Subject: [newprep] Fwd: I-D Action:draft-resman-idna2008-mappings-01.txt

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Apr 2010 08:40:55 -0600

This document is probably of interest here...

-------- Original Message --------
Subject: I-D Action:draft-resman-idna2008-mappings-01.txt
Date: Mon, 19 Apr 2010 12:00:01 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Mapping Characters in IDNA2008
	Author(s)       : P. Resnick, P. Hoffman
	Filename        : draft-resman-idna2008-mappings-01.txt
	Pages           : 7
	Date            : 2010-04-19

In the original version of the Internationalized Domain Names in
Applications (IDNA) protocol, any Unicode code points taken from user
input were mapped into a set of Unicode code points that "made
sense", and then encoded and passed to the domain name system (DNS).
The IDNA2008 protocol presumes that the input to the protocol comes
from a set of "permitted" code points, which it then encodes and
passes to the DNS, but does not specify what to do with the result of
user input.  This document describes the actions that can be taken by
an implementation between user input and passing permitted code
points to the new IDNA protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-resman-idna2008-mappings-01.txt

---

From: jefsey <[email-masked]>
Date: Sat, 24 Apr 2010 10:31:53 +0200

>http://www.ietf.org/internet-drafts/draft-resman-idna2008-mappings-01.txt

This document is important. As important is the IAB's 
http://tools.ietf.org/html/draft-iab-idn-encoding-01 and possibly the 
tedious but comprehensive enough 
(http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf) compilation 
of my IESG level appeal for those wanting to get the details and 
grasp the whole context.

My reading of the concerned parts of IDNA2008 is, as I have explained 
many times, that it was necessary for a domain name character set 
(DNCS) to eventually be worked out. It was adequately formed in using 
ISO 10646 code points, which permits easy interoperability. I, 
therefore, understand the process, which is being used to prepare a 
UCS string into a DNCS string, as a "domainization". A remaining 
difficulty is, however, the support of Latin language majuscules, 
since they are necessary for their semantic addressing.

In addition, I consider the DNCS in-parts as a super-set of a 
"regular character set" ("regcode") prepared in the same manner, but 
also with anti-phishing considerations, so that the resulting charset 
can serve as a secure man/machine multiorthotypographic universal 
charset (passports, security cards, operating system commands, 
databases, ISO 11179 registriesetc.). A secure "regcode" encoding 
table should eventually be produced that could be based upon Unicode 
+ lingual context and be attached to ISO 3166 and use ccTAGs for a 
unique secure international sorting order that could be used in 
"internatioperable" applications. This would permit an IETF regcode 
to address the Internet protocols' needs through a standard 
"regularization" process, and to free Unicode from network operations 
constraints.

This issue will be raised as one of the points of my IAB level 
appeal, because IDNA2008 was (per its charter and by its results) a 
severance of the Internet from Unicode. The responses to the 
questions legitimately raised by your proposed charter do in fact 
belong to the IAB guidance that I claim IESG should have requested 
before approving IDNA2008 - or quoted in a disclaimer indicating that 
IDNA2008 is the network side of multilingualization, not the whole of it.

Some consider that the other part belongs to the UI (User Interface, 
cf. "resman" draft). I personally think that it also belongs to the 
needed architectural IUI (Internet Usage Interface) if one wants to 
respect the constraints investigated by the IAB in its Domain 
Internationalization draft. Anyway, through UI or IUI, the work you 
consider is necessary. However, I would not engage in it, before the 
IAB has published its position on the matter. This is why I 
documented and am following my Project.FRA roadmap to the IESG, and 
they have discussed it before approving IDNA2008.

Their response to my appeal shows that they also accept that the 
issue is worth a BoF (or several ones since your concern is not the 
only one that should be consistently investigated). However, until 
IAB has commented on the IESG answer, I do not really know in which 
area (if any) such IUI related issues (including yours) should be 
discussed. Please remember that IAB has initiated a Draft on IDNs 
that, at least for the time being, seems to contradict the very 
IDNA2003 architectural principle of IDN in Applications and lead to 
consider an IDNApplication that would certainly impact your 
evaluation process. Basically, one cannot have _several_ software 
modules in a computer that may convert and resolve domain names differently.

Best.