Consensus Call on Latin Sharp S and Greek Final Sigma

[Andrew Sullivan]

Dear colleagues,

On Sat, Nov 28, 2009 at 06:28:22PM -0500, Vint Cerf wrote:
> Should Latin Small Letter Sharp S and Greek Small Letter Final Sigma  
> be PVALID in IDNA2008 or not:
> 
> Please Respond by choosing among the following:
> 
> (1) Both characters should be PVALID
> (2) Both characters should be DISALLOWED
> (3) Only Latin Small Letter Sharp S should be PVALID
> (4) Only Greek Small Letter Final Sigma should be PVALID

Because we have only the choices above before us, and because the
Chair has not adjusted the question to include any transitional
strategies, I am left to choose among them (since the deadline for
comments is today).

I would prefer that we come to some agreement in favour of some sort
of transitional strategy, because I believe that without such a
strategy, there will be a number of important clients that will ignore
whatever the WG concludes and do some sort of mapping prior to the
IDNA lookup stage.  The effect of this will be to have some mapping
that is effectively a part of deployed IDNA2008 without it being part
of the documents we produce.  I suspect that implementers will
collaborate but not converge perfectly on a mapping in such a case.
That will mean the worst of all worlds: we'll get subtle
incompatibilities (probably with widespread common functioning), and
yet we still will not get the benefits of these additional characters.

I therefore believe that some variant of MAYBE (such as the
suggestions for flag-day cutover with a transitional period, or my own
sketch of a negotiation protocol whereby a client can learn of zone
policy) is preferable to any of the options 1-4 above.  Despite the
lukewarm reception it garnered, I will endeavour (I hope this evening)
to outline how I think the negotiation of capabilities could be
undertaken.  I freely admit it's a fantastic kludge and willing to
accept that it's a horrible idea, but I haven't seen any other
proposals for actual gradual adoption of the characters as client
capability expands.

To me, what is most important is the overall effect on user
experience.  Whereas I do understand the objection that in the short
term, we will be faced with an extremely nasty backwards
incompatibility (such that a given IDNA target is actually ambiguous),
I believe that the harm from that is less than the harm that comes
from not delivering on our plan to get out of the way of localized
registry policy and localized experience.  I accepted the arguments at
the beginning of this work that we wanted to move towards
localization, and not just internationalization, of the name system.

Therefore, if the WG is unable or unwilling to consider alternatives
to the options the Chair presented, I must say that among the options
I prefer (1).  Mine is nevertheless a very weak endorsement, and I
urge us to concentrate on finding an acceptable transition strategy
that allows us to mitigate the obvious nasty effects of backward
incompatibility.  In particular, I am keen for us to avoid creating a
case where widespread ambiguity of identifiers happens as soon as
someone upgrades their client.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.