W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: ISSUES LIST: Chunked Encoding

From: Dirk.vanGulik <Dirk.vanGulik@jrc.it>
Date: Sat, 16 Mar 1996 00:31:55 +0100
Message-Id: <9603152331.AA09609@ jrc.it>
To: hardie@nasa.gov
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

Ted Wrote:
> > 
> > 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.

Althoug I quite agree with that the parsing of multipart mime is expensive, I'd
do have a factual problem with the statement that 'the probability of collision
is unfortunately false'. 

It should be understood that the boundary string does not need to be random,
nor does it need to be unpredictable; in fact making it random and/or unpredictable
increases chance of collision. Where the text 'whole unpredictable' a completely
fixed string whould be the best boundary string; that is any fixed string of 
given lenght. (Sorry for the crappy translations; but I lack the english 
vocabulary to get the mathematics across)

However, as you assert rightly, the message conveyed is not unpredictable. Now proof
can be given that a multi variant string which is a function of the text it signs and
a function of history has almost the same chance of collision as a *fixed* string 
with a random text. 

In practive, some cheap Lenght, MD5 or CRC of the text signed combined with the 
results of a function which is a function of the previous resoult (say a counter, 
timer, etc) nears the optimum. You might want to consult literature on Number 
theory and most books on encryption might help you out as well.

> > What can be done to move us forward.

I would very much prefer to have *both* chunked and multipart.  As this allow the 
server builders to choose and to optimize; it is easy to envision senarios where
either of the two would excell, or where the difference between server resources
and programming resources are large.

Dw.
Received on Friday, 15 March 1996 18:07:53 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:48 EDT