Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
Has anybody looked into the transitional issues that would arise if Email
was to be moved into allowing UTF-8 headers?
yes, though perhaps not in sufficient detail.
Simply stating that it wouldn't work completely with current systems,
but could work in future modified systems, seems compelling enough to
go for it in the long run to me. (I doubt anyone is challenging that
position?)
frankly I think it would be easier to transition to a completely different
mail format. that is, I think that having two slightly different
mail formats (one ascii, another utf-8) is more confusing and more
likely to lead to interoperability problems than having two obviously
distinct formats which require explicit translation between the two.
I can't see why this would be easier, could you elaborate? Having a
new format that is perfectly backwards compatible if 7bit encodings
are used (as a utf-8 wire format would be) seems much better than
inventing something completely different.
Or are you resigned to the fact that we shall still be encoding headers
using RFC 2047 in 40 years time even though all transports and operating
systems will be 8bit (and even bibary) clean by that time?
please don't cite 40 years of extrapolation from current practice as
'the fact'.
It will be 40 years unless someone is thinking about the future
upgrade path now. IMHO it should have been specified that software
must move to 8bit clean after 2000-01-01, or something, back when the
MIME specs were written (much like some PKIX standards specify that
after 2003-01-01, or something, certificates with certain properties
should not be issued by CAs). Now we're stuck with quoted-printable
and other hacks for maybe 40 years. The only software still not
adopting MIME is because MIME is too complex for the purpose (e.g.,
/bin/mail), and they will never upgrade now.
no, I don't think that 8bit transparency of mail transports alone is
sufficient to warrant the pain of that transition - because zero
additional functionality is gained beyond a small bandwidth savings,
and the pain of having to upgrade millions of installations of hundreds
of different mail programs (MTAs, UAs, list servers, mail filters,
POP servers, IMAP servers, etc.) is too substantial for that minimal
gain - which is mostly wanted for the sake of purity. it doesn't
lessen complexity, it increases it - because mail handling programs
would still have to recognize the old format as well as the new one
for many years.
what would be worth the pain of transition? a hypothetical redesign
of the internet email system that is both reliable (in that you can
expect messages to be delivered with integrity) and safe to use (in
that it won't expose your systems to security threats).
The benefit would be reduced software complexity. No need to worry
about quoted-printable and similar 7bit hacks. Right now it seems as
if the internet email system just gets more and more complex to
implement. IMHO that's not the best path to take.