referencing IDNA2008 (and IDNA2003?)

[J-F C. Morfin]

Jean-Michel,
you are probably right explaining all this. However, Peter is 
probably not used to our customs.

So, let me add that for the time being the IUCommunity focuses on 
developping an experimentation ML-DNS in public domain (matters 
documented on IETF lists are subject to ISOC Copyrights). We hoped we 
could have a non-copyrighted stream, but for the time being, IESG and 
mostly IAB have been clear enough: IUI issues are either research or 
non-IETF scope. This is why we also setting up an IU task force that 
will be able to document the IU issues as public domain. Their 
further presentation as IETF documents will be subject to ISOC 
Copyright, but not their content. Also, the IUCommunity being young 
and testing having not begun yet on U-labels, nothing says that 
ourcurrent vision will even stay around.

So, according to the precautionary principle of least user surprise, 
better we stay in our respective areas. And Internet IETF RFCs stay 
within the boundaries of lowercase A-Labels.
best
jfc


At 14:37 22/10/2010, jean-michel bernier de portzamparc wrote:


>2010/10/22 J-F C. Morfin <<mailto:jfc at morfin.org>jfc at morfin.org>
>IMHO in the cookie case, there are three types of cookies:
>
>- those documented as part of the Internet technology, subject to 
>standard track document, that can only document their use within the 
>Internet Iron Curtain (i.e. lowercase A-labels)
>- those being used by IUI level applications that are to be 
>documented by the Internet Users community that can be documented 
>through BCP or for information like RFC 5895.
>- those being used by the users applications that are documented by 
>their developers.
>
>The IU community has many needs and solutions that can be supported 
>in respecting the now existing and confirmed Iron Curtain 
>separation. Let try to not erode it and create instability.
>
>
>I just wish to add, for Peter to best understand, that "U-labels" as 
>conceived by the IUCommunity  may be transformed into lowercase 
>A-label with many different "presentation prefixes" (other than 
>"xn--") and from many non U-labels origins (like user gesture, 
>computed result, audio input, sentences, Netix commands, etc.) that 
>may only be occasionnally used on the Internet. The ML-DNS implies a 
>domain name stack (different classes) that may be used as their 
>class IN lowercase A-Label occurence.
>
>In the future we will strive to document a UN class that will 
>support a non homographically confused NUCS (network universal 
>character set) UCS subset for ML-DNS unique registrations (avoiding 
>confusion like .br and .6r) on a first come first served basis.
>
>Last but no least we plan to fully use not only the identification 
>(centralized management), but also designation (individual 
>management) and communication (mutual management) capacities. 
>Therefore, only the Internet DNS (i.e. lowercase A-Label IN and 
>further UN classes as accepted by the Internet community (presently 
>the IEISOCANN enhanced cooperation IANA root file)) is considered as 
>being in the IETF standard track area.
>
>Best
>Portzamparc
>
>
>_______________________________________________
>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/20101022/ad7a78f2/attachment.html>