- From: Keith Moore <moore@cs.utk.edu>
- Date: Thu, 01 May 1997 21:43:28 -0400
- To: Robert Herriot <Robert.Herriot@eng.sun.com>
- Cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, moore@cs.utk.edu
> 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.
Received on Thursday, 1 May 1997 18:46:00 UTC