Proposed document structure and content for IDNA

Vint Cerf vint at
Fri Jul 11 13:28:23 CEST 2008


ML-DNS is not the topic of this Working group. Whatever it may be it is not part of a relevant argument for any particular parsing of IDNA documents. Please do not continue to send emails about ML-DNS on this list. 


----- Original Message -----
From: idna-update-bounces at <idna-update-bounces at>
To: idna-update at <idna-update at>
Sent: Fri Jul 11 03:09:03 2008
Subject: Re: Proposed document structure and content for IDNA

At 00:56 11/07/2008, Mark Davis wrote:
>tables* ( the long lists from tables.txt, the context rules, 
>exception lists: all to go onto IANA and be updated there with 
>successive versions of Unicode and any the Expert Reviewer 
>Committee's changes)

1) As indicated in a private mail to some I have a problem with this.

Paul's proposition permits to have a compact and clear parallel 
presentation of IDNA and ML-DNS we hope to start testing in a few 
months (the main difference will probably be that ML-DNS will be 
fully end to end, falling back to IDNA for retrocompatibility with 
Legacy systems when punycode is used).

The only real problem we have is with Unicode and Unicode copyrights. 
This is why I call for a Unicode/IETF MoU for years. We cannot make 
ML-DNS dependent on non Open Standards we cannot review. Nor make it 
subject to rules with a copyright we could not adapt. I stated that 
ML-DNS will be based upon LS640 which is Open Standard and the basis 
of ISO 639-6 (cf. ISO 639-6 acknowledgments). We will also respect 
ISO 3166 with the additions we documented to ISO 3166/MA (as per ISO 
3166) and we label as ONSD 3166-4.

We consider the way we can include and extend ISO 10646. We can 
respect, quote, and adapt RFCs or submit our own I_Ds. Without an 
IETF/Unicode MoU we have no capacity to do something equivalent with Unicode.

2) this means that this WG-IDNABIS would create an Expert Reviewer 
Committee, such as the ietf-language at, or may be use it 
as a Reviewer Committee?  This is a new concept to me. Also, one of 
the opposition we had over BCP 47 was that the WG-LTRU refused to 
consider any relation between BCP47 and IDNA. This would create 
another difficulty since every IETF and ICANN position so far and 
still last week says that IDNA deployment will be based upon ISO 
3166, while BCP47 is not and is not intended to be ISO 3166 but ISO 
639 compatible.  An ISO NWIP proposed by Debbie Garside last year 
refused to consider a cooperation and was defeated. This is why 
ML-DNS will use ccTAGs.

This is why I support that everything technical should be compacted 
in one single reference document. The only table being ISO 10646. 
That document may be subject to changes if there are Unicode proposed 
changes adopted by the IETF, as it is the reason today for this WG. 
There is no politics involved, just a need of gathering everything at 
the same place, within a unique document to be translated into each 
of the ISO 3166 language and script to make it locally normative/legal.


Idna-update mailing list
Idna-update at

More information about the Idna-update mailing list