Esszett, Final Sigma, ZWJ and ZWNJ

[Andrew Sullivan]

On Mon, Feb 23, 2009 at 01:48:57PM -0500, John C Klensin wrote:

> Andrew, I hate engaging in protocol-lawyering, especially about
> charters

Me too.  Let me try to be clearer, though, that all I'm really trying
to do is work out whatever compromises we can here in this WG, where
those interested in the topic are congregated, rather than having some
later fight at the IETF last call.  My impression is that different
people have very different ideas of what the WG was setting out to do,
and if we can't come to some agreement now (even if it's belated --
it'd have been nice to settle this during charter writing) then we're
going to have to do it later, during IETF LC or appeals or something.
In the interests of actually getting the technology out the door, I'd
prefer to have the argument here.  

> 	"Subject to the more general constraints described
> 	above, the WG is permitted to consider changes that are
> 	not strictly backwards-compatible.  For any such change
> 	that is recommended, it is expected to document the
> 	reasons for the change, the characters affected, and
> 	possible transition strategies."

That text is in fact exactly why I thought these characters were in
play from the outset.  But not everyone seems to have formed the same
impression, possibly because there would clearly be new characters,
not allowed under IDNA2003 (but not mapped), which would become
permitted; that would also be a change that was not strictly
backwards-compatible, but which would, some think, be less controversial.
 
> Now, I suppose one could read "- Ensure practical stability of
> validity algorithms for IDNs." as one of those "general
> constraints" and prohibiting _any_ change that is not strictly
> backward-compatible.  

I don't know that I buy that.  There is clearly a difference between
allowing characters that didn't used to be allowed, and changing the
mapping of formerly-mapped characters.  In the former case, the change
is not strictly backwards-compatible: older IDN libraries will not
allow the characters, even though they are valid under the new IDNA
rules.  That would mean that old libraries would sometimes reject
U-labels made with those characters, even though the U-label is legal
under the new regime.  The latter case, however, takes a U-label that
under the old system has a wire representation of R, and changes the rules
so that the same U-label under the new system has a wire
representation of R''.  One can construct a pretty strong argument
that this is a protocol version change affecting the "wire" format of
the protocol (even though the "wire" turns out to be "ascii label in
DNS"); and that it therefore needs a protocol version indication.
Since we _have_ a handy protocol version identifier in "xn--"  it
should not be a big deal to change the protocol version, and therefore
we should do it.  But that's also not allowed under the charter.

So, that's the argument I expect people to make.  In case I haven't
made this clear enough, it's _not_ an argument I am making, and it's
not one that I am sure I buy.  But in the interests of trying to
hammer out a consensus in this WG, I think it's an argument we should
take very seriously.  In particular,
 
> (ii) the claim that eliminating the mapping of these character
> (which the charter requires) violates the provision that "the
> DNS [to] continue to allow any system to resolve any domain name
> in a consistent way"... But, again, this is about the domain
> names in the DNS, as evidence by the use of "any system".   But
> an ACE-based string that is valid under IDNA2003 will resolve to
> exactly the same thing and in exactly the same way in IDNA2008.

I think we need to stop relying on the arguments that nothing is
changing in the DNS.  Everyone involved understands perfectly well
that the actual labels in the DNS are not affected.  But I think it
entirely plain that no actual user in the world cares a tinker's dam
whether the "domain name" is a "DNS name" or an "IDNA name".  Plainly,
if we weren't trying to hide the difference in important ways, we'd
never do IDNA in the first place.  And there is plainly a
straigtforward problem that, under IDNA2003, someone typing in
fußball.tld actually goes to "fussball.tld"; and under IDNA2008, it
goes somewhere else.  

I agree with you that _not_ eliminating the mapping would also violate
the charter.  That's another reason I figured the characters had to be
up for consideration anyway; but someone else could read that as "the
charter is incoherent."  

> Rationale already discusses options for registries to manage
> this change, as required by the provision for
> non-backward-compatible changes quoted above. 

Yes.  I don't actually think the WG needs to produce any document on
this; sorry if I wasn't clear about it.  I just think that having a
couple worked out examples of how one could do it (Cary provided one
earlier, and it was exactly the sort of thing I had in mind) would
help a great deal in illustrating how this problem is managable.

I think I've said enough on this topic, also, because (as I've
tried to make clear) I long ago assumed we were going to introduce
this incompatible change.  

(I honestly never understood the reluctance to add a new prefix -- to
me, that's the easiest way to solve this, and it's a trivial database
operation to create "version 2" names under such a protocol change, so
if I were running a registry, it'd be my preference.  But I know that
actual registry people objected strenuously to such a suggestion.  And
let me be clear that I don't want to open that as a topic for
discussion now.)

Best,

A

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