Re: ISSUES LIST: Chunked Encoding

My apologies; I forgot to cc the list on one of my questions to
Phil, so that following exchange is probably a bit hard to follow.
Basically, I asked why using Multiparts in an 8-bit clean environment
was not acceptable.  The following should be understood as a reply
to that question, and my response.

> Phillip Halam-Baker writes:	 
> > 
> > Because they introduce an unnecessary osurce of error.
> > 
> > The assumption that one can form boundary strings with negligible
> > probability of collision is unfortunately false. I have a system which
> > provides a hyperterminal interface using HTML and HTTP. If multiparts
> > were put into the HTTP spec that system could not be introspective,
> > if the terminal ever relayed any of its own output it would fail.
> > 
> > The Web as knowledge system has to be introspective. That is not
> > a negotiable position. If the IETF wants to break our protocols because
> > they don't want to understand what the project is about then the IETF
> > will not be the venue for standardization.
> > 
> > Mutliparts are very much less efficient than the chunked encoding. They
> > require every byte to be interpreted in serial mode. This is simply not 
> > acceptable if we are dealing with a live video feed. In that case one 
> > would want to use low level switching to direct content at a destination 
> > without processor intervention.
> > 
> > 
> > 	Phill
> > 
> Phill,
> 	No one is interested in breaking anything; we are (all, I
> hope) interested in getting a system which interoperates as widely as
> possible, and which can be deployed in a reasonable manner.  I think
> you would find most people would agree with you that using Multi-part
> MIME is less efficient than chunked encoding because of the need for
> interpretation; that was, in any case, my reading at the meetings in
> L.A.  My question is simply: for the situations where you need signed
> parts or other footer data, what can't be done using Multipart?
> 	Looking over what you've posted on this matter, I see
> situations in which footer data is needed, and I see situations in
> which what you call the introspective nature of the Web makes the use
> of boundary strings problematic.  I don't, however, see any overlap
> between the two.  If there are overlapping cases, describing them
> would help me a lot in understanding the problem.
> 	Remember, we are talking here about what to put in 1.1, not
> the whole future of HTTP; what can we get done now that moves us forward?
> 				Ted

Received on Friday, 15 March 1996 18:07:41 UTC