Esszett, Final Sigma, ZWJ and ZWNJ

[Paul Hoffman]

At 1:48 PM -0500 2/23/09, John C Klensin wrote:
>I'm having trouble understanding your position (and Paul's).
>The charter rather specifically says that we can consider and
>make incompatible changes:
>
>	"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."
>
>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.  But (i) that is explicitly an "additional
>goal", not a "general constraint".   And (ii) even if it were a
>"general constraint", reading it to prohibit this case would, I
>believe, require reading it to prohibit _any_ change that is not
>strictly backward-compatible with IDNA2003 and that would
>completely contradict the provision quoted above.

Note the word "strictly" in "strictly backwards-compatible". Some of us think, I think with justification, that it means there was room for variance as long as other parts of the charter were not messed with. Making some characters that were prohibited in IDNA2003 now allowed clearly meets this requirement; so does prohibiting some characters that were allowed in IDNA2003 now prohibited. Changing the bits-on-the-wire representation of labels does not meet that, particularly when combined with the prohibition on changing the Punycode prefix.

In any other IETF protocol, if you are going to change the bits on the wire and you have an unambiguous method to flag that change, such flagging would be required. I am having trouble understanding why you think this protocol is special.