[Top] [All Lists]

Re: yet another way to indicate related MIME body parts

1993-10-25 12:37:02
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