In <200205072112(_dot_)17626(_at_)sendmail(_dot_)mutz(_dot_)com> Marc Mutz
<mutz(_at_)kde(_dot_)org> writes:
On Monday 06 May 2002 18:03, Charles Lindsey wrote:
<snip>
So perhaps we should still be looking at other possibilities for local
part, such as RFC 2047. Yes that needs care to ensure it is done
canonically, but that is just a matter of insisting that the whole
local-part be treated as exactly one encoded-word.
A base64-encoded UTF-8 encoded-word.
Yes, I think on further reflection that you would not insist on too much
(or even any) canonicalization of the RFC 2047 stuff, but you would
require it to be decoded to an octet stream at the far end, and the local
part would be considered to match if the octet streams matched. I did
something similar for signing headers with RFC 2047 encodings in
draft-lindsey-usefor-signed-01.txt.
You might also require texts in other charsets to be translated to utf-8
before comparing the octet streams. It would also work as well to compare
octet streams in UTF-16 or UCS-16 form.
But, for local-parts, the only other suggestion is to use IDNA. That
suffers from two problems, which nobody has responed to yet:
1. Punycode, as it stands, converts uppercase to lowercase. That is not
necessary (lowercasing is really a part of Name-prep, and local-parts would use
a
different *-prep), so the Punycode spec could be changed.
2. The result of applying IDNA to some valid local-part is another
local-part. Who is to tell whether that was not the intended local-part in
the first place. So you would first need to restrict RFC 2822 local-parts
in some way.
--
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