Eszett again (was Re: Parsing the issues and finding a middle ground -- another attempt)

[John C Klensin]

--On Thursday, March 05, 2009 10:21 -0800 Erik van der Poel
<erikv at google.com> wrote:

> Marcos,
> 
> Thank you for publicly posting DENIC's historical and current
> positions on Eszett.
> 
> I don't know where this leaves us. John's "add lower-case
> mappings only" suggestion and the more recent "try IDNA2008
> first, then map a la IDNA2003" suggestion give the impression
> that at least one member of the WG appears to be willing to
> add some mappings to the base specs (definitions, protocol,
> table, bidi and rationale), if I have understood John's
> suggestions correctly.
>...

For whatever my personal view is worth, let me clarify the above.

I'm thrashing around, looking for some position on which we
might be able to find consensus and move forward.  That includes
posting some suggestions that I think are bad ideas and that I
can just barely live with.  So far, I've made three such
suggestions in the hope of stimulating discussion about them and
seeing whether there is any chance we could converge on them.
In the order in which they were posted:

(1) Map to lower case only.  No compatibility-character
mappings, no mappings that depend on CaseFold.  This one didn't
get very far, but I note that, since the Eszett -> "ss" mapping
depends on CaseFold (and the Final Sigma -> Lower Case Sigma
does too), it wouldn't have helped much with this.  

(2) Map on lookup only for IDNA2003 compatibility only, and only
after verifying (in most cases) that the IDNA2008 rules do not
resolve to a DNS entry.  I consider that to be a transition
plan, rather than a mapping one, even if the effects on a given
lookup of a given label are much the same.  In particular, if I
were writing guidelines for zone administrators (an activity
that might fall within the scope of the Rationale document, but
probably does not), I would strongly encourage them to stop
registering anything that might depend on IDNA2003 mappings and
would, to the extent possible, also encourage those constructing
web pages, etc., to avoid those dependencies as an invitation to
confusion even if not outright attacks.

(3) Keep mapping out of IDNA2008 entirely, but treat it as a
part of IRI -> URI transformation, with only A-labels in URIs
and the mapping conventions potentially protocol-dependent.

FWIW, only the third of these avoids the need for any discussion
with the IESG, discussion that might or might not require a full
rechartering exercise and even more delay.  Getting this right
is, IMO, more important than the risk of a little [more] delay,
but the delays are really getting painful.

As an aside, I realized a few hours ago, in the process of
working on a non-WG document, that there is actually a conflict
(or at least a serious tradeoff) between mapping and variant
approaches.  Watch for a note on that subject.

     john