Although I've been arguing for a mapping phase, what I've been arguing for is one that is part of the lookup protocol, and so common across all implementations. An optional mapping -- one that is only a SHOULD -- and only for UI, is as far as I'm concerned, far worse than John's earlier version of protocol (<a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-12">http://tools.ietf.org/html/draft-ietf-idnabis-protocol-12</a>).<br>
<br>I suggest strongly we just drop the mapping document entirely, and just proceed with the previous basis: <a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-12">http://tools.ietf.org/html/draft-ietf-idnabis-protocol-12</a>.<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Sat, Jul 4, 2009 at 08:27, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com">vint@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Taking advantage of this exchange to underscore for the working group<br>
what I consider to be a remarkably perceptive observation:<br>
<div class="im"><br>
quoting from the authors:<br>
<br>
>> In the case of mapping user input, we could not give a good<br>
>> reason why this is needs to be required. It is clearly a good<br>
>> idea because it will prevent user surprise, and we say so.<br>
>> However, mapping does not promote interoperability between DNS<br>
>> clients and servers, nor between applications. Things that are<br>
>> just good ideas where the exceptions cannot be well defined<br>
>> are not, in my opinion, applicable targets of RFC 2119<br>
>> "SHOULD".<br>
<br>
</div>with the specificity of the new version of the mapping document<br>
and the rationale above as to its application, I urge the WG<br>
participants<br>
to raise any additional substantive issues promptly.<br>
<br>
We need to reach closure on all documents at the end of the first<br>
day of the meetings in Stockholm.<br>
<br>
I also suggest that the mappings document and the removal of<br>
RFC 2119 language eliminates the need for the "mapping forms"<br>
that Mark Davis suggested, since the mappings are suggested but<br>
not required. The IDNABIS framework establishes clear rules for<br>
defining what characters are allowed and what practices are<br>
recommended for registration and look up.<br>
<br>
I hope and believe that we are very close to consensus on the<br>
IDNABIS revisions.<br>
<font color="#888888"><br>
vint<br>
</font><div><div></div><div class="h5"><br>
><br>
><br>
><br>
><br>
<br>
_______________________________________________<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>