UTF-8

Sat Jun 19 10:22:36 CEST 2010

Dear Nicolas,
The points you raise from your perspective are those we raise from our
Internet Users' perspective. I am not familiar with your area but for two
years we met the same problem we analysed in terms of "IS/ARE, MUST, SHOULD,
MAY" interoperation. The major IDNA2008 is the switch of the MUST from the
Internet system, to the internet use interface (we named "internet peritem"
to get a clear difference) that itself is related to the User Inteface of
applications of the present/future "internet exotem".

You join us in calling for "MUST"s that permit interoperability and you call
for someone issuing these MUSTs. There is no MUST in IDNA2008, there only
are "IS/ARE". IDNA2008 says the way the Internet System is (DNS), period
(IS/ARE). Now, we need someone to tell/some place to discuss how we MUST
relate with these "IS/ARE" for the things to work. Then developpers will be
able to adapt in using the SHOULDs that Andrews describes: they will
interface these MUSTs (on the peritem side) and the users MAYs on the
external side, i.e. the Internet exotem.

This is for IETF an "unusual" case ("unusual" is the core word of the
WG/IDNABIS "Mapping" consensual document killed by the IESG): the IETF meets
the new "IS/ARE" level and has to get MUSTs defined _outside_ of its usual
scope/area.

I have initiated the workon at idna2010.org mailing list to discuss that
"MUST"s and their relations with IDNA2008 "IS/ARE"s, and we reserved
"IDNA2012.org" to the further discussion of the SHOULD between the Internet
use MUST (how one external system MUST use the Internet) and what users MAY
want to do. We used the 2008/2010/2012 sequence to underline that this is
not an IDNA versioning (as ccNSO started to imply) but a layer continuity.

Debates with the WG/IDNABIS Chair, however shown that this
workon at idna2010.org work was premature as long as there was not a community
agreement on what you ask: who is to discuss, and where, that MUST part,
along which lines. This is why JFC Morfin introduced his appeal, as an
operational user missing an answer, like you.

This is because, if from the very begining we have a response we work on
(ML-DNS - multi-layer DNS which matches the IAB I_D demand), if we have
commited that it will come atop of IDNA2008, and we have been consensual
with IDNA2008 because it enforces no MUST that would conflict with ours, we
do not want to introduce a super "NAT-like" problem without prior IAB
guidance.

Along our scheme, your threads do not belong to the IDNABIS mailing list
which has completed its work (cf. Charter) but to our  http://IDNA2010.org
workon at idna2010.org mailing list - _once_ its context has been commented by
IAB. You discuss interop with your Internet area needs. As users we also
have concerns of interoperability with the so called "ICANN domain name
industry" and its adminance, with other digital technologies, and with what
really interests us: the Intersem (semiotic Internet of subjects). Interop
with Microsoft Kinect is what is of prime interest. UTF-8 and IDN is just an
analogy for the "Natale-codeset" by Microsoft or IETF and image domain names
(IDNs).

There is still a long way to go. From the rock solid basis of IDNA2008 which
has no MUST and has split the Internet from the Unicode limitations without
repudiating its huge contribution.

Portzamparc

2010/6/19 Nicolas Williams <Nicolas.Williams at oracle.com>

> On Fri, Jun 18, 2010 at 05:33:00PM -0400, Andrew Sullivan wrote:
>  > > In this context I don't care what "longtime IETF participants" think.
> > > I care what the middleboxes do.
> >
> > Never mind middleboxes (because yes, they make life complicated).
> > Think just about applications that think they're doing reasonable DNS
> > sanity-checking.  There are _still_ places I can't put my .info email
> > addresses, because of some heuristic that no TLD is longer than 3
> > characters.  We're not even into the interesting problems, and we're
> > already broken.
>
> I don't care to broaden the scope of what we should concern ourselves
> with to include Joe Sixpack's website's user registration form that
> "validates" domainnames.
>
> > If I've read you right, you want to say what people MUST do.  I think
> > that's a mistake.  I think the best advice is to say that certain
> > practices maximize interop, that using either of A-label or U-label
>
> Of course we must say what implementors MUST do if we want interop!  In
> fact, we couldn't have interop if we didn't.  (Well, we can always
> interop with non-IDNs, but interop with IDNs is exactly the point here.)
>
> If there's any place where we can't decide what an implementor MUST do
> to achieve IDN interop then it must be the case that either we don't
> have enough information or we can't reach consensus on one approach or
> another because there is no common approach that wouldn't be costly to
> some significant part of the deployed base's users.  And even then
> nothing stops us from reaching consensus on some requirement eventually.
>
> > (with adequate type checking) will work, and that it would probably be
> > best to settle on [pick one.  I prefer A-label, but I don't care that
> > much because they're freely convertible].  If the latter is what
> > you've been saying, I am sorry that I so badly misunderstood.
>
> I think every domainname slot has to be taken on a case-by-case basis.
> We already have IDNA rules for a number of domainname slots.  Some slots
> we'll be able to declare as IDN-aware and we'll be able to allow
> U-labels and even raw Unicode in them (because the receipient will be
> able to apply ToASCII() and/or ToASCII(ToUnicode()) as necessary.  Some
> slots we'll have to declare as IDNA-unaware and restrict them to
> A-labels [if we want IDN interop].
>
> Nico
> --
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20100619/e943dd20/attachment-0001.html>