<html>
<body>
Peter,<br><br>
Yours is an excellent example of the IUI role and of the ML-DNS.
These two notions are not documented by RFCs yet (due to personal delays)
but are the normal continuation on the user side of IDNA2008 on the
Internet side.<br><br>
As you may know, f rom the very beginning of the WG/IDNABis I raised the
question of its intended final purpose:<br><br>
- was it to satisfy the Internet's,<br>
- or innovation's and the (lead) users' needs. Lead users like you
and I.<br><br>
The response was clear enough: it was the Internet's needs layers
only. On this clear target, I promised to document and build the response
to the users, as a user-application-front-end called the ML-DNS, where ML
stands for "multi-layer". In a multilingual environment it was
to support every language at the same level as English. The solution was
to support a "domain name pile" where the Internet domain name
corresponds to the two bottom layers (A-label and U-label), but where
many layers can be added on top to support things like: <br><br>
- metadata that Unicode does not support (such as what is needed for
French majuscules), <br>
- encrypted domain names,<br>
- various normalization forms (such as the one you are
investigating), command lines, etc. each being supported by its own
layer's library or service. You could conceptually understand it as
"punyplus code", which will convert back and forth different
layers (such as yours) into A-labels.<br><br>
NB. I evaluate that network written exchanges need a dedicated
extended network oriented normalization form based on graphical premizes
+ (optionnally) the language being used.<br><br>
1. That way A-labels can be considered as pivotal among the different
UDNs formats (User Domain Names) including the Internet Class Domain
Names (IDN) made of the A-U-label duality. Just remember that a class is
a consistent particular vision of network protocols. If you can use the
basic Internet through converters like punycode it will be simpler for
you. However, what the Internet can deliver, as demonstrated by DNA2008,
is quite powerful and gradual. Before having to consider a different
class, you can consider your own presentation. There was no presentation
layer in the Internet technology, yet to support the language diversity
that one needs the presentation layer was introduced through the
"xn--" prefix, which represents the "xn"
presentation. <br><br>
So, it is up to you to decide what you need. This is just acknowledging
that the Internet is able to support the principle of subsidiarity, which
is necessary to support the users' diversity, such as yours.<br><br>
However, please remember RFC 3439: very large systems, and the Internet
is a very large system multiplied into a very very large system by
subsidiarity, are to respect the principle of simplicity. Keep it as
simple as you can.<br><br>
2. Now there is another problem. The Internet supports subsidiarity
without changing a single one of its bits: it is just reading RFCs in a
different perspective. However, this is not the case for IDNinA, the very
initial IDN support concept that does not scale. If you have two
applications on your machine that support two IDNA libraries, nothing
makes you sure that they will behave the same and resolve the same IP for
the same U-label.<br><br>
The consequence is that you need to have the ML-DNS in a single IDN
(A-label/U-label) management position, i.e. in a distinct layer that all
the applications will call. Actually when you consider that new
middle-layer, you quickly see that it can be the place for other services
to the user and that it is a network architecture new area: an Internet
use interface. This IUI is actually made of the Internet's extended
intelligence, which we do not want on a robust end to end network and
that we always have placed on the fringe. The IUI is a the Internet
fringe. Its addition leads to a fringe to fringe smart extended use of
the end to end stratum that itself is a smart use of the plug to plug
offered by the Telecom stratum.<br><br>
Then you can quickly see that this IUI can be an extension of the
Internet, and also a location for intelligent user front-ends, like the
ML-DNS is with front-ends to the Internet and other technologies, that
may share their ML-DNS, for example. Then, it becomes the Intelligent Use
Interface to serve an entire new world (different technologies) and
stratum (brain to brain semantics, what I call the Intersem). When
raising the issue with the IESG and IAB (you can see that my appeals for
clarification on their sites), you see this is implicitly the emergence
of an entirely new networking area. Therefore, one needs a special SDO
level to document and experiment it.<br><br>
I called it the "IUse" emergent community, in turn proposing an
IUTF liaising with the IETF through the iucg@ietf.org (internet/IETF
users contributing group) mailing list supported by the
<a href="http://iucg.org/">http://iucg.org</a>/wiki (I am currently
rather behind schedule for different personal and health reasons) needing
to use the Internet as a basic common central commodity and to extend it
to suit their individual needs in their own areas, at a minimum
architectural and developmental cost based on incremental simplicity.
<br><br>
Best, <br><br>
jfc<br><br>
<br><br>
At 23:59 07/04/2011, Peter Saint-Andre wrote:<br><br>
<blockquote type=cite class=cite cite="">RFC 5890 states:<br><br>
o A "U-label" is an IDNA-valid string of
Unicode characters, in<br>
Normalization Form C (NFC) and including
at least one non-ASCII<br>
character, expressed in a standard Unicode
Encoding Form (such as<br>
UTF-8). It is also subject to the
constraints about permitted<br>
characters that are specified in Section
4.2 of the Protocol<br>
document and the rules in the Sections 2
and 3 of the Tables<br>
document, the Bidi constraints in that
document if it contains any<br>
character from scripts that are written
right to left, and the<br>
symmetry constraint described immediately
below. Conversions<br>
between U-labels and A-labels are
performed according to the<br>
"Punycode" specification
[RFC3492], adding or removing the ACE<br>
prefix as needed.<br><br>
To be valid, U-labels and A-labels must obey an important
symmetry<br>
constraint. While that constraint may be tested in any
of several<br>
ways, an A-label A1 must be capable of being produced by
conversion<br>
from a U-label U1, and that U-label U1 must be capable of
being<br>
produced by conversion from A-label A1. Among other
things, this<br>
implies that both U-labels and A-labels must be strings in
Unicode<br>
NFC [Unicode-UAX15] normalized form. These strings
MUST contain only<br>
characters specified elsewhere in this document series, and
only in<br>
the contexts indicated as appropriate.<br><br>
I'm updating the i18n handling in XMPP, and the XMPP community would<br>
like to use NFD on the wire for various reasons. Ideally we would
like<br>
to do so without requiring a trip through NFC. However, it appears
that<br>
we can do this only by using a term other than U-label, since that
is<br>
tied to NFC. Indeed, it seems that a string in Unicode NFD
normalized<br>
form is not an IDN label at all. This strikes me as unfortunate (I<br>
thought that normalization was handled only in RFC 5895 along with
other<br>
such mapping issues), but probably because I do not understand how
the<br>
symmetry requirement expressed in RFC 5890 necessitates the use of
NFC.<br>
Would any of the i18n experts on this list care to enlighten me on
the<br>
latter point?<br><br>
In the meantime, I shall pursue a way to specify XMPP domainparts<br>
independently of the term U-label.<br><br>
Peter<br><br>
-- <br>
Peter Saint-Andre<br>
<a href="https://stpeter.im/" eudora="autourl">https://stpeter.im/</a><br>
<br>
<br><br>
<br><br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
Idna-update@alvestrand.no<br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a></blockquote>
</body>
</html>