Re: Content-Digest header

Chris Newman writes:
 > I believe the proposal draft-demailly-cd-header-00 is extremely
 > counter-productive.
 > 
 > My concerns:
 > 
 > 1) Creating a new mechanism to provide an existing service (Content-MD5)
 > would cause user agents to be more complex with no gain in functionality.
No major http UA use Content-MD5
and no server at all produce them
 > 2) Allowing more than one digest algorithm is harmful to interoperability.
Some user *will* need other algorithm
If not today, in few monthes or years, I'll bet on that,
you need to think a bit for the future and standardize will its not
too late
 > 3) Content-MD5 is a widely deployed Draft Standard protocol.  It works well
 > in practice.  It is unlikely the IETF will permit an incompatible method for
 > doing the same thing to be standardized, and I will certainly encourage them
 > to oppose this proposal.
My bike works well for some stuff, but I won't use it to go 100 miles
away
 > To address the complaints with Content-MD5:
 > 1) You have to digest _something_ and it is important that that something is
 > well specified.  Thus canonical format discussions are absolutely necessary.
 > The canonical format for http is whatever data is sent over the wire
 > as the "body".
This has to be defined, indeed
 > 2) What's the big deal of converting between base64 and hex coding?  It's
 > a few lines of code, and is only an aesthetic consideration.
It is no big deal except you can use it as hex with 0 lines of new
software... 
 > 3) If MD5 is too computationally intensive for some situation, then there
 > probably shouldn't be any digest in that situation to get reasonable
 > performance.
That's untrue
some people could be happy with unix sums, or any private digest
algorthm,
Also the Digest could be used as an opaque string by the client to do
conditional requests...etc...

dl
--
Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|...  Freedom
Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept

Received on Wednesday, 15 November 1995 19:49:51 UTC