[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] ToUnicode output can be longer than input



--On Wednesday, 30 April, 2003 14:21 +0200 Dan Oscarsson <Dan.Oscarsson@kiconsulting.se> 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