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.
Actually, I'm not sure I understand the difference between having a start
parameter that can indicate any body part, and always having "start" be the
first body part (as in header-set). In either case the mail reader has to
look at the headers for that body part before processing the mail.
(but either one of these should be easier to deal with than multipart/foo)
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 think it's just like when a mail reader doesn't recognize any other
object -- it refuses to present it, and maybe offers to save it in a file.
In this case the object saved in a file would presumably be the entire
multipart/references object.
If the "start" object can't be displayed, sometimes it makes sense to have
the mail reader present the individual objects, sometimes not. If the sender
wants the fallback behavior he should use multipart/alternative for the start
object.
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.....
Perhaps. But you at least have to decide how to pass the name of the
"directory file" to the inner program. command-line? standard-input?
(I suppose this could be metamail-configurable.)
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
I hope so!
Keith