In <200208181956(_dot_)g7IJuK027910(_at_)astro(_dot_)cs(_dot_)utk(_dot_)edu>
Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> 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: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk 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