Rens,
Two issues to comment on, rescanning because you can't handle the
media type and having the start entity first. In reverse order.
The Multipart/Related draft left the location of the start entity
arbitrary to allow MIME composers some freedom. An easily imagined
scenario: a composer generates a composite object on the fly but
doesn't have all the data for the start entity until after the other
pieces have been generated. Hence the start entity comes last. I
suspect other situations occur in which the placement of the start
entity "naturally" comes at some other place.
As in Multipart/Alternative one might want to place a simple or
explanatory Text/Plain entity at the beginning, in case the recipient
couldn't view the Related media type.
How about addressing the rescanning problem by making the "type"
parameter of Multipart/Related required. Then you know at the start
if you can handle the entity. Person opinion: if a system can't handle
the type in Multipart/Related wherever it occurs there's no reason to
display it at all. I suggest that the fallback to Multipart/Mixed is
inappropriate but I have no objection to permitting it. Permitting
the fallback argues for separating the start entity and the first
entity functions.
As I've suggested above, one can provide guidance for humans whose UAs
gave up on the media type while the other can be rich in details for the
application that processes the media type. Doing that implies that
applications using Multipart/Related gracefully handle non-referenced
entities. I.e., those not referenced in the internal structure of the
objects packages as Multipart/Related as would be the case in a
Text/Plain "warning" message.
Best.../Ed
On Thu, 18 May 1995 17:16:43 EDT Rens Troost wrote:
"Chris" == Chris Newman <chrisn+(_at_)CMU(_dot_)EDU> writes:
Chris> The problem with the start parameter is you have to scan to
Chris> the start item to decide if the bodypart is one that is
Chris> understood. If it isn't, you need to go back to the
Chris> beginning and re-process in a more multipart/mixed fashion.
This is right on the money, but not unique to Ed's draft;
multipart/alternative exhibits the same unfortunate multi-pass
behavior, since the ordering is least preferred/most portable -> most
preferred/least portable.
But Ed; why not mandate that the start part be the first part? It
would greatly simplify handling.