Re: ISSUES LIST: Chunked Encoding

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:34 UTC