Re: [idn] WG last call documents

[Dan Oscarsson <Dan.Oscarsson@trab.se>]

>From: "Eric A. Hall" <ehall@ehsco.com>

>
>draft-hoffman-stringprep-00.txt:
>draft-ietf-idn-nameprep-07.txt:
>
> | Stringprep Profile for Internationalized Host Names
>
>Since this profile is specifically for host names, all of the rules that
>apply to hostnames should be placed here. 

From what I could read the title is wrong.
It should be: Stringprep Profile for Domain Names.

To make this work, we need ONE stringprep plus ACE.
One that can be used on ALL labels in DNS.
To have different profiles for different labels would be
a mess. Well, you could mark each profile+ACE with a
different ACE prefix to indicate profile used but having
lots of different encodings/profiles have so far proven to be
a big difficulty for programmers to handle.

A part from the stringprep plus ACE we need rules on what
characters should (or must) be used on different things.
For example a host name should be printable letters
with intermixed printable separators (and no repeated ones).
An other rule is applied on e-mail names.
The above rules on what character are allowed does
only belong in applications, not at DNS protocol level.


>
>
>draft-ietf-idn-idna-06.txt:
>

> | 3. Requirements
>
> | IDNA conformance means adherence of the following three rules:
>
> | 1) Whenever a domain name is put into a generic domain name slot,
> | every label MUST contain only ASCII characters. 
>
>"generic domain name slot" should be substituted with "STD13 slot". There
>is no reason whatsoever that application protocols cannot exchange IDNs or
>IHNs in whatever form they wish.

I agree. Also the term "generic" means anything and that would mean
non-ASCII characters.

>
> | 2) ACE labels SHOULD be hidden from users whenever possible. 
>
>I have argued against this before and I will do so again now.
>
>Should WHOIS servers perform this conversion on output (email addresses
>and nameservers) since it is likely to be displayed to a user? Should an
>email client perform conversion on a message? Every protocol and
>data-format has unique considerations. Making blanket statements like this
>is harmful.

I agree in that the WHOIS server should output names using the character
context of it's protocol. We need a WHOIS protocol that uses UTF-8 and
when it does, ACE labels may not be transmitted over that protocol.

But a WHOIS client should always decode ACE data and display them using
the
local character set.

There should also be a requirement that a protocol using UTF-8 should
never send data using ACE so the receiver does not have to handle
the extra work of checking for embedded ACE.


>
> | B. Design philosophy
>
>What value does this section provide? This text is religion not science,
>seeing as how it omits key counter-arguments, namely that there are
>hundreds if not thousands of applications for every DNS server, so
>upgrading servers in addition to applications represents an incremental
>cost (rather than the "The cost of implementing IDN may thus be much
>lower, and the speed of implementation could be much higher" erroneous
>opinion).

I agree. Remove this section. It contains too much religion.


>
>
>General comments:

>"Adam M. Costello" wrote in <20020207043706.GA7193@nicemice.net>:
>
>> There are some code points that are prohibited in host names, but not
>> in all textual domain names.  The underscore is the best example.
>> These prohibitions belong in ToASCII.
>
>I disagree with this for a couple of reasons. First of all, these
>exceptions are associated with protocol identifier labels, which are not
>hostnames. Secondarily, "protocol identifiers" are
>generally considered as protocol operators which do not need to be
>internationalized (therefore never needing anything but ASCII). 

Depend on who is expected to view protocol identifiers and what
programs using the protocol expects.
Protocol identifiers can have non-ASCII characters.

>SRV owner labels are protocol elements, not text. They should never go
>through any conversion.

Why not. There can be non-ASCII SRV owner labels. As prople are afraid
the non-ASCII host names (which is also a type of protocol element)
can break applications they should be afraid that non-ASCII SRV owner
labels could break applications.

It is easiest if at the DNS protocol level ONE type of ACE (and
stringprep)
is used on all labels. The the lowest level can all use the same
code. Higher levels in applications can put additional constraints
on the content of labels. By having the lowest level as broad as
possible and as few as possible constraints we have a good building
ground for the future. Otherwise we might just like to day with
this ugly "use only ASCII constraint" have to invent a new layer
on top of the old one to bypass the constraints.


>DJ Bernstein is right-on when he says that certs don't solve the spoofing
>problem. There is nothing preventing the wiley hacker from getting a cert
>for billg@micr0soft.com, and there would be nothing about that cert which
>would alert anybody that spoofing had occurred. In general terms, this
>means that I agree with DJB that the initial scope should be tightly
>controlled and slowly incremented. I think that this opinion was also
>expressed by J Klensin's solicitation for a "safe-set" and D Crocker's
>endorsement of a safe-set. This doesn't mean we all agree with DJB, but I
>think that in this case, he is probably correct.

Most of this burden is on the domain owners. Registration of bad type
of domains below .com should not be allowed. This includes names
like micr0soft.com and micorsoft.com which clearly never should
have been allowed.


-
One other thing. As the IDNA supporters think this idea will work fine
and the users will soon not have to see or write ACE names, there
should be a date on which this should be examined. If at that date
not most important software and protocols have been updated, IDNA
should be removed and replaced with something making people update
their software. UTF-8 would probably do that.
For example, at that date I expect to be able to write URLs in HTML
documents using the documents native character set.
The date should be fairely soon as the supporters of IDNA have said
this is quick. 2003-12-31 is acceptable.

   Dan