<html>

<body>

Jean-Michel,<br>

you are probably right explaining all this. However, Peter is probably

not used to our customs. <br><br>

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.<br><br>

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.<br>

best<br>

jfc<br><br>

<br>

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

<br>

<blockquote type=cite class=cite cite="">2010/10/22 J-F C. Morfin

<<a href="mailto:jfc@morfin.org">jfc@morfin.org</a>><br>

<dl>

<dd>IMHO in the cookie case, there are three types of cookies:<br><br>

<dd>- 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)<br>

<dd>- 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.<br>

<dd>- those being used by the users applications that are documented by

their developers.<br><br>

<dd>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.<br><br>

</dl><br>

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.<br><br>

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. <br><br>

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.<br><br>

Best<br>

Portzamparc<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>