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

From: Dan Oscarsson <[email-masked]>
Date: Wed, 30 Apr 2003 14:21:24 +0200 (CEST)

Adam M. Costello wrote:

>> Maybe IDNs, as that is a construct of IDNA, but not domain names in
>> general.  Domain names in an international context is not defined by
>> IDNA,
>
>The *representation* of domain names in an international context is not
>defined by IDNA, but IDNA does define a mechanism for deciding which
>names are valid in that context, and does define a way to compare names
>in that context.
>
>The IETF could produce a second set of definitions in the future, but
>until that happens, the IDNA definitions provide the only standard way
>to use non-ASCII characters in domain names, even in an international
>context.

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 30 Apr 2003 09:01:47 -0400

--On Wednesday, 30 April, 2003 14:21 +0200 Dan Oscarsson 
<[email-masked]> 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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 30 Apr 2003 16:53:19 +0200

Dear John and Oscar,
At 15:01 30/04/03, John C Klensin wrote:
>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).

We saw this approach has probably failed in spite of the efforts and the 
capacity of the involved persons. There is no interest to reuse it. May be 
interest in understanding why it did not work well?

>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.

True.

>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.

I am probably one of them since I think the current solution is a 
bugged?  Sorry, I am still here.

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

I fully agree. As long as IDNs were under IETF control the rest of the 
partners were blocked. Now the IDNA has been released, even if the proposed 
solution was(is) no good, it is A solution.

You wanted it? you got it? now help us making it work!
Don't disband, that would be too easy.

Now, what has been worked out in three years is a very small part of the 
problem. So it is no big deal to circumvent it if it is realy that bad (and 
may be to globally benefit from that effiort?).

1. wording is ununderstandable? ITU translated "internationalized" into 
"multinational" and others into "mutilateral". Habit takes off to note IDNs 
as "ML.ASCII" and MDNs as ML.ML". That is OK.

2. Texts are unreadable. It realy boils down to adding an European standard 
for "nasty danger" header (xn) to domain names of which non ascii 
characters have been transcoded in using Adam's funy code.

3. the choice of "xx--" as an header format instead of "x--x" creates a 
legally complex babelsquatting?. Great, the GNSO/IPC might help fixing it.

4. TLD Managers, WTO, Edifact, laws, Govs, are details "engineers" did not 
bother considering? May be this gives us more flexiblity in finishingthe 
work? Some are already trying to use it to make the IDNA bug a feature for 
the 5000 languages of the mankind (happily 20 are disapearing a year).

John, I fully agree with you. Let stop disputing about IDNA. Let help ".us" 
to support domain names after the proper spelling of the name of every US 
citizen (USA might be a country where this support might be made a law 
quick? Maybe could we read French law under voting that way?). Or let help 
scSLDs to do it, in an ML.ML format, for non roman T/SLDs.

Not three other years from now, just now.
jfc

>regards,
>     john
>
>
>
>
>
>
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.474 / Virus Database: 272 - Release Date: 18/04/03

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 1 May 2003 01:57:27 +0000

Dan Oscarsson <[email-masked]> wrote:

> IDNA defines a way to compare names in ASCII context because it
> requires names to be in IDNA ACE format.

It requires names to be in ASCII format in IDN-unaware contexts.  It
does not require names to be in ASCII format when they are compared.  It
says:

    Whenever two labels are compared, they MUST be considered to match
    if and only if they are equivalent, that is, their ASCII forms
    (obtained by applying ToASCII) match using a case-insensitive ASCII
    comparison.

That doesn't say you must compare the ASCII forms, it says you must
reach the same answer as if you compared the ASCII forms.  And the rule
doesn't say it applies only in certain contexts, it says "whenever"
two labels are compared.  If that's not clear enough, the point is
underscored in the introduction:

    Applications can also define protocols and interfaces that support
    IDNs directly using non-ASCII representations.  IDNA does not
    prescribe any particular representation for new protocols, but it
    still defines which names are valid and how they are compared.

> Comparing names in an international context must be done using UCS
> characters directly.

I assume that's your opinion.  It's certainly not a requirement of any
standard.

IDNA allows you to perform the comparison any way you
like, provided you get the right answer.  For example,
given any two valid internationalized labels X and Y,
tolower(ToASCII(X)) == tolower(ToASCII(Y)) iff nameprep(ToUnicode(X)) ==
nameprep(ToUnicode(Y)), so you can use either form as a canonical form
for comparisons.

AMC