Al,
Maybe there are two views on how the MIME UA does its work. You
suggest the MUA resolves goes down a level, resolves that level,
returns up a level, and then sees if it can display the node it just
visited. It's also possible for the MUA to visit the node and decide
to display it without returning. Sort of recursive descent. The
problem with the latter approach is one of propogating the context.
MUAs are not constrained to either approach. I expect that both
approaches exist.
When applied the Multipart/Related your model works for /Alternative.
What if the root were /Mixed or /Parallel? Those don't make sense as
they don't resolve to a single media type value. For me, allowing
/Alternative may overly constrain the MUA implementations or requires
additional communication to handle a special case. Consequently
I'm loath to suggest that be allowed. If MUA implementors don't have
a problem then I don't either.
I don't think I've answered the issues you've raised directly.
Perhaps I'm too thick headed on Friday afternoons. Do we
agree that for media type T/St there could be two helper apps? One
that handles T/St as a discrete type and one that handles a
Multipart/Related whose root has type T/St? If so, then I think
the disagreement comes from the underlying MUA processing models we
entertain. Do we agree that both models are possible?
Best.../Ed
Btw, do the same processing models apply to Message/External-body?
Given the following composite types, which could be root objects?
What does it mean if they were root objects? How does the processing
model affect that?
Multipart/Mixed
Multipart/Parallel
Multipart/Alternative
Multipart/Related
Multipart/????
Message/External-body
Message/Partial
Message/RFC822
I don't have good answers except that the processing model may make
even those that resolve to discete media types difficult to handle.
That's why I conclude that, for simplicity, the root must be a discrete
type.
On Fri, 03 Nov 1995 13:34:31 EST Al Gilman wrote:
OK, since we clearly disagree on what is simple vs. what is complex,
Let's see what we agree on.
1. The helper Ap only understands what to the MIME composite is
an atomic part with one non-composite type.
On to the differences in interpretation:
To follow up on what Ed Levinson said ...
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.
What needs to know this is what calls the helper Ap, not what
resolves which part is to be treated as the root among the
alternatives in a multipart/alternative. The resolution
transaction consults the set of local type capabilities and
blesses one of the alternative sub-parts as "where to start"
within the composite. The multipart/related has a static
starting-point ("root") and the multipart/related has a dynamic
one. Once the local capabilities have been queried, the root
within the multipart/alternative is bound.
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").
It doesn't call the helper. It blesses one of the alternatives
as "root" and returns. The caller calls the helper. If the
caller was a multipart/related handler, it knows that. The
multipart/alternative resolver doesn't need to know who called
it.
It's as simple as that.
Al