Subject: [idn] Editorial comments on idna

From: Erik Nordmark <[email-masked]>
Date: Fri, 3 May 2002 20:59:09 +0200 (CEST)

draft-ietf-idn-idna-07.txt
----------------------

I've reviewed the idna document to make sure it is
ready for IETF last call.

Here are some editorial comments that it would be useful to
fix before the last call.

I've read the document thinking about what an implementor of an
application needs to understand and know in order to enable IDN in the app.

The introduction makes sense for those that have participated on the IDN
mailing list. Unfortunately it doesn't do a good job of introducing 
things for the first time reader. Assume that Joe/Jane application 
implementor is going to read this. What would they need to know up front 
to help them understand what they need to do where in the applications?
I think this can be done with an introduction that is 1-2 pages long.
But it needs to start stating the problem a bit.
And the dangling reference to "other proposals" don't make any sense
for such a reader.
Perhaps even the picture in section 6 can be moved to the introduction.
Even better to split that picture into two pictures - one "before" 
and one "after" adding IDN support to the application.

Section 4 and the ToASCII and ToUnicode algorithms in general
operate on labels but the application cares about domain names.
I don't think it is sufficient to tell the poor application programmer
"do this for each label" without saying how to extract the labels
from the domain name.
I assume this algorithm just consists of looking for U+002E in the input
strings. 
However, in order to be consistent with the text in section 5.1 in nameprep
I think IDNA should say that the labels should be separated at U+3002
as well as U+002E.

Section 6 doesn't mention that the application needs to set the
"host name syntax rule" flag.
Section 6 doesn't mention that the application needs to set the
"prohibit unassigned" flag.
What is needed here is just some text to make it clear that the
application needs to do *something*. Example text would be:
	When the application is handling a domain name for which
	the host name syntax checks should apply (which is the common case)
	the application needs to set the "host name syntax" flag when using
	ToASCII/ToUnicode.

	When the domain name is stored the application needs to set
	the "prohibit unassigned" flag when using ToASCII/ToUnicode.
	[and similarly for the inverse]

The abstract could be improved by adding the benefit of using a
representation into the same octets e.g. by adding
	This representation allows IDNs to be introduced with minimal
	changes to the existing DNS infrastructure.

Section 2: Is there a reference for US-ASCII that can be added?

Section 2: host name vs. domain name.
I think it makes sense to add "In this document we use the term "domain
name" in general, and when referring explicitly to the syntax restrictions
in [STD3] we use the term "host name syntax".

Section 2" IDN definition.
I don't think the last sentence about "name handling bodies" 
is part of the definition.
Is there a better home for that statement somewhere else in the document?

Section 2: Internationalized Label
I think the definition for "ACE label" should be broken out as being its own
paragraph.
Also, the ACE definition should be explicit that the ACE label includes
the ACE prefix (which is what punycode states).

Section 2: I find it odd that the "generic domain name slot" is less
generic than the "internationalized domain name slot".
Is there a better name which is closer to the reality that such
slots are quite restrictive? (LDH slot? ASCII slot?)

Section 4.1 should say in its first sentence that the
input is a sequence of code points making up one label.

Section 4.1 and the definition of "internationalized label" talk
of "equivalence". I think this is a bit too subtle.
I think it might help to define "label equivalence" in section 2
explicitly (in its own paragraph) and point out that this
is not just a case of code point by code point comparison
(because under "label equivalence" an ACE label should match
the corresponding non-ACE label.)

Section 4.1 talk of "host name syntax rules" but has no reference
to what this means. STD3?
Perhaps the above clarfication to the definition takes care of this.

Section 4.1 (or section 6?) should say something about the meaning
of a failure indication of ToASCII.

Section 4.1 step 2: specify that the "prohibit unassigned" flag is
used by nameprep.

Section 4.1 step 3: "is a host name" isn't well defined.
It should say something like
	if the "host name syntax" flag is set.

Section 4.1. Step 5 should presumably be before step 4.
Or do you want to allow multiple applications of ToASCII i.e. being
able to apply it to a label which has already been "ACEd"?
If so it makes sense the desire to be able to do this explicit.

Section 4.1 step 6 doesn't say "and fail if there is an error".

Section 4.2 should say in its first sentence that the
input is a sequence of code points making up one label.

Section 4.2 step 2. Why is this step needed?
This is likely to be another unstated desire/requirement.

Section 4.2 step 2. Should say that nameprep uses the "prohibit unassigned"
flag.

Section 4.2 step 6. What happens when ToASCII returns an error?

Section 4.2 step 7. Instead of "sequence" how about "result of
ToASCII"? "Sequence" reads a bit like "the saved copy 
of the sequence".

Section 5 After "IESG--" add: [IANA to assign]

The picture in section 6 doesn't actually show where ToASCII and
ToUnicode fits. How about putting a box between the resolver library and the
application conversion box?

Also, the text on the arrow going to "application servers" talks both
of the immediate case (when application protocols use ACE) and
a future where some application protocols might negotiate to use
a non-ACE encoding. Perhaps the latter should be a separate picture?
The text could be replaced by having two different paths. Roughly

	v	^			^
	|	|			|
	v	^			|
    ToASCII/ToUnicode			TBD
	    ^				|
	    | Existing application	| New, IDN-aware application
	    | protocol			| protocol
	    v				v
    Existing application	New, IDN-aware application servers
    servers

I think the text in the picture is trying to say the above.
The above "TBD" is "predefined by the protocol" in the document.
Perhaps the "ToASCII/ToUnicode" box should be named "IDNA" - but "IDNA"
is more the whole approach than the single functional unit doing
the conversions.

The last paragraph in section 6.2 can perhaps refer to the 
terminology in the picture. For instance saying that in terms of figure X
this means that the ToASCII/ToUnicode box would be available as part of
the Resolver library box.

Section 6.6 says
	It also SHOULD
	be used for other name comparisons, such as when a browser wants to
	indicate that a URL has been previously visited.
I don't understand what this has to do with DNSSEC. Does it belong in
a different section?
And if we allow well-defined comparisons without requiring ACE encoding
before the comparison then I don't see why it would be required.

Section 7 says:
	ACE is an encoding for domain name labels that use non-ASCII
	characters.
My brain tripped on this. Seemed to read that ACE uses non-ASCII characters.
And I suspect other non-native English speakers might have more problems
understanding what "that" refers to. Can it be reworded?

Split normative vs. non-normative references.

---

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 06 May 2002 06:55:49 +0200

--On 2002-05-05 21.56 +0000 "Adam M. Costello"
<[email-masked]> wrote:

> First, a quick small proposal:  The name "UnACE" would more accurately
> reflect the behavior and purpose of ToUnicode.  Should we rename it?

If one is "ToASCII", then the other is either "FromASCII" or
"ToSomethingElse" (I think...).

   paf

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 6 May 2002 21:55:03 +0000

> "ToSomethingElse" (I think...).

ToNonACE would work.

Both operations take any label as input, so it's the output that
distinguishes them, so FromWhatever doesn't make sense.

The one thing you can say about the output of ToASCII is that it's
always ASCII, so the name ToASCII makes perfect sense.

The one thing you can say about the output of ToUnicode is that it's
never an ACE (but it could be ASCII or non-ASCII), so the name UnACE or
ToNonACE would seem to be the most appropriate.

This is not a big deal.  If people still prefer ToUnicode, that's fine,
I just thought we might be able to find a name that gives the reader
better intuition about what it does.

AMC

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 06 May 2002 20:20:16 -0400

>> "ToSomethingElse" (I think...).

Why then not "ToACE" and "FromACE". "ToNonACE" feels like double negations,
and those constructions are not easy for non-english native people (like
myself).

  paf

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 7 May 2002 00:56:28 +0000

Patrik Fältström <[email-masked]> wrote:

> Why then not "ToACE" and "FromACE".

FromACE doesn't make sense because both operations accept *any* label as
input, not just ACE.

ToACE doesn't make sense because neither operation always outputs an
ACE.  ToASCII sometimes outputs an ACE, sometimes not, but it always
outputs ASCII, hence the name ToASCII.

I don't think there could be a better name for ToASCII than ToASCII, so
let's leave that one alone.

> "ToNonACE" feels like double negations, and those constructions are
> not easy for non-english native people (like myself).

Yeah, it is a little contorted.  That's why I first thought of UnACE.

UnACE is my favorite, but I would be content with any of ToNonACE,
UnACE, and ToUnicode.

AMC

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 06 May 2002 21:14:30 -0400

> UnACE is my favorite, but I would be content with any of ToNonACE,

As "ToUnicode" can take non-ace as input, naming it unace is wrong as you
say.

So, why not keep the names we have?

  paf

---

From: liana Ye <[email-masked]>
Date: Fri, 10 May 2002 10:27:20 -0700

Another thought, may be ToNonLDH is a more accurate
name. 

Liana

________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.

---

From: liana Ye <[email-masked]>
Date: Fri, 10 May 2002 10:22:18 -0700

I think ToNonAscii is much better than ToUnicode.  

Since the current ToUnicode protocol can contain other codes 
such as GB, JIS and many others for localized display puposes 
and trademark matches.  We know that trademarks started as 
regional issues (Refer to WIPO RFCs).  So besides the issue 
of internationalized tradenames, such as TC/SC, Latin/Greek, 
Latin/Armenia and Upper/Lower character set insensive issue 
right now in debate, GB code tradename matches to BIG5 is 
an issue even we ignore the TC/SC issue of the 20% of the world 
population problem in this WG.  

The protocol ToGB, ToBig5, ToJIS, ToKSC, ToISO8859 will be
co-exist with ToUnicode.  Thus, ToNonAscii is much better in
describing what we have in stringprep, where ToUnicode is 
the forwarding one the existing servers are convergent to.

The process could be

(screen/keyboard/sound) Input buffer in  whatever

1. apply ToGB/ToBIG5/ToUnicode ... 
       for trademark check   

2. apply ToACE (or  ToUTF-8, ToUTF-16 for whatever )
       output  unchanged or  ACEd 

3. apply gethostid/gethostname 
      for tradename match

When received from transmission:

ToNonAscii 
    if NLDH refuse it (may it be UTF-8, GB, BIG5, JIS, Unicode, ...);
    if ACEd, decode it with 
         ToUnicode, ToGB, ToJIS, ToUTF-8 ... 
         (for another tradmark match check here before display them?)
    else unchanged DNS tradenames. 

Thus ToUnicode should be reserved for higher level trademark
matching in the future. 
	
Liana

---

From: Keld Jørn Simonsen <[email-masked]>
Date: Fri, 10 May 2002 19:57:03 +0200

> So, why not keep the names we have?

I don't think that ToUnicode is the correct name, as it is really
10646 that it is defined for. So maybe To10646 or ToUcs.

Best regards
Keld

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 10 May 2002 19:35:31 +0000

> Another thought, may be ToNonLDH is a more accurate name.

No, because the output of ToUnicode sometimes is LDH.

> I think ToNonAscii is much better than ToUnicode.  

No, because the output of ToUnicode sometimes is ASCII.

The only thing we can say for sure about the output of ToUnicode is that
it is never ACE.  (Well, and that it's Unicode, but all strings in the
IDNA spec are Unicode.  Even ASCII strings are Unicode, because Unicode
is an extension of ASCII.)

The only names I can think of that might be better than ToUnicode are
ToNonACE and UnACE.  Since no one has expressed support for either of
those, I guess we're sticking with ToUnicode.

Keld Jørn Simonsen <[email-masked]> wrote:

> 10646 that it is defined for.

The difference between ISO-10646 and Unicode is not relevant here.
Both use the same table that maps between code points and characters.
The difference (as I understand it) is that Unicode defines lots of
additional information about the characters and how to handle them,
while ISO-10646 is little more than a table and some encoding forms.

AMC

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 May 2002 13:54:50 -0700

>"ToSomethingElse" (I think...).

yes.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850