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

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

At 16:40 22/04/2010, Peter Saint-Andre wrote:
>This document is probably of interest here...
>
>-------- Original Message --------
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-resman-idna2008-mappings-01.txt

This document is important. As important as 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.

_______________________________________________
newprep mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/newprep

---

From: "Yao Jiankang" <[email-masked]>
Date: Sun, 25 Apr 2010 08:44:44 +0800

What peter said is "This document is probably of interest here...".
We do not focus on IDN, but internationalized string. There is a difference.

---

From: jefsey <[email-masked]>
Date: Sun, 25 Apr 2010 14:30:54 +0200

>We do not focus on IDN, but internationalized string. There is a difference.

I think that the first thing to be done is to consider if the 
intended works is to be a set of patches, or to fit in the Internet 
architecture which is now based upon RFC 1958, RFC 3439 and IDNA2008.

I am only interested in the later. This is why I disagree with the 
ambiguous "internationalized string" wording. Because we should not 
necessarily replicate alternative solutions (RFC 1958) and because we 
also should strive for the simplest one (RFC 3439), if we want this 
work to be of use, we need to discuss universal services character 
sets. The target is to support a multilingual universal networked 
system, where IETF so far has tried to diversely internationalize 
functions of an ASCII network system. Today, based upon experience we 
reached the point where the IDNA2008 character set seems a good 
enough working basis for such a multilingual universal network system 
character set. For clarity sake I call if regcode (regular code) and 
its use in replacement of another system, "regularization".

I can already list as constraints: "user readyness", interoperability 
with ASCII and ISO 10646 code points, usability by IDNApplications 
(users side) and IDNA (network side), as being much phishing proof as 
possible, orthotypographically acceptable (no semantic value having 
to be bent/lost due to regcode constraints) and to be unambiguously 
multilingually/scripturally sortable throughout all the digital 
ecosystem (for example in being able to be used with my ccTAG 
proposition). I also add as a major constraint: its universal 
usability by IUI slots, what implies a common adminance. In a 
nutshell we need a world digital ecosystem equivalent to ASCII (when 
UCS is a complete CS for typographers).

As I explained, at this stage I am questioning the IETF through a 
possible three steps process (appeal to IESG and IAB, possibly ISOC 
further to experimental operations) in order to know (1) in which 
kind of Internet architectural understanding should it now operate 
(2) who should lead that adminance (because precisely we do not focus 
on IDN, and even not on network issues) and on which grounds.  This 
leads to a very simple question: should we adapt a code to existing 
functions, or adapt protocols and functions to a code - and then which code?

jfc