<div dir="ltr">My purpose is not to see the mapping incorporated into the protocol document; it is rather to provide a separate but concrete specification of what that mapping should be, along the lines of what is in <a href="http://docs.google.com/Doc?docid=dfqr8rd5_51c3nrskcx">http://docs.google.com/Doc?docid=dfqr8rd5_51c3nrskcx</a><div>
<br></div><div>That is, supply a mapping that is essentially the same as the one used in IDNA2003, but logically and consistently extended to the repertoire of any Unicode version, much like what Tables is doing in terms of rules.</div>
<div><br></div><div>My concern is that if we don't supply a precise specification of what a compatible mapping would be, we will end up with all kinds of spurious differences among mappings.</div><div><br></div>The open issue in my mind as to the draft document I put together is whether it has to be absolutely compatible with IDNA2003, or whether we can get rid of the small set of exclusions (Section 3.3 Exclusions) and the mapping errors (Section <a href="http://3.4.3.">3.4.3.</a> Retain Corrigendum #4: Five Unihan Canonical Mapping Errors), which would be rather nice to do.<div>
<br><div>Mark<br>
<br><br><div class="gmail_quote">On Mon, Jul 28, 2008 at 12:11 AM, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
--On Monday, 28 July, 2008 08:07 +0100 Paul Hoffman<br>
<div><div></div><div class="Wj3C7c"><<a href="mailto:phoffman@imc.org">phoffman@imc.org</a>> wrote:<br>
<br>
> At 12:41 AM -0400 7/28/08, John C Klensin wrote:<br>
>> As I read your note (and I would encourage anyone on the list<br>
>> who hasn't done so, and done so carefully, to fix that), I<br>
>> come away with the feeling that you assume that, in the<br>
>> absence of very specific guidance and instructions,<br>
>> implementers are likely to run wild and do things that we<br>
>> would agree are crazy.<br>
><br>
> That is one interpretation of his message. Another is that<br>
> implementers are likely to do as little as possible and do<br>
> things that we would agree are lazy. Mark's list of possible<br>
> equivalents could just as easily show non-interop due to lazy<br>
> application/IME implementers as it could to wild/crazy ones.<br>
><br>
> The IETF has a much richer history with lazy and/or rushed<br>
> implementers. It would be good for us to keep them in our<br>
> thoughts as we craft the documents.<br>
<br>
</div></div>Absolutely. If one makes the assumption of lazy and<br>
indifferent implementers and zone administrators --and, while I<br>
think the IDNA experience has been different, I certainly agree<br>
that we've seen large quantities of those in other areas-- then<br>
the odds are that we will see no mapping at all because it is<br>
easier to not do it than it is to do, much less thinks about.<br>
<div><div></div><div class="Wj3C7c"><br>
john<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></div></div></div>