Well, you would also need to either have the initial command indicate
how many multiple commands are going to be sent, or else have some
kind of terminator so the server knows when to stop listening for
commands. Of course, similarly, the multipart structure would need a
length header just as all requests with nonempty bodies do, unless you
prohibit epilogues.
> To me a MIME message only
>makes sense in the context of a single message consisting of multiple
>parts.
To me, multiple requests encapsulated into a single request is very
much analogous to multiple messages encapsulated into a single
message, considering how close a request is to a message. (and
likewise for responses, of course.)
>By my reading of MIME each part is allowed to have its own headers, but
>NOT its own command.
Um, I'm not sure I know what you mean by this. We define a MIME type
which is allowed to have a command. What's the problem? I think
you're confusing the headers of the body part in the multipart
structure with the headers that are part of the object?
>Also the content boundaries are in practice much less useful than
>content length encoding since there is no guarantee that a boundary
>does not occur in text and no escape mechanism
Sure there is. The composing software gets to decide what the
boundary is, and presumably can choose something that isn't in the
rest of the message (which it knows.) It's not like RFC934 where the
boundary string was static and an escape mechanism was needed. Which
is cleaner is a matter of opinion; I think it's about even either way.
The real distinction here, I think, comes down to two differing
philosophies on the development of HTTP:
a HTTP requests and replies are very similar to MIME messages in most
respects. This similarity is no accident, and in general
functionality which is already defined in MIME should carry over to
HTTP with minimal change unless there is a very good reason to do
something else.
This allows consistency, enhances the degree to which existing
software can be used to handle both kinds of information, allows
HTTP to be easily transported along any existing communication
channel capable of handling mail messages, etc.
In brief, solutions for which there already exist definitions,
spec, and software are to be preferred, even if they may seem a bit
more complex in the short run.
b HTTP uses MIME Content-Types because they are a useful, general
mechanism for labeling information. Similarly, HTTP requests and
responses have headers and bodies because such has proven a useful
distinction in other contexts and there seemed no point in
reinventing the wheel.
However, there's no reason for HTTP to solve other problems the same
way MIME does unless it's clearly the best way for HTTP to do so.
For instance, MIME separates multiple parts with boundaries because,
in general, length headers cannot be used in mail because hostile
MTAs may perform transformations on messages which change their
length (though some stubborn UAs attempt to use them anyway.) But
HTTP, when used directly, doesn't have that concern and therefore we
don't need to use that solution.
In brief, solutions which seem simple and straightforward are to be
preferred, even if other potentially applicable answers exist.
I tend towards the "a" camp of the above, but can certainly see the
other side (which is what I think I hear Phillip saying.) What about
other aspects? How should binding work, for instance? Is it even
worth bothering to try to ensure that the requests and responses can be
encapsulated and bursted without any modification?
- Marc
-- Marc VanHeyningen mvanheyn@cs.indiana.edu MIME, RIPEM & HTTP spoken here