I've read Keith's draft, and I'm surprised at how much I like it. I
think that Keith has added to the value of this idea significantly with
the "start" parameter and the internal reference type. I think this is
the first draft of this type that really lets you do some things more
easily than with a new multipart/foobar type for each application. I
particularly like having the "start" parameter in the enclosing
multipart header, because it gives a general-purpose MIME parser (e.g.
metamail) a way to tell what program to call on the inner stuff, which
unparameterized types like "multipart/header-set" really didn't offer.
One technical question: What should a MIME-reader do if it implements
multipart/related, but doesn't recognize the type of data in the "start"
object? You obviously prefer to avoid this case by using
multipart/alternative, but it will inevitably happen!
I'm still a bit skeptical about the appendix. That's a lot of work to
go through for inventing file names. A possibly simpler approach would
be to pass the inner program the name of a directory file, which would
contain a line for each body part, of the form
<content-id> filename
Sounds at least as good, and a LOT easier to implement.....
Anyway, I really like this draft. Is there any chance that the authors
of multipart/header-set, multipart/related, multipart/reference,
multipart/appledouble, and multipart/enabled-mail could all get together
and refine this into something we can all use? -- Nathaniel