Comments on draft-ietf-idnabis-defs-10

Vint Cerf vint at
Thu Sep 3 15:10:22 CEST 2009


  See comments below.


On Aug 30, 2009, at 6:35 PM, Elisabeth Blanconil wrote:

> Dear Wil,
> thank you for reading the interplus provisional documents and spotting
> how IUCG user members trust the WG Charter when it states :
> "The WG will stop work and recommend that a new charter be generated
> if it concludes that any of the following are necessary to meet its
> goals:
> "(i) A change to the "punycode" algorithm or to the ACE approach to
> encoding names  in the DNS."
> -> this is now what you propose.
We have made NO change to the punycode algorithm. The lowercasing  
observation is to assure canonical form conversions between punycoded  
forms (A-labels) and Unicode forms (U-labels) but does not change the  
punycode algorhtm itself.
> "(ii) A change to the ACE prefix from "xn--"
> -> you now propose a change from "xn--" to "$$--"

No that was my way of referring to all strings containing "--" in  
positions 3 and 4 of the on-the-wire form of R-LDH labels. We continue  
to use "xn--" as the A-label prefix but for all IDNA-aware  
applications, reserve the use of the first and second characters in  
case there is ever a need to define a new prefix.
> "(iii) A change to the basic approach taken in the design team
> documents (Namely: independence from Unicode version and elimination
> of character mapping in the protocol)"
> -> Vint already proposed the change of the last sub-point.Yet the WG
> has not stopped work as the Chair confirmed it when I asked if it was
> necessary for an I_D concerning and quoting the WG to be published as
> a WG Draft or if IUCG could submit it.

A minor change in the charter was made and approved by the AD to allow
for non-normative mapping document.
> As we expected it, at this stage of the document set production, a few
> hours before the end of the WG/LC, you question the worked out rough
> consensus. Since we obviously expected your requests, we have
> considered at length how they could be best addressed. Our consensus
> is:
> 1. either the Chair calls for a stop on the WG work, and a debate on
> Charter changes to be proposed.
There was extensive discussion on the matter of putative A-labels  
upper case ASCII and the matter was resolved in my opinion by assuring
that input to punycode conversion is done using lower-case ASCII only.
> 2. either the Charter (modified or not?) is respected and we make (i),
> (ii) and (iii) an issue for the IETF/LC.
You are free to raise any issues you like in IETF/LC but it is my  
sense that
we have complete the WG Last Call and are in final edits leading to
presentation of the IDNABIS/IDNA2008 documents to the AD.
> 3. or we face an IETF process and architectural conflict that will
> probably resolve at network clients level.
I have no idea what you mean here but adoption of IDNA2008 is
plainly voluntary.
> It would be better to avoid (3). (1) and (2) seem technically
> equivalent at this stage. The real issue is the impact of the
> resulting further delays in implementing IDNA2008, on Fast Track and
> IDNccTLDs, etc. and their FLOSS strategic equivalents: Project.FRA,
> Multilinc, etc. FYI, since FLOSS have no financial nor political
> dependency, AFAIK they seem to be on track.
> Best regards.
> Elisabeth Blanconil
> 2009/8/30 Wil Tan <wil at>:
>> On Sat, Aug 29, 2009 at 5:17 PM, John C Klensin <klensin at>  
>> wrote:
>>> --On Monday, August 24, 2009 23:24 -0400 Andrew Sullivan
>>> <ajs at> wrote:
>>>> In a previous comment (see
>>>> 0.html), I made a vague remark about something I find
>>>> worrisome in this text in §
>>>> ...
>>> These changes, with Paul's suggested modifications, have been
>>> tentatively accepted and incorporated in the document.  Anyone
>>> who objects should say so quickly.
>> I posted a comment related to the definition of A-label some time  
>> ago, but
>> the thread was
>> digressed:
>> The issue is with case variants of A-labels. By DNS rules, as  
>> mentioned in
>> several places in the idnabis-defs draft, A-labels are to be  
>> compared in a
>> case independent manner. However, if certain characters in an A- 
>> label have
>> been uppercased, the Punycode decoding algorithm (due to its mixed- 
>> case
>> annotation feature) may produce invalid U-label because the ASCII  
>> characters
>> will be in capital letter form.
>> =wil
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at
> _______________________________________________
> Idna-update mailing list
> Idna-update at

More information about the Idna-update mailing list