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

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

Paul Hoffman / IMC <phoffman@imc.org> wrote:

> > When all systems use ASCII or Unicode, different interpretations are
> > not allowed in this specification.
>
> 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.

Agreed.

> > 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.

I don't think we need to mention any specific character sets.  If the
reader doesn't already know that there are character sets other than
ASCII and Unicode, then none of this is going to be understandable
anyway.

> > 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.

I have no objection.  We might be able to compact it a bit:

    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.

    When systems use local character sets other than ASCII and Unicode,
    this specification leaves the transcoding problem up to the
    application.  If applications implement different transcoding rules,
    they could interpret the same name differently and contact different
    servers.  This problem is not solved by security protocols like TLS
    that do not take local character sets into account.

[I didn't change the first paragraph except to remove the last
sentence.]

Simon, does that still say everything you want it to?

AMC