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

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 29 Apr 2003 07:47:47 +0000

Dan Oscarsson <[email-masked]> wrote:

> > An ACE label is formally defined as a label that ToUnicode would alter.
> > A (valid) internationalized label is formally defined as a label to
> > which ToASCII can be applied without failing.  It can be shown that all
> > ACE labels are (valid) internationalized labels.
> 
> No that is wrong.
> 
> A IDNA ACE label is defined as above.  Not ACE in general.

When I said "ACE label" above I was obviously talking about an IDNA ACE
label, not some more general ACE concept.  I had started out talking
about whether ToUnicode can output more code points than it inputs,
and Edmon questioned whether the example I gave was a valid ACE.  He
obviously meant IDNA ACE, and my statement above was explaining why it
was in fact a valid IDNA ACE.

I think the term ACE was introduced before I arrived on this mailing
list, so I have no memory of its origin, but I do remember the group
deciding that after a particular ACE was selected, it would be known
simply as "ACE".  Now that IDNA is a proposed standard, I would argue
that "ACE" means "IDNA ACE".

> There are several domain names that will fail when ToASCII is used,
> but are still domain names.  They just cannot be handled by IDNA.

There are non-text domain labels to which ToASCII cannot even be
applied, because ToASCII can be applied only to labels that are text.
But among text labels, ToASCII defines which ones are valid.

> IDNA do not define the world and do not define the basic semantics
> of ACE or domain names with non-ASCII characters.  IDNA does only
> define a way to encode domain names so they can be sent over lagacy
> ASCII DNS protocol.  It does not define what domain names work in an
> international context.

The IDNA spec disagrees.  It says:

    This document defines internationalized domain names (IDNs)...

    If an application wants to use non-ASCII characters in domain names,
    IDNA is the only currently-defined option.

    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.

AMC

---

From: John C Klensin <[email-masked]>
Date: Tue, 29 Apr 2003 07:21:54 -0400

--On Tuesday, 29 April, 2003 07:47 +0000 "Adam M. Costello" 
<[email-masked]> wrote:

> I think the term ACE was introduced before I arrived on this
> mailing list, so I have no memory of its origin, but I do
> remember the group deciding that after a particular ACE was
> selected, it would be known simply as "ACE".  Now that IDNA is
> a proposed standard, I would argue that "ACE" means "IDNA ACE".

Adam,

Regardless of what the WG may or may not have decided at the 
time, the fact that various "testbed names" and other 
non-standard approaches continue to exist (something that at 
least some of the WG didn't anticipate), makes the use of the 
term "ACE" at least ambiguous.  The WG would be doing itself, 
and the community, a disservice by ignoring the fact that there 
continue to be other "ACE" approaches in active use and 
insisting that only it can define what "ACE" means.

I have been using "IDNA name" or "IDNA ACE" in my writing, and 
would suggest that others adopt that, or some similar, 
convention that precisely identifies what is being discussed.

thanks,
      john