> We seem to have a wide variety of beliefs about how Content-Length
> and boundary strings interact when a part of a multipart/* contains a
> Content-Length. I prefer the behavior described by the last
> email in this series. But this exchange shows a lack of consensus.
> Can we reach consensus, or this an email versus HTTP difference in
> behavior?
This whole exchange is a good illustration on why I'm opposed to the
reuse of HTTP/1.1 for non-web applications, including a printing
protocol. HTTP/1.1 is a real mess. MIME is also a real mess. They
are messy because they needed to be backward compatible with a widely
deployed installed base, while adding new features not anticipated for
in the original protocol design. Any new printing protocol will have
its own baggage also. Should it then inherit additional baggage from
HTTP and MIME?
Being able to print from a web browser would be a Good Thing, but I
seriously question whether it's worthwhile to standardize this
interface. Printer shops are going to need to add their own
front-ends anyway, for queueing and to add additional services not
supported directly by a printer.
It would be far better to define a new protocol which doesn't inherit
the baggage of HTTP/1.1. The "baggage" isn't the amount of code
required to implement the protocol, it's the difficulty in dealing
with lots of protocol variants -- caused by multiple earlier versions
with ill-defined specifications, as well as future changes to HTTP --
and the resulting lack of interoperability and increased
testing/support costs.
(not to mention the overhead of having arguments about whether
Content-Length is valid within a multipart content which is carried
over HTTP.)
It seems like the lpr problem all over again, only worse.
(Except that the one thing "right" about the lpr protocol design is that it's
framing protocol is almost foolproof -- a byte count followed by that many
bytes.)
Do you really want to burn HTTP/1.1 and MIME support into printer
ROMs? Why not use something which is simpler and easier to get right?
Keith
p.s. Use of Content-Length *within* a multipart (as opposed to the
top level) seems like a huge design botch precisely because it begs
the question of what happens if Content-Length is wrong (as it often
is). If there's really a good reason for using it within a multipart,
I'd like to know about it.