On Wed, 14 Aug 2002, Fred Morris wrote:
On Tue, 13 Aug 2002, Bart Schaefer wrote:
On Tue, 13 Aug 2002, Udi Mottelo wrote:
Unfortunately metamail doesn't know the Content type
"multipart/alternative" you can miss some files.
Metamail knows multipart/alternative -- but it interprets it according to
the MIME spec, which says that when given alternatives you select exactly
one of them (the "best" one based on the test criteria in mailcap).
Unfortunately I don't recall the RFCs saying anything about mailcap; maybe
you could cite a reference?
Sorry - "according to the MIME spec" and "based on ... mailcap" are two
seperate concepts there. Mailcap tests are the mechanism that metamail
uses to implement the "most preferred" selection specified by MIME; there
is not otherwise a connection, except that both the original MIME spec
(RFC1521) and the mailcap spec (RFC1524) were written by the same author
(Nathaniel Borenstein), published at the same time, and intended to be
used together.
What they do infer is that the "most preferred" format is the last one
presented in the body. Yes, what I am saying is that according to my
interpretation, if a text/html part precedes a text/plain part, then the
text/plain part is "preferred"! Not that mail clients necessarily agree
with me in practice.
There are two things going on here.
(1) When assembling m/a, the parts are intended to be ordered from least
preferred presentation to most preferred. There is an assumption that the
most complex presentation is the most preferred, i.e., the writer always
wants the reader to see the richest possible content, so that the ordering
should always place the simplest format (usually text/plain) first. This
also assures that if the recipient does not have a MIME-capable reader, he
need only skip over the miminum amount of cruft to find readable content.
(2) When decoding any MIME multipart, the decoder is never required to
make more than one linear pass over the input stream. In the particular
case of m/a, the intent is that the decoder can, if necessary, buffer up a
rendering of the first part as it reads it, and then when it encounters
the content-type of the second part, immediately decide to either display
the first part and stop, or to discard the first part and begin buffering
the second; and so on until it reaches either the end of the message or a
part that it is unable to display. Again there is an assumption that, if
the parts are in order of increasing complexity, a decoder that e.g. can't
display text/html, also won't be able to display the application/pdf that
follows it.
The RFCs seldom make or intend things to be more complicated than they
need to be; always apply Occam's Razor.
This is true, but has to be applied in context of what the spec is meant
to achieve. In the case of m/a, one of the goals was as much backward
compatibility as possible with pre-MIME mail user agents.
Micro-resume, just so you know I'm not merely expressing personal opinion:
I was involved in the IETF mailing list discussions that led to RFC1521
et al.; I was the head of the engineering team that implemented MIME in
one of the first MUAs to support it; and if you want a reference to verify
any of this, I can direct you to my friend Nathaniel Borenstein.
On Wed, 14 Aug 2002, David W. Tamkin wrote:
I know nothing about MIME (except that 100% of the multipart email I get
should have been sent in single-part plain text; whatever value MIME may
have for someone else, for me it is an unalloyed negative)
In 20/20 hindsight, perhaps the MIME spec should have said more about not
sending the extra m/a parts when they don't actually add anything to the
presentation. However, the IETF waffles back and forth on how much they
can interfere with implementation decisions when defining protocols. In
the case of MIME, there were a lot of MUA implementors involved, and the
pendulum was pushed away from restricting them.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail