Eszett and Final Sigma (was: Re: Consensus Call Tranche 8 Results)

[John C Klensin]

Mark (and others),

Please read my from last weekend about the new documents and the
new section 7.2 of Rationale for another approach to handling
this and some proposed text.  Also note that Rationale contains
(and has contained since before the WG started) a summary of the
analysis of the implications of changing the prefix.

That text, especially the new text, may or may not be what the
WG wanted, but I thought that getting a specific textual
proposal on the table to which people could react was probably a
good idea.

Three comments based on other notes in this and other threads:

(i) Because of criticisms that some of the text of Rationale was
too tentative and read too much like a proposal to be considered
for publication, I've gone through it and changed the statements
to assume that they represent WG consensus and conclusions.  The
new material in 7.2 is written in that same tone and tense.
This doesn't make the material any more permanent if there are
WG disagreements with it; it is just a change in style that some
people asked for.

(ii) I don't see the Eszett (or Final Sigma) changes as being
very much different in practice from a problem we have had to
deal with several times before when new label forms or options
have been introduced into the DNS.  The creation of new gTLDs
after many years of the assumption that there would be no more
after .INT was introduced meant that provisions needed to be
considered for those who already had established labels in other
domains.  The introduction of IDNs required consideration of
whether special treatment should be given to those who already
had ASCII representations of their preferred labels, especially
when the IDN label contained a few extended Latin characters but
most of the label was in ASCII.   Alternate spelling issues,
even within non-Latin scripts, required consideration of whether
those spellings should be caused to match and how to do that.

For different cases, and in different places, we've seen
different approaches.  DNS search rules have been pulled out,
dusted off, and adapted.  We've seen suggestions about
application of variant rules at lookup time although I don't
think anyone has actually implemented it.  Both of those
approaches require multiple lookups for the same name and
decisions about which string takes priority.  
We have also seen application of registration-based approaches,
with different registries using many variations on "sunrise"
procedures, several variations of variants (RFC 3743 describes
an approach and a method to identifying a bundle of names, but
treats the decision about what to do with the bundle as an
external policy matter), and a few flavors of "registrants
beware and use dispute resolution policies if needed".  

IMO, none of the above have worked perfectly, but they were
necessary to expanding capabilities and choice and to permit us
to introduce IDNs at all.  Taking different approaches in
different registries -- and treating the issues largely as
registration-side ones-- has caused some inconvenience and
confusion (I would argue that no approach would have been much
different on that dimension).

You may disagree with some or all of the above, but the
experience has clearly been that, while there have been rough
edges, there have been no meltdowns either
procedurally/administratively or in DNS operations.

As far as the tradeoff between a dual lookup for labels
containing either of these characters and a new prefix is
concerned, while I don't personally believe that either option
is a good idea for the general case (see the discussion in
Rationale), I note that a new prefix would require either
abandoning all IDNA2003 registrations (implausible) or a dual
lookup for _every_ label containing one or more non-ASCII
character.  Unless one argues that doubling the number of DNS
queries would have an insignificant operational effect, I'd
assume the latter would be operationally significant.

    john



--On Tuesday, 04 November, 2008 17:51 -0800 Mark Davis
<mark at macchiato.com> wrote:

> It is still premature to add eszett and final sigma until we
> have some accompanying text that addresses the security
> exploit. The two possibilities I could think of are:
> 
>    1. Change the prefix for xn--
>    2. Recommend or require that if the name contains either
> eszett or final    sigma, that any DNS lookup by client
> software has to be done twice: once    with the original, and
> once with a second string that has these remapped to    "ss"
> and sigma respectively, and is then NFC'ed.
> 
> Mark
> 
> 
> On Tue, Oct 21, 2008 at 11:38 PM, Mark Davis
> <mark at macchiato.com> wrote:
> 
>> About eszett, I think we are still waiting on proposed text
>> on the security issue. If the security and interoperability
>> issues can be addressed, I'm happy with allowing eszett, but
>> we haven't seen any text yet, and thus cannot make a firm
>> assessment.
>...