Nathaniel Borenstein writes:
Keith's was the first proposal of this kind that had any appeal to me at
all, but I'm now back where I was, and where Ned is -- seeing virtually
no advantage to these proposals, and a considerable downside. -- NB
I am in the same domains as Nathaniel so far, i.e. the easiest
way of parsing an object which is made up of several parts is
to enclose them in one multipart part. That part should
be tagged in some way with a description about what kind of
object it is, to make the parsing easier. But, Steve says that
adding multipart/header-set to Eudora was not hard at all, and there
is a point that IF the order of the different parts is decided,
one could continue to parse until you find the application/whatever
header part and _then_ send it to the parser.
I think this is "uglier" than having separate types for the
multipart types that exists, and I can still not see why we can't
have multipart/whatever... It's easier to understand I think.
If sameone make a "WWW"-type with lots and lots of pictures and
such in the document, I think that should be a separate type
(text with links inside) and not a multipart message. We should not
try to use the multipart type for what it isn't.
I might be the only one, together with Nathaniel, that didn't
understand the magic with header-set or related parts.
BUT, note that I think the primary goal in this discussion is to use
the SAME method for all of the future multipart messages that
exists, i.e. I will never, never use multipart/appledouble if
everyone except me thinks for example multipart/header-set is
the solution to use!
Patrik