Nicolas,<br>Jean-Michel only explained you our Internet User position. The MUSTs you refer to are actually "IS/ARE". They document the way the existing DNS IS behaving. IF you want it to work properly you MUST do this, because this is the way the Internet IS.<br>
<br><div class="gmail_quote">2010/6/22 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;">

And by my reading these are very strong normative requirements.  That<br>
very first one requirement that I quote above is the most important one.<br>
It captures the essense of IDNA.<br></blockquote><div><br>There a major difference between "normative" (the way normality is) and standardizing (the way things must be). This is a global difficulty borne from the size of the systems we consider. This is what IDNA2008 addresses. Four us, this is the RFC195/RFC3439/IDNA2008 Internet architecture.<br>
 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Now, what isn't specified in as much detail is: just what is an<br>
"IDN-unaware domain name slot".  Yes, a definition is given in<br>
draft-ietf-idnabis-defs-13, but there is no exhaustive list.</blockquote><div><br>This IS the key point.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
 If anyone<br>
is going to complain about lack of normative language in IDNA2008, they<br>
should complain about the lack of an exhaustive list of IDN-aware and<br>
-unaware domainname slots. </blockquote><div><br>Here is the IDNA2008 break through. It is not a lack but an architectural dramatic progress. IDNA2008 confirms the way domainname slots ARE on the Internet (i.e. use of ASCII DNS). It _decided_ NOT to decide about the way domainname slots MUST be on the user side. This belong to the Internet use.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Of course, there's a reason such a list is<br>
missing: we need to consider all domainname slots on a case-by-cases<br>
basis, and the IDNAbis WG couldn't have tackled that job.<br>
<br>
I think the lack of an even of small subset of these slots is a problem<br>
-- not a huge problem, but it is a problem.  I also think that more<br>
guidance to protocol designers, and to developers, would be nice -- if<br>
it weren't so late, I might insist on it.  However, I think there's<br>
enough for us to get by, and any guidance that could be given couldn't<br>
be normative.<br></blockquote><div><br>Yeap. Internet side designers can normalize (IS/ARE) or standardize (MUST) what is inside the Internet system, not what is outside.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


For example, in the NFSv4 WG we're discussing what to do about NFSv4's<br>
domainname slots.  First we need to establish how they are handled by<br>
existing implementations.  For at least some, if not all<br>
implementations, NFSv4's domainname slots are handled in an IDN-unaware<br>
fashion right now.  But that's not entirely dispositive: we could<br>
consider a) the cost and likelihood of fixing the deployed base, and b)<br>
interoperability options when "legacy" deployments exist, and we could<br>
conclude that we'd rather have these slots be declared IDN-aware in<br>
spite of their current treatment.  (We're still working this out in the<br>
NFSv4 WG; we've not made any decisions yet.)<br></blockquote><div><br>You are in the situation of every protocol designer having to use IDNs. This is why there is a missing IAB guidance, so we speak of the same thing (currently we do not). There is no definition given so far of what an IDN is. The one we use is "Internet Domain Name", because  they are supported by the Internet. But there are many other kind of names in use that are or could be used on the Internet and interoperably outside of the Internet.<br>
<br>IDNA2008 has documented that/how the Internet supports IDNs under their A-label "xn--" form. Thats all. The "Mapping" document went further, outside of the WG/IETF existing scope (making the internet work better). Here we discuss making the Internet used better.<br>
<br></div><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">
> I have initiated the <a href="mailto:workon@idna2010.org">workon@idna2010.org</a> mailing list to discuss that<br>
> "MUST"s and their relations with IDNA2008 "IS/ARE"s, and we reserved<br>
<br>
</div>Your claims regarding IDNA2008 and lack of normative language in it are<br>
clearly incorrect. Your invitation to join yet-another mailing list<br>
isn't exactly winning me over.<br></blockquote><div><br>No one is interested in discussing the issue (being already on that list or not) before IAB says where the standardizing language you/we call for is to be discussed and how.<br>
<br>Best.<br><br>Stephane Lancel<br></div></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>