[Top] [All Lists]

RE: yet another way to indicate related MIME body parts

1993-10-27 18:28:54

So, what header-set helps the mailer with is to make some more
intelligent message to the user than multipart/whatever which
is treated as multipart/mixed.

I'm afraid I don't see the point. You have now argued, quite successfully as
far as I can see, that it is dangerous for a reader to treat
multipart/header-set with an unrecognized initial header part in any special
way. In other words, it should be treated as multipart/mixed if the header set
isn't known. But how does this differ from handling of multipart/whatever 
would get?

Are your ideas that the first part in a header-set multipart
always can be skipped, or how should it be treated by the mailer?

multipart/header-set claims to solve some kind of problem by making it known
that the first part is somehow special. Fine. Now, a given system either
knows how to handle this special sort of entity (whatever it might be, however
it is labelled) or it doesn't. And if the structure is understood the
particulars of the labelling are not relevant.

This means that the only case that distinguishes multipart/header-set from
multipart/whatever is the one where the header isn't recognized. So, I'm
therefore asking what I see as a very reasonable question: How does the
handling of multipart/header-set differ from the handling of multipart/whatever
when the header isn't recognized? Thus far I have seen only one explanation of
how the handling might differ, which you just got finished showing is a bad

Until and unless I see some tangible reason why the semantics of a header-set
are useful to someone, somewhere, I will continue to see no point in this
proposal. I can live with it with the added parameter, but I still don't think
it is useful.


<Prev in Thread] Current Thread [Next in Thread>