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?)
actually I haven't seen a single compelling argument to move to utf-8.
however if I had the luxury of designing a new mail system, I would
certainly use utf-8 for human-readable text. I just don't think that
we'll have that luxury for a long time.
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?
because with a completely incompatible (though translatable) format
nobody would pretend that it's acceptable to shove a new-format
message into a mail system that only understands 822/2822/MIME.
it will be absolutely necessary to translate at the boundaries
between the two systems, and it will be absolutely clear where
such translation is necessary. if the translation fails,
it will also be fairly clear *where* the translation failed.
on the other hand, if you just shove utf-8 into protocol elements
that currently expect ASCII, there is no clear boundary between the
systems - and thus no clear (to the user) deliniation of who is
responsible for the translation.
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.
if you think about it, "compatible if 7bit encodings are used"
isn't terribly important - since the entire justification for
this change is to *not* be restricted to 7bit encodings.
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.
first of all, people are thinking about the future upgrade path
now - it's just that we can't usefully specify it at this point.
second, the 40 that's pure speculation on your part, and totally
unwaranted. Internet mail hasn't even been around 30 years yet,
and it's still evolving - why in the world do you think you can
expect it to be static for the next 40 years?
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
hey, if you think it's reasonable to impose your idea of appropriate
operational constraints on people who were there at the time, dream
on. we could only mandate those things for which we could get consensus.
there was wide consensus that a flag day wouldn't work, there was
significant objection at the time to *ever* expecting systems
to be 8-bit clean, 8-bit cleanliness would not have rid us of the need
for encodings in MIME (including the need for something like 2047 -
we would still have needed a per-element charset label because utf-8
was not available). besides which 8-bit cleanliness is the *least*
of the problems associated with using utf-8.
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.
that argument simply doesn't hold up under analysis.
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.
that's the way systems tend to evolve - they get more and more complex
over time (as they become more efficient or adapt to new circumstances)
until changes in external conditions prompt a revolutionary change.
then they start getting more and more complex again.
Keith