<font class="Apple-style-span" face="georgia, serif">Well, there is definitely FUD involved, but often FUD is in the eye of the beholder.</font><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div>
<font class="Apple-style-span" face="georgia, serif">> <meta charset="utf-8"><span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; ">We had experimental confirmation that the terminology in<br>
IDNA2003 created a certain amount of confusion.</span></font></div><div><span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif"><br></font></span></div>
<div><span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; "><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: separate; font-size: small; "><font class="Apple-style-span" face="georgia, serif">> <span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; ">How serious an incompatibility that is depends on how far one<br>
wants to go to support characters that have been recognized as<br>bad practices since 2003 and earlier just because someone,</span></font></span></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;"><font class="Apple-style-span" face="georgia, serif"><br>
</font></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;"><font class="Apple-style-span" face="georgia, serif">We had anecdotal evidence, not 'confirmation'. I do find some of the conclusions reasonable -- for example, it is credible that people registering labels that are mapped (eg ÖBB.at) might believe that what they had registered was the unmapped version, whereas what they actually registered was the mapped version <meta charset="utf-8">(eg <a href="http://xn--bb-eka.at">öbb.at</a>), and that such misunderstandings can cause problems.</font></span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><font class="Apple-style-span" face="georgia, serif"><br></font></span></div><meta charset="utf-8"><div><span class="Apple-style-span" style="border-collapse: collapse;"><font class="Apple-style-span" face="georgia, serif">But to justify the backwards incompatibilities, we <i>never</i> got any hard data (no statistics by TLDs, none for the many other registries) to justify the need for the thousands of backwards incompatibilities. No measurable impact of what were felt to be "bad" practices; just anecdotes. So speaking of 'confirmation' is misleading.</font></span></div>
<div><font class="Apple-style-span" face="georgia, serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="georgia, serif"><span class="Apple-style-span" style="border-collapse: collapse;">Don't get me wrong; now that IDNA2008 is in place, we need to move to it. But there will be a period of transition. It is easy to someone who doesn't have product responsibilities to shrug that off, but those who do have user-facing products are faced with dealing with the transition issues.<br>
</span></font><div><span class="Apple-style-span" style="border-collapse: collapse;"><font class="Apple-style-span" face="georgia, serif"><br clear="all"></font></span><font class="Apple-style-span" face="georgia, serif">Mark</font><br>
<br><i style="font-family: georgia, serif; ">— Il meglio è l’inimico del bene —</i><br>
<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">John C Klensin</b> <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span><br>Date: Sun, Oct 24, 2010 at 13:15<br>
Subject: Re: referencing IDNA2008 (and IDNA2003?)<br>To: jean-michel bernier de portzamparc <<a href="mailto:jmabdp@gmail.com">jmabdp@gmail.com</a>>, Mark Davis ☕ <<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>><br>
Cc: <a href="mailto:Marc.Blanchet@viagenie.ca">Marc.Blanchet@viagenie.ca</a>, IDNA2010 Documentation <<a href="mailto:workon@idna2010.org">workon@idna2010.org</a>>, <a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a>, internet users contributing group <<a href="mailto:iucg@ietf.org">iucg@ietf.org</a>>, Peter Saint-Andre <<a href="mailto:stpeter@stpeter.im">stpeter@stpeter.im</a>>, Adam Barth <<a href="mailto:ietf@adambarth.com">ietf@adambarth.com</a>><br>
<br><br>Folks,<br>
<br>
There is a bit of the sound of FUD here and I don't think that<br>
is useful, especially when some of the group are complicating<br>
things with their own vocabulary.<br>
<br>
Observations:<br>
<br>
(1) We had experimental confirmation that the terminology in<br>
IDNA2003 created a certain amount of confusion.  That was<br>
partially due to not making a distinction between a "Unicode"<br>
(really, native-script" or Unicode encoded in one of the<br>
Unicode-standardized encodings) label that could be encoded by<br>
ToASCII (after Nameprep processing and so on) and a similar<br>
label that could be obtained from applying ToUnicode to such a<br>
valid label encoded by ToASCII.  There was also confusion about<br>
the exact status of strings that were encoded using Punycode,<br>
had the "xn--" prefix, but were not actual, valid, IDN labels.<br>
And, finally, there was confusion about whether strings encoded<br>
by Punycode should be looked up without validating them<br>
(although I personally believe that IDNA2003 was very clear on<br>
that point, there was confusion nonetheless).  For exactly those<br>
reasons, IDNA2008 contains much more precise definitions.  That<br>
creates a situation in which, depending on how one looks at<br>
things, there is a much broader range of strings that can be<br>
considered valid (particularly those that depend on mapping) in<br>
IDNA2003 than there is in IDNA2008.  That difference, however,<br>
has a lot more to do with the validity of different presentation<br>
forms (again, including forms that require mapping to be valid)<br>
than fundamental validity.   And every valid A-label (under<br>
IDNA2008) that represents Unicode characters that are valid in<br>
Punycode-encoded labels that are valid output of ToASCII under<br>
IDNA2003 is valid under IDNA2003 and has the same interpretation<br>
when converted back to a native character string (U-label in<br>
IDNA2008).<br>
<br>
(2) Mark is quite correct in pointing out that the IDNA2003<br>
considers many characters, especially symbols and punctuation,<br>
valid that IDNA2008 does not.  That issue has nothing to do with<br>
mapping and is really an entirely separate issue where validity<br>
checks are concerned.  However, those who are concerned about<br>
that difference in terms of lookup compatibility should read<br>
Section 5.3 of RFC 5891 very carefully if they have not done so<br>
already.  The case that it quite intentionally involves seems to<br>
me to be precisely the one that Adam ideally has: a pair of<br>
domain names that contain things that look like A-labels which<br>
he wants to compare by a simple octet-by-octet comparison.<br>
<br>
In the less ideal case in which one of the two strings to be<br>
compared is in native-character from, not Punycode-encoded, is<br>
complicated for another reason.  IDNA2003 quite intentionally<br>
left policies about what characters could actually be registered<br>
for use in labels to registries, while IDNA2008 first eliminates<br>
symbols punctuation, and other non-letter/ non-digit characters.<br>
But every set of recommendations I've aware of for IDNA2003<br>
recommended against registering a label containing any character<br>
that was not a character validly used to write "words" in some<br>
language.   Modulo some hand-waving, that is the same rule that<br>
IDNA2008 specified as part of the PVALID/ DISALLOWED<br>
distinction.   So, for those punctuation and symbol characters<br>
(etc.) the difference between IDNA2003 and IDNA2008 has more to<br>
do with something that one can get away with under IDNA2003 (in<br>
some registries) but is explicitly prohibited under IDNA2008<br>
rather than a new incompatibility.<br>
<br>
How serious an incompatibility that is depends on how far one<br>
wants to go to support characters that have been recognized as<br>
bad practices since 2003 and earlier just because someone,<br>
somewhere, may have successfully registered and used them<br>
(remember that we are talking about domains in cookies here, not<br>
what might have been used in an IRI).<br>
<br>
regards,<br>
   john<br>
<br>
<br>
--On Sunday, October 24, 2010 21:21 +0200 jean-michel bernier de<br>
<div><div></div><div class="h5">portzamparc <<a href="mailto:jmabdp@gmail.com">jmabdp@gmail.com</a>> wrote:<br>
<br>
> 2010/10/24 Mark Davis ☕ <<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>><br>
><br>
>> > These A-label having been initially registered as IDNA2003,<br>
>> > IDNA2008 or<br>
>> xn-ascii does not make any difference.<br>
>><br>
>> There is a bit of a problem in terminology. I used the term<br>
>> "punycode label" to include labels of the form "xn--...",<br>
>> where the ... is valid Punycode representations (in ASCII) of<br>
>> a Unicode string (with non-ASCII characters).<br>
>><br>
><br>
> This seems to be an IDNA2003 and IDNA2008 well acceptable<br>
> definition?<br>
><br>
><br>
>> If we are speaking precisely, the term "A-Label" is defined<br>
>> in IDNA2008, and is more restrictive. It does not include all<br>
>> the punycode labels that are valid in IDNA2003. So<br>
>> "<a href="http://xn--1-wpn.blogspot.com/" target="_blank">http://xn--1-wpn.blogspot.com/</a>" (= http://€<br>
>> <a href="http://1.blogspot.com/" target="_blank">1.blogspot.com/</a>) does not have an A-Label in it, but is a<br>
>> punycode label, and is valid in IDNA2003.<br>
>><br>
><br>
> This is also my understanding. But I understand it is only<br>
> more restrictive because the IDNA2008 conversion terms are<br>
> more restrictive.<br>
><br>
>><br>
>> Because A-Label is defined in IDNA2008 (not in IDNA2003), we<br>
>> should follow the IDNA2008 definition precisely. Otherwise<br>
>> communication becomes difficult -- two people think they are<br>
>> in agreement about a point involving A-Labels, when they mean<br>
>> different things, and are thus not in agreement.<br>
>><br>
><br>
> Agreement. IDNA2003 stated (RFC 3490) : "While all ACE labels<br>
> begin with the ACE prefix, not all labels beginning with the<br>
> ACE prefix are necessarily ACE labels." How should I call<br>
> non-ACE/non-A-label "xn--" ASCII domain names? Such domain<br>
> names exist and therefore can be used by Cookies.<br>
><br>
> However, the problem I raised was that for the network DNS<br>
> A-labels are the reference, while U-labels are the IUser's<br>
> reference, and that no concept has been suggested (*) (on the<br>
> IETF side) and no mechanism has been defined (*) on the IUse<br>
> Architecture side to make sure they strictly correspond<br>
> throughout applications. (*): I am aware of except the<br>
> IDNApplication concept (i.e. to centralise punycoding on each<br>
> machine/network) and the ML-DNS JFC is working on a running<br>
> test.<br>
><br>
> Frankly, my understanding is that IDNA2008 is a vertical<br>
> begining and real IETF horizontal work is to come, as per<br>
> <a href="http://www.iab.org/documents/iabmins/iabmins.2010-04-07.txt" target="_blank">http://www.iab.org/documents/iabmins/iabmins.2010-04-07.txt</a><br>
> and their<br>
> <a href="http://www.iab.org/appeals/2010-08-20-morfin-response.pdf" target="_blank">http://www.iab.org/appeals/2010-08-20-morfin-response.pdf</a><br>
> committed reponse .<br>
><br>
> Portzamparc<br>
><br>
><br>
><br>
>> Mark<br>
>><br>
>> *— Il meglio è l'inimico del bene —*<br>
>><br>
>><br>
>> On Sat, Oct 23, 2010 at 19:05, jean-michel bernier de<br>
>> portzamparc < <a href="mailto:jmabdp@gmail.com">jmabdp@gmail.com</a>> wrote:<br>
>><br>
>>> 2010/10/24 Mark Davis ☕ <<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>><br>
>>><br>
>>> I'm in agreement about the usefulness of storing the<br>
>>> punycode form. As to<br>
>>>> what you would like to see, Patrik, I'm in agreement there<br>
>>>> as well; that the goal is IDNA2008. And I think we'll get<br>
>>>> there eventually, when the major registries disallow the<br>
>>>> registrations of non-IDNA2008 names.<br>
>>><br>
>>><br>
>>> Dear Mark,<br>
>>><br>
>>> whatever the policy of the "registries", their transitions,<br>
>>> their interest in Unicode, their commercial, cultural or<br>
>>> political strategies, etc.  they only use A-labels as far as<br>
>>> the Internet and the Internet DNS are concerned (them having<br>
>>> "xn--" headers or not - remember that until IDNA2003 every<br>
>>> cooky was A-label only). These A-label having been initially<br>
>>> registered as IDNA2003, IDNA2008 or xn-ascii does not make<br>
>>> any difference. Cookies are not interested in the origin of<br>
>>> the domain name, but in the value of the domain names. Every<br>
>>> IDN has one and only one lowercase A-label value. And this<br>
>>> value is here to stay.<br>
>>><br>
>>> Considering anything else for cookies, is to reintroduce the<br>
>>> confusion that IDNA2008 clarified.<br>
>>> Remember the sensible ".su" position: they will not register<br>
>>> U-labels, but only A-label whatever the reverse<br>
>>> punycodability.<br>
>>><br>
>>> The problem for implementers is not there. The problem is to<br>
>>> obtain a local user authoritative A-label, something the AD<br>
>>> was told not to ask but IAB will have to document.<br>
>>><br>
>>> Portzamparc<br>
>>><br>
>><br>
>><br>
<br>
<br>
<br>
<br>
</div></div></div><br></div></div>