referencing IDNA2008 (and IDNA2003?)

[jean-michel bernier de portzamparc]

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
> characters).
>

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
.

Portzamparc



> Mark
>
> *— 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.
>>
>> Portzamparc
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20101024/33897936/attachment-0001.html>