Unconditional punycode conversion

J-F C. Morfin jfc at morfin.org
Tue Mar 8 18:59:04 CET 2011


At 01:02 08/03/2011, Simon Josefsson wrote:
>The next-to-last part of IDNA2008-lookup is section 5.5 of RFC 5891:
>
>    The string that has now been validated for lookup is converted to ACE
>    form by applying the Punycode algorithm to the string and then adding
>    the ACE prefix ("xn--").
>
>Consider an IDNA2008-lookup input label of "foo".  The above appear to
>say that this string should be punycode encoded, which seems wrong.
>
>Could someone help me pin-point where it says that section 5.5 does not
>apply to an input string "foo"?
>
>Alternatively, should section 5.5 instead say that ACE encoding is only
>intended to occur when the label to be converted contains non-ASCII
>characters?  That would make more sense.

Dear Simon,

What is the impact of having punycode applied to "foo"? Zip, nothing. 
If, as a programmer, I want to get every IDN (Internet Domain Name) 
punycoded (which I actually do), what would be the impact? Nil, zip, 
nothing. Except for that : the day, as a programmer, that I want to 
change _my_ punycode into _my_ punyplus to correctly support, on a 
fringe to fringe basis, the orthotypography 
(<https://datatracker.ietf.org/doc/draft-iucg-idna2008-orthotypography/>draft-iucg-idna2008-orthotypography-00) 
of _my_ language (e.g., French and Latin languages, which represent a 
significant number of the people I relate with, pool of innovation, 
economic reserves, and political power), of which I can in fact do 
and disseminate it without changing IDNA2008 in any way. This simply 
by publishing a non-IETF IUse document explaining why and how to load 
and use a punyplus 
(<https://datatracker.ietf.org/doc/draft-iucg-punyplus/>draft-iucg-punyplus-03) 
module to those people who speak French and Latin languages.

It is in this way that the semantic internet can remain compatible 
with the legacy internet and support both "foo" and "Foo".


Now, in a broader perspective, the general problem that we face is 
not easy because it is "unusual" (cf. RFC 5895).

1. Here, we are at the IETF. In respecting the IETF rules and in full 
knowledge of the situation (con, pros and needed add-ons or even 
external changes to consider), through WG Chair, Unicode, and IUCG 
(<https://datatracker.ietf.org/doc/draft-iucg-afra-reports/>draft-iucg-afra-reports-00) 
reports and AD positions, after WG and IETF LC, the IESG has approved 
IDNA2008. IDNA2008 exemplifies a major enhancement of the way in 
which to understand the Internet. Shortly thereafter, RFCs stated 
that the internet was seated on two principles (constant change and 
simplicity) (RFC 1958 and 3439) plus recipes in RFC 1958. IDNA2008 
introduced a third principle to match diversity (subsidiarity) with 
an impact on the Internet model (presentation layer), domain name 
(now a pile and no longer a single ASCII label set), and the 
possibility for users to use it as a fringe to fringe intelligent network.

2. In my report to the IESG, I pleaded for the IDNA2008 document set 
to be accepted immediately, in spite of the pertinent questions of 
the AD on the viability of the IDNA very concept on the user side, 
because IDNA2008 completes the inside Internet and because the 
outside Internet (Fringes and further) needs it to proceed in its own 
building that will address those questions. I also indicated that I 
would appeal their decision 
(http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf), which I did. 
This was because of the major additions to the common understanding 
of the Internet, the IESG did not even inform the IETF community, not 
even by an IESG disclaimer.

This appeal procedure was actually to get:

1. the IAB confirming IDNA2008 as it is, i.e. architectural, and that 
new discussions (this mailing list) should go to the IAB, which 
directly works on the issue (cf. the recent RFC 6055 which does not 
close the IDN related issues).

2. the IETF as a whole determining how to handle what IDNA2008 
introduces (what is only partly discussed in here) and where. The IAB 
fully answered that in eight points that are rather clear and 
positive. (http://iab.org/appeals/2010-08-20-morfin-response.pdf) 
What affects the inside internet belongs to the IAB scope as well as 
to further WGs, of which the Charter is to be better defined. What 
affects the outside, such as my own understanding of the outside, is 
an area where the IAB, hence the IETF, does not take any position.

I am working on this and helping the emergence of the necessary IUse 
documentation and user community, i.e. the people concerned by the 
Intelligent Use of the world digital ecosystem, of which the Internet 
is an element; and its liaison with the IETF via the iucg at ietf.org 
mailing list and site. As a free middlenetware. To be done properly 
it takes time moreover I was tied by family issues. At the earliest 
stage of the WG/IDNABis I committed to develop and deploy an ML-DNS 
user oriented extension of the IDNA work. It happens that the 
Internet is more powerful than I expected, and that the ML-DNS comes 
with a lot of additional "researc"h area "opportunities" as says the 
IESG, the introduction of which should - if possible - not shake the 
Internet community, nor be controlled by a single sponsor I could 
easily accept.

jfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20110308/983b3e13/attachment.html>


More information about the Idna-update mailing list