Re: drums2?

["Charles Lindsey" <[e-mail]>]

In <[e-mail]> Keith Moore <[e-mail]> writes:

>I don't see why introducing I18N into the local-part need restrict the
>syntax or flexibliity for non-I18Ned local-parts.  As long as the I18N'ed
>local-parts are a subset of the current syntax then I don't see why this
>needs to affect 2822 or its successor.

Suppose an encoding is defined for local-parts (perhaps some form of
stringprep followed by punycode).

Suppose X is the original local-part in some strange charset, and Y is the
result of encoding it.

Then Y is also a valid local-part in its own right under the present
syntax, otherise there is no guarantee it will get transported (for
example, the output of punycode is always a valid local-part AIUI).

Then when you receive Y, how do you tell whether it was an encoding of X,
or whether it really was intended to use that crazy-looking Y as the
local-part of the address?

You need therefore some foolproof way to distinguish between an encoded
local-part and an unencoded one. This means placing some restriction on
local-parts as presently defined.

My own preference would be to limit genuine local parts to tokens, and to
arrange that the encoded form was not a token. But there are other ways.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5