Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt

Thanks, those are very good points. A few notes on your proposed 
changes to the security considerations:

At 8:20 PM +0200 5/27/02, Simon Josefsson wrote:
>+Domain names are used by users to identify and connect to Internet
>+servers. The security of the Internet is compromised if a user
>+entering a single internationalized name is connected to different
>+servers based on different interpretations of the internationalized
>+domain name.

That seems fine, and expands from what we had before to cover your 
larger concern.

>   When all systems use ASCII or Unicode, different
>+interpretations are not allowed in this specification.

I think that goes too far. A user system that "uses Unicode" could 
still make wrong judgements between the keyboard and the encoding. 
For example, on the Mac, typing Option-8 inserts a bullet character. 
There are many different bullet characters in the Unicode character 
repertoire, so entering a host name that includes one of those bullet 
symbols might get the wrong result. Thus, I'd rather not use that 
last sentence.

>+When involved systems use non-ASCII and non-Unicode characters (such
>+as ISO-8859-1 and ISO-2022-JP, which are common on the Internet),

We're not concerned with what is common on the Internet, but what is 
common in systems.

>+however, this specification leaves the transcoding problem up to the
>+application.  Thus there can not be any assurance that two
>+applications will not implement different transcoding rules. When two
>+applications implement different transcoding rules, they will
>+(assuming both domains exists) contact different servers.  Note that
>+the problem can not just easily be solved by using a security protocol
>+such as TLS to identify and authenticate to end points, unless these
>+protocols have already solved the problem which IDNA is trying to
>+solve.

That seems like a good addition.

--Paul Hoffman, Director
--Internet Mail Consortium