-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 08 May 2002 13:34, Charles Lindsey wrote:
In <200205072112(_dot_)17626(_at_)sendmail(_dot_)mutz(_dot_)com> Marc Mutz
<mutz(_at_)kde(_dot_)org> writes:
<snip>
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.
<snip>
But that breaks existing software that needs to compare local-parts for
equality (think mailing list handling software). This breaking can only be
avoided if the encoding has the property to always yield the same output
octet-sequence for the same input Unicode sequence (modulo Unicode n11n and
c13n).
But, for local-parts, the only other suggestion is to use IDNA. That
suffers from two problems, which nobody has responed to yet:
<snip (1)>
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.
But this is a problem that arises for every encoding that is representable in
current local-part syntax. Rfc2047 also yields just another valid
local-part[1] (altough less likely to confilct with existing local-part due
to the many "broken" mailers that would display it decoded).
Marc
[1] If you follow rfc2047's suggestion to encode any specials, too, so the
encoded-word looks like an atom.
- --
Marc Mutz <mutz(_at_)kde(_dot_)org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE82qz53oWD+L2/6DgRAq5SAKCUNSJYMI+bIMt9b3jjfvHPr9ji1wCfZHuF
Iejy/m5XkxBudehfxMx8xNM=
=7Wzl
-----END PGP SIGNATURE-----