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.
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.
I gave up on the parameter for one-pass processing because I had enough
room to store the whole message (or at least the more important first 32Kb
of the message) and there's so much m/a that it had to be processed anyway.
There was also less than stellar support for it.
So my implementation stores the whole message coming off the wire and then
remembers a pointer to the start of the previous alternative so it can go
back to it when an alternative is found that can't be handled. 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.
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.
LL