Proposed document structure and content for IDNA
vint at google.com
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 alvestrand.no <idna-update-bounces at alvestrand.no>
To: idna-update at alvestrand.no <idna-update at alvestrand.no>
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
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 alvestrand.no, 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 alvestrand.no
More information about the Idna-update