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