I hadn't had a chance to read the new documents, but will do so.<div><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Wed, Nov 5, 2008 at 5:55 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;">
Mark (and others),<br>
<br>
Please read my from last weekend about the new documents and the<br>
new section 7.2 of Rationale for another approach to handling<br>
this and some proposed text. Also note that Rationale contains<br>
(and has contained since before the WG started) a summary of the<br>
analysis of the implications of changing the prefix.<br>
<br>
That text, especially the new text, may or may not be what the<br>
WG wanted, but I thought that getting a specific textual<br>
proposal on the table to which people could react was probably a<br>
good idea.<br>
<br>
Three comments based on other notes in this and other threads:<br>
<br>
(i) Because of criticisms that some of the text of Rationale was<br>
too tentative and read too much like a proposal to be considered<br>
for publication, I've gone through it and changed the statements<br>
to assume that they represent WG consensus and conclusions. The<br>
new material in 7.2 is written in that same tone and tense.<br>
This doesn't make the material any more permanent if there are<br>
WG disagreements with it; it is just a change in style that some<br>
people asked for.<br>
<br>
(ii) I don't see the Eszett (or Final Sigma) changes as being<br>
very much different in practice from a problem we have had to<br>
deal with several times before when new label forms or options<br>
have been introduced into the DNS. The creation of new gTLDs<br>
after many years of the assumption that there would be no more<br>
after .INT was introduced meant that provisions needed to be<br>
considered for those who already had established labels in other<br>
domains. The introduction of IDNs required consideration of<br>
whether special treatment should be given to those who already<br>
had ASCII representations of their preferred labels, especially<br>
when the IDN label contained a few extended Latin characters but<br>
most of the label was in ASCII. Alternate spelling issues,<br>
even within non-Latin scripts, required consideration of whether<br>
those spellings should be caused to match and how to do that.<br>
<br>
For different cases, and in different places, we've seen<br>
different approaches. DNS search rules have been pulled out,<br>
dusted off, and adapted. We've seen suggestions about<br>
application of variant rules at lookup time although I don't<br>
think anyone has actually implemented it. Both of those<br>
approaches require multiple lookups for the same name and<br>
decisions about which string takes priority.<br>
We have also seen application of registration-based approaches,<br>
with different registries using many variations on "sunrise"<br>
procedures, several variations of variants (RFC 3743 describes<br>
an approach and a method to identifying a bundle of names, but<br>
treats the decision about what to do with the bundle as an<br>
external policy matter), and a few flavors of "registrants<br>
beware and use dispute resolution policies if needed".<br>
<br>
IMO, none of the above have worked perfectly, but they were<br>
necessary to expanding capabilities and choice and to permit us<br>
to introduce IDNs at all. Taking different approaches in<br>
different registries -- and treating the issues largely as<br>
registration-side ones-- has caused some inconvenience and<br>
confusion (I would argue that no approach would have been much<br>
different on that dimension).<br>
<br>
You may disagree with some or all of the above, but the<br>
experience has clearly been that, while there have been rough<br>
edges, there have been no meltdowns either<br>
procedurally/administratively or in DNS operations.<br>
<br>
As far as the tradeoff between a dual lookup for labels<br>
containing either of these characters and a new prefix is<br>
concerned, while I don't personally believe that either option<br>
is a good idea for the general case (see the discussion in<br>
Rationale), I note that a new prefix would require either<br>
abandoning all IDNA2003 registrations (implausible) or a dual<br>
lookup for _every_ label containing one or more non-ASCII<br>
character. Unless one argues that doubling the number of DNS<br>
queries would have an insignificant operational effect, I'd<br>
assume the latter would be operationally significant.<br>
<br>
john<br>
<br>
<br>
<br>
--On Tuesday, 04 November, 2008 17:51 -0800 Mark Davis<br>
<<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>> wrote:<br>
<br>
> It is still premature to add eszett and final sigma until we<br>
> have some accompanying text that addresses the security<br>
> exploit. The two possibilities I could think of are:<br>
><br>
> 1. Change the prefix for xn--<br>
> 2. Recommend or require that if the name contains either<br>
> eszett or final sigma, that any DNS lookup by client<br>
> software has to be done twice: once with the original, and<br>
> once with a second string that has these remapped to "ss"<br>
> and sigma respectively, and is then NFC'ed.<br>
><br>
> Mark<br>
><br>
><br>
> On Tue, Oct 21, 2008 at 11:38 PM, Mark Davis<br>
> <<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>> wrote:<br>
><br>
>> About eszett, I think we are still waiting on proposed text<br>
>> on the security issue. If the security and interoperability<br>
>> issues can be addressed, I'm happy with allowing eszett, but<br>
>> we haven't seen any text yet, and thus cannot make a firm<br>
>> assessment.<br>
>...<br>
<br>
<br>
<br>
</blockquote></div><br></div>