Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: <draft-klensin-idna-rfc5891bis-01.txt>)

[Mark Davis ☕️ <[e-mail]>]

>> We were given a different explanation and answer to our questions, one
much closer to "there is no problem and will be no problem in  the future,
so don't worry - no special rules are needed".
> Correct. Being on the receiving side of the messages, and one of the
persons that asked the questions, yes, we asked, they responded...

I'm mystified as to who exactly you think said "there is no problem and
will be no problem in the future" (or words to that effect), since I can't
imagine any Unicode expert saying that NFC, NFKC, or the then-proposed IDNA
2008 solves the problem of visually visually indistinguishable or confusing
characters. In fact, there are many emails on
https://mailarchive.ietf.org/arch/search/?email_list=idna-update NFKC
making it clear that NFKC reduces, but does not close to solving that
issue. And the same for the then-proposed context rules.

So I'm guessing that there was a misunderstanding as to the problem being
discussed.

Can you point to the email(s) on this list from a Unicode expert that you
would characterize as responding that "there is no problem and will be no
problem in  the future, so don't worry - no special rules are needed" ? (Of
course, it needn't be those exact words — I just want to figure out what
was the foundation for your statement.)


Mark

On Sat, Mar 10, 2018 at 2:06 PM, Patrik Fältström <[e-mail]> wrote:

> On 9 Mar 2018, at 12:27, John C Klensin wrote:
>
> > * Your explanation below is very helpful, at least to me.
>
> Me too.
>
> > I am
> > confident that, if it was what we were given when we started the
> IDNA2008 design, some of the rules would have reflected it.   We were given
> a different explanation and answer to our questions, one much closer to
> "there is no problem and will be no problem in  the future, so don't worry
> - no special rules are needed".
>
> Correct. Being on the receiving side of the messages, and one of the
> persons that asked the questions, yes, we asked, they responded...
>
> > The question is what to do now.  If we were to decide that your
> discussion would made a good addition to the protocol, we would run into at
> least two problems.  One is that we promised the registry community that
> there would be no more disruptive
> > changes and, at least as important, the Unicode Consortium
> > outrage at our altering the way a handful of code points were treated
> would presumably be much greater if we were to make a change that would
> invalidate a large number of labels that might now be registered and in use
> somewhere in the tree.  Another is the problem that started this thread --
> there appears to be no energy in the IETF to consider and process changes
> to IDNA, even fairly trivial clarifications.
>
> I think we should do some scenario planning here. Remember that we do not
> have a world where IDNA2008 based on Unicode 6.x is what people use. People
> use all different kind of mix between IDNA2008, IDNA2003 and Unicode
> versions. I have myself worked with the curl library (that uses libidn) and
> to be honest, I do not think people KNOW what they use. Or they know, and
> they know they violate the rules. For the contracted parties, they have the
> LGR coming down the road anyways, so...
>
> And *if* we go down this path, is it "enough" to do in the LGR (i.e.
> ICANN) or should IETF do some adoption (and W3C?), or should IETF say "we
> can move forward in a more safe way AS WE KNOW ICANN DO LGR"...
>
> Or...
>
>    Patrik
>
> _______________________________________________
> IDNA-UPDATE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idna-update
>
>