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
