<html>
<body>
At 01:02 08/03/2011, Simon Josefsson wrote:<br>
<blockquote type=cite class=cite cite="">The next-to-last part of
IDNA2008-lookup is section 5.5 of RFC 5891:<br><br>
   The string that has now been validated for lookup is
converted to ACE<br>
   form by applying the Punycode algorithm to the string and
then adding<br>
   the ACE prefix ("xn--").<br><br>
Consider an IDNA2008-lookup input label of "foo".  The
above appear to<br>
say that this string should be punycode encoded, which seems
wrong.<br><br>
Could someone help me pin-point where it says that section 5.5 does
not<br>
apply to an input string "foo"?<br><br>
Alternatively, should section 5.5 instead say that ACE encoding is
only<br>
intended to occur when the label to be converted contains non-ASCII<br>
characters?  That would make more sense.</blockquote><br>
Dear Simon,<br><br>
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
(<a href="https://datatracker.ietf.org/doc/draft-iucg-idna2008-orthotypography/">
draft-iucg-idna2008-orthotypography-00</a>) 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
(<a href="https://datatracker.ietf.org/doc/draft-iucg-punyplus/">
draft-iucg-punyplus-03</a>) module to those people who speak French and
Latin languages.<br><br>
It is in this way that the semantic internet can remain compatible with
the legacy internet and support both "foo" and
"Foo".<br><br>
<br>
Now, in a broader perspective, the general problem that we face is not
easy because it is "unusual" (cf. RFC 5895).<br><br>
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
(<a href="https://datatracker.ietf.org/doc/draft-iucg-afra-reports/">
draft-iucg-afra-reports-00</a>) 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. <br><br>
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
(<a href="http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf" eudora="autourl">
http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf</a>), 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. <br><br>
This appeal procedure was actually to get:<br><br>
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). <br><br>
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.
(<a href="http://iab.org/appeals/2010-08-20-morfin-response.pdf" eudora="autourl">
http://iab.org/appeals/2010-08-20-morfin-response.pdf</a>) 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. <br><br>
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@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.<br><br>
jfc<br>
</body>
</html>