Subject: Re: IPP>PRO - http comments

From: [email-masked] (Robert Herriot)
Date: Thu, 1 May 1997 12:45:57 -0700

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?

I have summarized the differt opinions below.

>From [email-masked] Wed Apr 30 23:10:31 1997

	The meaning of multipart is defined in the MIME specifications.
	Content-Length isn't part of the multipart definition.
	As such, it's only a comment, and should be ignored.

>From [email-masked] Wed Apr 30 18:51:51 1997

	It is illegal to send content where the content-length and the boundary
	string disagree. So one doesn't take priority over the other. A
	recipient should signal an error if it detects that they are
	different.

>From [email-masked] Wed Apr 30 18:51:51 1997 in reply to my question
to his reply above

	BH> If there is a Content-Length header with a value of n, can the program
	BH> skip over n bytes without looking for an erroneous boundary-string
	BH> within the n bytes?
	
	I think that a careful program would use the content-length to
	check the boundary-string, rather than vice versa. However,
	"non-standard values are non-standard"; there's only so far
	you should go in a standard saying what programs have to do when
	confronted with non-standard input.

>From [email-masked] Thu May  1 09:14:39 1997 replying to Larry's comments

	I agree with the first part but not the second.
	
	If you see a content length the obvious thing to do is to avoid the
	computationaly intensive check of each byte (yes O(1) is less than
	anything Boyer-Moore can do and that is not subjective). You
	hop straight to the boundary.
	
	If you see a boundary marker ther, then its OK other wise you signal
	an error.
	
	Note that if there are additional boundaries within the content length
	delimited block you don't see them. 
	
	So content length should take priority but you may in some cases be 
	able to detect an error.
	
	>Senders that are at all uncertain about the length of the data should
	>omit content-length and rely on the boundary alone.
	
	Yep

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 May 1997 21:43:28 -0400

> Can we reach consensus, or this an email versus HTTP difference in

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.