draft-klensin-idnabis-protocol-04 section 4.5

[John C Klensin]

--On Thursday, 27 March, 2008 17:24 +0100 Simon Josefsson
<simon at josefsson.org> wrote:

> Now that I understand the situation, I would completely agree
> with you.
> 
> This discussions makes me unsure whether the core 4
> specifications can obsolete RFC 3490.  Some aspects of what's
> provided by RFC 3490 (guidelines for applications) will not be
> provided by the new RFC's, it seems.  I think the WG charter
> sends a rather different message.
> 
> Given that this is a -bis effort, I would prefer having a
> standard mapping that is compatible with IDNA2003, to bridge
> old implementations to new ones.

Simon,

Without judging the answer let me tie this discussion with one
that has occupied a lot of time on the list (if you look in the
archives, look for "Sharp S" and/or "Eszett" in subject lines.
In recent years, several people have argued with great passion
and citations to German orthographic authorities that Sharp S
should be treated as a normal character and that it was a
significant and offensive mistake in IDNA2003 to map it to "ss".
I don't want to restart that argument -- I don't know how to
resolve it and I certainly can't provide any new information
that would help -- but, if that position prevails, we would also
end up with an incompatible change because IDNA200X would accept
the character, encode it with punycode, and look it up or put it
into the zone.

So the WG actually has three cases to examine, not two:

	*  Sharp S mapped to "ss" and "ss" used to form domain
	names, even if the relevant domain name is not an IDN
	(the IDNA2003 approach).
	
	* Sharp S disallowed and possibly mapped to "ss" outside
	the IDNA protocol (the current IDNA200X approach)
	
	* Sharp S treated as a Protocol-Valid latter.

Unsurprisingly, one of the arguments against the third option is
incompatibility.  While the first two options are compatible
with each other if mapping is done on a pre-processing basis and
standardized (see Mark's note -- I disagree, but will wait until
the WG gets going before repeating myself about the reasons),
the third is not compatible and requires either accepting the
incompatibility or considering the dreaded prefix change.

best,
    john