The question, "Does the "root" need to be fully resolved?" must be
answered in the affirmative. Otherwise, the Multipart/Alternative
must know that it's resolving something for a /Related. One
cannot expect the helper app that handles a descrete media type T/st
to handle a compound object whose root is T/st (Multipart/Related;
type=T/st). Thus, the process resolving the Mul/Alt must know that
it's doing so for a Mul/Rel root. Otherwise, it won't know what
helper app to invoke (with which to "start processing").
Consequently, the Mul/Rel start parameter must point to a fully
resolved discrete MIME entity, not a composite one. Having the
composite type recurse seems to require a whole lot of complexity.
Keeping it simple seems like a "good thing".
Ed
On Fri, 03 Nov 1995 10:26:19 EST Al Gilman wrote:
To follow up on what Ed Levinson said ...
Multipart/Related expects to know the content-type of the object root,
the body part with which to start processing. If the root is inside
a Multipart/Alternative, that adds an additional level of binding or
indirection that must be resolved before the MUA can determine which
helper application gets invoked.
Ed
What does it mean to "start processing?" If the prime
substructure in a Multipart/Related happens to be a
Multipart/Alternative, then processing starts by resolving which
of the alternatives to employ. It doesn't start by selecting a
helper from the "root type" information in the top level
composite. But it knows right where to start, and how.
If the RFC actually restricts content-type [as applied to the
root] to be a fully-resolved, non-multipart type, then this
language is in conflict with the language elsewhere that says the
composition methods recurse.
As you will probably have guessed, I would vote to "save the
trees." But I don't need to put any tree-descriptions in as type
designations in any of the multipart aggregators: so long as I
can use multipart types to characterize the child parts.
Al