local mappings

[John C Klensin]

Paul,

We may need to agree to disagree about this.  The conclusions of
the rest of the WG --and, to the extent to which we can
understand it-- the rest of the Internet community and
particularly the people   more affected in the non-ASCII scripts
in their everyday lives than you or I are -- are more important.
I'm been traveling internationally for the last several years
and attending a lot of meetings.  Some of those meetings and
trips have been specifically related to IDN-related topics.
Others have not, but that fact has, many times, not prevented me
from getting a lot of input on these issues.    Before I stopped
going to ICANN meetings, I was hearing a lot there too and have
since been hearing from Cary, Tina, and others who are still
involved.  I've heard from registrars, registries, and end users
(many of each).  And, with two qualifications, everything I said
in my note is an accurate reflection of those discussions.

Those qualifications are:

(1) You misread my "all of the mappings in IDNA2003" comment.
You read it as hyperbole, presumably that I was suggesting that
every mapping was a problem.   I intended "all" as in "the very
large number of mappings in IDNA2003:".

(2) To a certain extent, each person has his or her favorite
mapping and is willing to dispense with most or all of the
others.  It seems to me that there are three ways to deal with
that observation, two of which are obvious and, at least
conceptually, fairly easy:

	(i) Put all of the desired mappings into the spec.  I
	note that I've heard requests for mappings that go
	beyond those in IDNA2003, often justified by "if you are
	going to do _those_, you should certainly support
	_mine_".  
	
	(ii) Draw the line at "having no mappings at all makes
	everyone equally unhappy and has some other advantages".
	
	(iii) Try to find some middle ground.

Ignoring, for the moment, the issue of information preservation
and reverse mapping (see below), the first is guaranteed to
leave some people unhappy and to leave the IETF either in the
position of making a lot of very subtle and script-specific (or
usage-specific) decisions or trying to blame any decision people
don't like on Unicode.  Remember, in that regard, that some
decisions that may be entirely correct for the very large set of
applications of Unicode may not be appropriate for people's
perceptions of what works well in IDNs, conditioned by
traditional DNS "exact match" constraints.  Some of the other
input I've gotten makes it very clear that assigning blame,
rather than getting things right, is neither acceptable nor
useful.  YMMD and, based on your knowledge and whatever
communities you have gotten input from, probably does.

Because the second has proven difficult in terms of an adequate
explanation of local -- "if you think those are the same, map
them before the putative label gets to IDNA and make sure that
nothing that requires mapping appears on the wire" -- mappings,
I thought it was worthwhile exploring the third.  If Vint tells
me that exploration of out of charter and that I should stop, I
will promptly do so.   But, at the moment, I think it is clearly
more desirable to find out whether there is a position on which
we can agree than to try to simulate protocol-lawyer action on
the charter.  

FWIW, I believe that _adopting_ any mappings into the protocol
would require a modification or exception to the charter, since
"no mapping" is one of the "requires rechartering" listed in the
three points at the end of the description.  Whether even
raising that possibility is out of order is, IMO, up to the
Chair... but, if it position is that it is, then, IMO, so are
both your substantive suggestions and your recharter proposal on
this mailing list.  I think that position would lead us into a
silly state, but, again, YMMD.

My reading of the charter is that everything we have actually
agreed to do, and everything that is reflected in the documents
so far, is clearly within charter, too much optimism about
scheduling notwithstanding.  Please note in particular the 11th
full paragraph of the description, which begins:

	"Subject to the more general constraints described
	above, the WG is permitted to consider changes that are
	not strictly backwards-compatible."

That seems fairly clear to me.  The rest of that paragraph
requires us to document those changes.  If you don't think we
have done an adequate job of that documentation, please send
proposed text.

Finally, "the mappings were never meant to be two-way." is
certainly a correct statement about IDNA2003.  The contention is
that having two-way mappings is a better decision and an
important one, not that the decisions of IDNA2003 were not what
they were.

regards,
   john

--On Monday, January 26, 2009 6:18 PM -0800 Paul Hoffman
<phoffman at imc.org> wrote:

> At 8:26 PM -0500 1/26/09, John C Klensin wrote:
>> Reasonable people may disagree, but we've gotten very clear
>> signals that all of the mappings of IDNA2003 were bad news.
> 
> Reasonable people do disagree. The hyperbole about "all of" is
> particulary silly.
> 
>> They create, rather than reduce confusion, especially since
>> information is lost in the reverse mappings. 
> 
> That is a very old straw man. The mappings were never meant to
> be two-way.
>...