I-D Action:draft-faltstrom-5892bis-01.txt

jefsey jefsey at jefsey.com
Thu Dec 23 12:04:07 CET 2010

At 08:29 23/12/2010, Patrik Fältström wrote:
>Ken, thanks for this.
>Makes sense.
>What do others think?

I support all the comments of Ken, except "... The IETF considers it 
important that the IDNA standard remain aligned with the Unicode Standard."

This is a negation of the former WG/IDNAbis charter and RFC 5892 
which states: " It specifies a procedure, and not a table, of code 
points so that the algorithm can be used to determine code point sets 
independent of the version of Unicode that is in use".

IDNA2008 is deal with those who "design, use, and manage" the inside 
and the outside of the Internet which is to be as much stable ad the 
DNS is stable. This is for outside applications (eg. RFC 5895, 
ML-DNS, etc.) to see their submissions resolved the same whatever the 
date they were developed and deployed.

This may create difficulties. These difficulties may belong to :
- the "inside" of the Internet, the network side. They are to be 
addressed by the IAB coming IDNA work to keep them transparent to the 
external side.
- the "ouside", on the user side. They are to be addressed by the 
emerging IUse community. This community is _not_ exclusively Internet 
oriented. It needs and has started working on the preparation of an 
ISO 10646 based cross-needs International Network Character Set that 
will serve as a IUI (Intelligent Use Interface) reference. The INCS 
is based upon RFC 5892. Its plans includes visual character 
validation and IDv6 locale transcription tables.

As long as the entire IDNA architecture has not been securely 
consolidated by the IAB or by grassroots practice, no application 
developer should be proposed anything else than the RFC 5892 allowed 
code points. In any case we deny the right to non-IUse SDOs to make 
any assumption on the use of any code point. They are allowed or not 
period. There are at least two projects we know of encyption 
algorithms based on the INCS. IDNA2008 specifies the "inside" aspects 
of the protocol and leaves open the "outside" aspects. Unicode and 
IETF does not now the impact of unilateral changes of them on others 
who trust them to respect the rules. PVALID must stay unchanged.

Anyway, I have difficulties understanding how a private submission 
can be standard track and could be partly override a close dedicated 
WG standard track document set. This kind of suggested update is 
similar to the job of Michael Everson for langtags, except that the 
langtags table maintenance is described in an RFC (eventhought it is 
not respected). Maintaining RFC 5892 was never considered, no IETF 
job was ever discussed, etc. the IUse "group" would have determinedly 
opposed it.

Please, let no divide the Internet again on the Unicode issue we have 
solved. IETF RFCs and Unicode Versions are "independent" (RFC 5892).


More information about the Idna-update mailing list