- From: Dirk.vanGulik <Dirk.vanGulik@jrc.it>
- Date: Sat, 16 Mar 1996 00:31:55 +0100
- 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 UTC