referencing IDNA2008 (and IDNA2003?)
jean-michel bernier de portzamparc
jmabdp at gmail.com
Sun Oct 24 21:21:46 CEST 2010
2010/10/24 Mark Davis ☕ <mark at macchiato.com>
> > These A-label having been initially registered as IDNA2003, IDNA2008 or
> xn-ascii does not make any difference.
> There is a bit of a problem in terminology. I used the term "punycode
> label" to include labels of the form "xn--...", where the ... is valid
> Punycode representations (in ASCII) of a Unicode string (with non-ASCII
This seems to be an IDNA2003 and IDNA2008 well acceptable definition?
> If we are speaking precisely, the term "A-Label" is defined in IDNA2008,
> and is more restrictive. It does not include all the punycode labels that
> are valid in IDNA2003. So "http://xn--1-wpn.blogspot.com/" (= http://€
> 1.blogspot.com/) does not have an A-Label in it, but is a punycode label,
> and is valid in IDNA2003.
This is also my understanding. But I understand it is only more restrictive
because the IDNA2008 conversion terms are more restrictive.
> Because A-Label is defined in IDNA2008 (not in IDNA2003), we should follow
> the IDNA2008 definition precisely. Otherwise communication becomes difficult
> -- two people think they are in agreement about a point involving A-Labels,
> when they mean different things, and are thus not in agreement.
Agreement. IDNA2003 stated (RFC 3490) : "While all ACE labels begin with the
ACE prefix, not all labels beginning with the ACE prefix are necessarily ACE
labels." How should I call non-ACE/non-A-label "xn--" ASCII domain names?
Such domain names exist and therefore can be used by Cookies.
However, the problem I raised was that for the network DNS A-labels are the
reference, while U-labels are the IUser's reference, and that no concept has
been suggested (*) (on the IETF side) and no mechanism has been defined (*)
on the IUse Architecture side to make sure they strictly correspond
throughout applications. (*): I am aware of except the IDNApplication
concept (i.e. to centralise punycoding on each machine/network) and the
ML-DNS JFC is working on a running test.
Frankly, my understanding is that IDNA2008 is a vertical begining and real
IETF horizontal work is to come, as per
http://www.iab.org/documents/iabmins/iabmins.2010-04-07.txt and their
http://www.iab.org/appeals/2010-08-20-morfin-response.pdf committed reponse
> *— Il meglio è l’inimico del bene —*
> On Sat, Oct 23, 2010 at 19:05, jean-michel bernier de portzamparc <
> jmabdp at gmail.com> wrote:
>> 2010/10/24 Mark Davis ☕ <mark at macchiato.com>
>> I'm in agreement about the usefulness of storing the punycode form. As to
>>> what you would like to see, Patrik, I'm in agreement there as well; that the
>>> goal is IDNA2008. And I think we'll get there eventually, when the major
>>> registries disallow the registrations of non-IDNA2008 names.
>> Dear Mark,
>> whatever the policy of the "registries", their transitions, their interest
>> in Unicode, their commercial, cultural or political strategies, etc. they
>> only use A-labels as far as the Internet and the Internet DNS are concerned
>> (them having "xn--" headers or not - remember that until IDNA2003 every
>> cooky was A-label only). These A-label having been initially registered as
>> IDNA2003, IDNA2008 or xn-ascii does not make any difference. Cookies are not
>> interested in the origin of the domain name, but in the value of the domain
>> names. Every IDN has one and only one lowercase A-label value. And this
>> value is here to stay.
>> Considering anything else for cookies, is to reintroduce the confusion
>> that IDNA2008 clarified.
>> Remember the sensible ".su" position: they will not register U-labels, but
>> only A-label whatever the reverse punycodability.
>> The problem for implementers is not there. The problem is to obtain a
>> local user authoritative A-label, something the AD was told not to ask but
>> IAB will have to document.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Idna-update