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

Mark Davis mark at macchiato.com
Wed Nov 5 15:39:24 CET 2008


I hadn't had a chance to read the new documents, but will do so.
Mark


On Wed, Nov 5, 2008 at 5:55 AM, John C Klensin <klensin at jck.com> wrote:

> 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.
> >...
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081105/315b36d1/attachment.htm 


More information about the Idna-update mailing list