Keith Moore
2003-11-11 19:44:34 UTC
This is an elaboration of comments I made at the microphone yesterday.
1. I don't buy the argument that it's reasonable to require end-to-end
MTA upgrades before IMA can work. Users don't have enough ability to
choose the MTAs that are used (on either sending or receiving end),
since such choices are often forced by one's ISP or local network.
I also don't buy the argument that requiring end-to-end MTA upgrades
puts the burden for upgrade only on those who need it, because users of
languages other than English are everywhere. Someone whose native
language isn't English travels to an English-speaking country and
connects to a network which (by whatever means) coerces outgoing SMTP
to go through its own MTAs that don't support the IMA extension.
Nor do I buy the argument that it's okay to bounce messages that arrive
an an MTA that doesn't support the IMA extension, because that ends up
dividing up the email network into two groups - one for those who never
correspond with anyone with an IMA and the one for the rest of the
world. People who wish to correspond with both groups will need two
email addresses (this is a given) and will need to arrange to use
different email addresses and to send the mail with or without the IMA
extension depending on which set of recipients the mail is going to.
And if a single message is sent to both IMA and ASCII addresses,
reply-to-all breaks.
2. Email addresses aren't just used by email; they are also used in
various other protocols - as principal names in security protocols as
well as ordinary applications, in instant messaging, etc. So the
impact of changing the format of email addresses goes well beyond email.
3. People have criticized IMAA because it's ugly. It's hard to get rid
of ugliness. ACEs are ugly for those who can't decode them. Putting
UTF-8 in headers is ugly for those MUAs that can't decode that.
Breaking message handling software (as will certainly happen) is ugly.
Bouncing messages is ugly. Translating messages is ugly when the
translations break.
People will complain no matter which solution is adopted, because that
solution is ugly. That doesn't mean that any of the other potential
solutions was less ugly.
There's something to be said for putting the ugliness in a place where
people are in a position to fix it. It's easier to upgrade your MUA to
support IMAs than to upgrade our MUA AND all of the MTAs that handle
mail you receive.
4. In the context of IDNs, the idea that you can compare strings by
"canonicalization followed by exact match" was thought to be fairly
dubious for some languages that have multiple writing systems with no
easy and repeatable means of translating one to another. My guess is
that it's even less adequate for "personal names" such as might be used
in IMAs, than for "enterprise names" such as would be used in IDNs.
5. If you really want to change the message format, why stop at UTF-8
headers? There are lots of kinds of cruft in 2822/MIME these days.
UTF-8 headers would only get rid of one kind of cruft - RFC 2047
encoded-words.
Actually, it wouldn't even do that, because existing MUAs would still
need to be able to handle 2047 encoded-words in both new messages from
old MUAs and old messages already in the user's message store. UTF-8
headers seem like a simplification but they would actually make MUAs
more complex for many years.
Also, moving to UTF-8 headers is harder than it looks. Right now, all
data elements in all header fields are ASCII. When you upgrade to
UTF-8 headers, does it axiomatically become okay to use UTF-8 anywhere?
What about in embedded message bodies that are currently required to
use a 7bit encoding? What about in URLs in header fields (like List-*
fields)? How do we handle Unicode characters that "look like" ASCII
specials?
Until someone has something resembling a specification that analyzes
the potential impacts not only on every header field and every email
protocol but also every use of email addresses, statements of the form
"UTF-8 is easier than X" are mere handwaving. I do think that someone
needs to be working on such an analysis so that we won't have to
revisit this discussion every time the idea comes up. At some point
the message format needs to change, but we can't really evaluate
whether it's worth it at any particular point without doing the impact
analysis.
1. I don't buy the argument that it's reasonable to require end-to-end
MTA upgrades before IMA can work. Users don't have enough ability to
choose the MTAs that are used (on either sending or receiving end),
since such choices are often forced by one's ISP or local network.
I also don't buy the argument that requiring end-to-end MTA upgrades
puts the burden for upgrade only on those who need it, because users of
languages other than English are everywhere. Someone whose native
language isn't English travels to an English-speaking country and
connects to a network which (by whatever means) coerces outgoing SMTP
to go through its own MTAs that don't support the IMA extension.
Nor do I buy the argument that it's okay to bounce messages that arrive
an an MTA that doesn't support the IMA extension, because that ends up
dividing up the email network into two groups - one for those who never
correspond with anyone with an IMA and the one for the rest of the
world. People who wish to correspond with both groups will need two
email addresses (this is a given) and will need to arrange to use
different email addresses and to send the mail with or without the IMA
extension depending on which set of recipients the mail is going to.
And if a single message is sent to both IMA and ASCII addresses,
reply-to-all breaks.
2. Email addresses aren't just used by email; they are also used in
various other protocols - as principal names in security protocols as
well as ordinary applications, in instant messaging, etc. So the
impact of changing the format of email addresses goes well beyond email.
3. People have criticized IMAA because it's ugly. It's hard to get rid
of ugliness. ACEs are ugly for those who can't decode them. Putting
UTF-8 in headers is ugly for those MUAs that can't decode that.
Breaking message handling software (as will certainly happen) is ugly.
Bouncing messages is ugly. Translating messages is ugly when the
translations break.
People will complain no matter which solution is adopted, because that
solution is ugly. That doesn't mean that any of the other potential
solutions was less ugly.
There's something to be said for putting the ugliness in a place where
people are in a position to fix it. It's easier to upgrade your MUA to
support IMAs than to upgrade our MUA AND all of the MTAs that handle
mail you receive.
4. In the context of IDNs, the idea that you can compare strings by
"canonicalization followed by exact match" was thought to be fairly
dubious for some languages that have multiple writing systems with no
easy and repeatable means of translating one to another. My guess is
that it's even less adequate for "personal names" such as might be used
in IMAs, than for "enterprise names" such as would be used in IDNs.
5. If you really want to change the message format, why stop at UTF-8
headers? There are lots of kinds of cruft in 2822/MIME these days.
UTF-8 headers would only get rid of one kind of cruft - RFC 2047
encoded-words.
Actually, it wouldn't even do that, because existing MUAs would still
need to be able to handle 2047 encoded-words in both new messages from
old MUAs and old messages already in the user's message store. UTF-8
headers seem like a simplification but they would actually make MUAs
more complex for many years.
Also, moving to UTF-8 headers is harder than it looks. Right now, all
data elements in all header fields are ASCII. When you upgrade to
UTF-8 headers, does it axiomatically become okay to use UTF-8 anywhere?
What about in embedded message bodies that are currently required to
use a 7bit encoding? What about in URLs in header fields (like List-*
fields)? How do we handle Unicode characters that "look like" ASCII
specials?
Until someone has something resembling a specification that analyzes
the potential impacts not only on every header field and every email
protocol but also every use of email addresses, statements of the form
"UTF-8 is easier than X" are mere handwaving. I do think that someone
needs to be working on such an analysis so that we won't have to
revisit this discussion every time the idea comes up. At some point
the message format needs to change, but we can't really evaluate
whether it's worth it at any particular point without doing the impact
analysis.