From: John R Levine
Sent: Sunday, October 10, 2004 1:13 PM
[ must interoperate with old MTAs ]
Your paragraph above is an excellent starting point for the Charter, in
Separately, I do want to comment briefly on the issue of
interoperability. Multipart/signed was designed expressly to be
backwards compatible with non-MIME-aware email components. Consider
that the content that was signed appears first and the security
information second, so as not to distract "backwards" components.
It works OK for people who can look at the MIME separator and realize that
they can ignore it.
Not all MUAs present mail to people. An oft-cited example is mailing list
managers that read lines of commands from the body of the message. I
would guess that these days most list managers can tolerate MIME since
there are so many lame MUAs that make it nearly impossible to send
non-MIME mail, but there are lots of other kinds of applications hanging
off mail systems.
I honestly don't know how many of them expect an unwrapped plain text body
and fail if they trip over a MIME separator. Or how many expect a
particular set of MIME sections and fail if there's more MIME than that.
Clearly, the ones with those problems can be patched or put behind an
unwrapping front end, but I don't have a good idea of how many there are.
So if there's a reasonble approach that dodges that MIME format issue
altogether, I'd rather use it.
I agree with everything John has said. It would indeed be nice to make use
of an existing technology on which a lot of people have worked very hard. I
also think it's paramount that we avoid doing anything that will render mail
going to non-participating sites significantly less intelligible to the
end-user than it is today. Though it is entirely possible to patch
non-conforming MTA's to properly deal with a message format meant for a
system that they don't participate in, inertia will make sure this does not
happen for a long time and we will have effectively shot ourselves in the
foot for adoption. If we want adoption that will span an extended period
where only some sites participate, we simply can't break much of anything
that currently works. If we do break anything, we better fix something else
that currently doesn't work so sites perceive it as a net win, even if they
don't participate. The latter is pretty unlikely. How any MASS proposal
affects sites that do not participate will figure largely into the decision
of other sites as to whether to adopt or not. That limits our choices quite
a bit, but that's life.
A good example of the inertia I refer to is BIND. BIND9 is pretty good,
though not everyone's favorite. However, there are a lot of sites out there
still running BIND4. Why on Earth would anyone run something that is five
major releases and numerous minor releases behind the current version and
forgo all those bug fixes and performance enhancements? For one very good
reason: because it still works well enough. You could claim they are lazy
or clueless, but there is a time-proven admonition that "if it ain't broke,
don't fix it". As much as I personally dislike the end result, it's hard to
make a case for change if what they have still works for their purposes.
That's not to say that someone here can't get very creative and devise a
MIME-based technique that doesn't break existing systems. If there are any
real requirements here, I would suggest that the need to avoid breaking
current infrastructure for non-participating systems is very high on the