Dear Nicolas,<br>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".<br>
<br>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.<br>
<br>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.<br>
<br>I have initiated the <a href="mailto:workon@idna2010.org">workon@idna2010.org</a> 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.<br>
<br>Debates with the WG/IDNABIS Chair, however shown that this <a href="mailto:workon@idna2010.org">workon@idna2010.org</a> 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. <br>
<br>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.<br>
<br>Along our scheme, your threads do not belong to the IDNABIS mailing list which has completed its work (cf. Charter) but to our  <a href="http://IDNA2010.org">http://IDNA2010.org</a> <a href="mailto:workon@idna2010.org">workon@idna2010.org</a> 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).<br>
<br>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.<br><br>Portzamparc<br><br><div class="gmail_quote">
2010/6/19 Nicolas Williams <span dir="ltr"><<a href="mailto:Nicolas.Williams@oracle.com">Nicolas.Williams@oracle.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Fri, Jun 18, 2010 at 05:33:00PM -0400, Andrew Sullivan wrote:<br>
</div><div class="im">
> > In this context I don't care what "longtime IETF participants" think.<br>
> > I care what the middleboxes do.<br>
><br>
> Never mind middleboxes (because yes, they make life complicated).<br>
> Think just about applications that think they're doing reasonable DNS<br>
> sanity-checking.  There are _still_ places I can't put my .info email<br>
> addresses, because of some heuristic that no TLD is longer than 3<br>
> characters.  We're not even into the interesting problems, and we're<br>
> already broken.<br>
<br>
</div>I don't care to broaden the scope of what we should concern ourselves<br>
with to include Joe Sixpack's website's user registration form that<br>
"validates" domainnames.<br>
<div class="im"><br>
> If I've read you right, you want to say what people MUST do.  I think<br>
> that's a mistake.  I think the best advice is to say that certain<br>
> practices maximize interop, that using either of A-label or U-label<br>
<br>
</div>Of course we must say what implementors MUST do if we want interop!  In<br>
fact, we couldn't have interop if we didn't.  (Well, we can always<br>
interop with non-IDNs, but interop with IDNs is exactly the point here.)<br>
<br>
If there's any place where we can't decide what an implementor MUST do<br>
to achieve IDN interop then it must be the case that either we don't<br>
have enough information or we can't reach consensus on one approach or<br>
another because there is no common approach that wouldn't be costly to<br>
some significant part of the deployed base's users.  And even then<br>
nothing stops us from reaching consensus on some requirement eventually.<br>
<div class="im"><br>
> (with adequate type checking) will work, and that it would probably be<br>
> best to settle on [pick one.  I prefer A-label, but I don't care that<br>
> much because they're freely convertible].  If the latter is what<br>
> you've been saying, I am sorry that I so badly misunderstood.<br>
<br>
</div>I think every domainname slot has to be taken on a case-by-case basis.<br>
We already have IDNA rules for a number of domainname slots.  Some slots<br>
we'll be able to declare as IDN-aware and we'll be able to allow<br>
U-labels and even raw Unicode in them (because the receipient will be<br>
able to apply ToASCII() and/or ToASCII(ToUnicode()) as necessary.  Some<br>
slots we'll have to declare as IDNA-unaware and restrict them to<br>
A-labels [if we want IDN interop].<br>
<br>
Nico<br>
<font color="#888888">--<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br><div style="visibility: hidden; display: inline;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup {  position:absolute;  z-index:9999;  padding: 0px 0px;  margin-left: 0px;  margin-top: 0px;  width: 240px;  overflow: hidden;  word-wrap: break-word;  color: black;  font-size: 10px;  text-align: left;  line-height: 13px;}</style>