Re: ToUnicode output can be longer than input

--On Wednesday, 30 April, 2003 14:21 +0200 Dan Oscarsson 
<[email protected]> wrote:

> Unless I remember wrong, IDNA defines a way to compare names
> in ASCII context because it requires names to be in IDNA ACE
> format. Comparing names in an international context must be
> done using UCS characters directely.
>
> At the moment, unfortunately, IDNA restricts the way domain
> names can be written and what characters can be used, partly
> due to its way to handle domain names in legacy protocols. It
> was possible to handle it better, but was not chosen so.
>
> I do not want to limit domain names, in an international
> context, because of a legacy compatibility issue.

Dan,

You've made several comments above with which I agree, and a few 
which I don't.  Fortunately or unfortunately, this isn't the 
right place for the discussion.

	* This list, or various of its participants, may have an
	opinion about the use of the term "ACE", but "invent
	definitive terminology for talking about IDNs (or
	anything else)" is not in the charter of the late WG,
	nor has reactivation and rechartering to do that been
	proposed.
	
	* IETF Standards are not mandatory and IETF has no
	enforcement capability.    Suppose a zone decides to
	adopt naming rules of its own --perhaps taking advantage
	of the assertions of RFC 2181 that any binary string can
	be used in the label of conventional/ traditional RRs in
	Class=IN, or by avoiding the normalization and mapping
	rules of IDNA.  Any problems that creates are between
	the zone administrators and applications developers or
	users who get burned.  The IETF is not involved.  ICANN
	might be, various national authorities might be, and
	assorted [other] lawyers might  be, but IETF is not.

	Some of the issues such actions would raise would
	certainly be relevant in looking at adoption and
	interoperability when someone tries to move IDNA to
	Draft Standard, but that isn't on the agenda right now
	either.

For the record, I personally consider local-zone rules about how 
DNS labels are interpreted as really stupid and an invitation to 
non-interoperability of applications, but, again, consensus (or 
not) in this group, on way or the other, isn't going to make 
that more or less true.

I suggest that, if you are serious about this, the usual IETF 
model is probably more useful than complaining on this list 
about paths not taken or paths that the WG tried (intentionally 
or not) to cut off).  Write a draft that goes into enough detail 
--both about what you propose and about how to make a transition 
from, or interoperate with, IDNA zones-- that it can be 
meaningfully evaluated.   Create a mailing list to discuss it. 
With the draft posted, try to organize a BOF or get some AD to 
create a WG directly, to explore the issues and see if a 
standards can be developed.   And so on.

But here?  My impression is that most of the people who watched 
or particpated in the WG are exhausted about the subject and 
really glad it reached _some_ conclusion and got documents out 
the door.  Those who really like IDNA will defend it, and some 
of us who still have misgivings about certain aspects of it 
would like to give it some time to see if it is adopted and 
workable in practice.  Those who are convinced that IDNA is a 
serious mistake, or that it will cut off important future 
evolution (and I have never been a member of either group) have, 
I think, mostly gone elsewhere.  Neither your ideas for more 
radical, in-DNS, approaches, nor mine ever got any traction in 
the WG and they are still less likely to get traction now, 
especially without solid drafts.

So I suggest taking it elsewhere, leaving this list for 
discussion of issues in implementation and deployment of IDNA.

regards,
     john