At 10:29 13/09/99 -0700, Laurence Lundblade wrote:
At 09:35 AM 9/13/99 -0400, Keith Moore wrote:
Did somebody once propose an modified form of multipart/alternative, with
reversed ordering of the alternative parts (i.e. high-to-low fidelity
rather than the standard low-to-high)?
in the absence of a mechansim to know whether the recipient could
handle such a construct, what would be the point?
There's a distinction here between the recipient handling MIME and the
recipient handling the particular most rich alternative. I believe m/a
ordering was chosen with the user of a non-MIME mailer in mind where the
text part will show up before the (for them) alphabet soup b64'd PDF or
such. Being friendly to non-MIME mailers is important and probably
eliminates any possibility of reversing the order.
I generally agree with all of the above. Your belief is what I understand
to be stated by RFC 2046 on m/a.
However if we ignore non-MIME mailers for arguments sake then reversing the
order would help with low memory implementations. The client skips
alternatives until one is found that can be handled without having to
"save" the previous part during the parse.
Yes... "if".
.... If you're
trying to MIME parse one-pass right of the wire because you can't store
much of the message at all then you're sort of stuck. I believe this is the
*single aspect of MIME* that prohibits one-pass processing.
Again, I agree. (w.r.t MIME conformance per RFC 2049?)
One option to get around this might be to assume that m/a is generally used
only for text/plain and text/html. I can't recall seeing anything else. If
that's the case then you make your decision at coding time. If your
implementation can deal with HTML you always skip the text/plain
alternative. If it can't you always take the text/plain alternative.
The case I am considering is to do with fax image formats, so that doesn't
really help. I was checking to ascertain whether or not there might be an
existing mechanism before considerations turn to inventing someting new.
Thanks,
#g
------------
Graham Klyne
(GK(_at_)ACM(_dot_)ORG)