Re: Content-MD5

>As I said before, the IETF generally doesn't standardize two different
>ways to do the same thing.

There are enough exceptions -- OSPF/whatever-it-is, usenet/email,
pre-snmp/pre-whatever-it-was, character sets, -- that I am glad you picked
the word generally.  I'll claim you left enough open space by using that
word that you did not say I am wrong and therefore while it may be
an exception, it is possible.

>I could go on and on, but suffice it to say that objections to protocols on
>the basis of duplication of function are taken very, very seriously, and
>such objections are going to be made should an attempt be made to standardize
>some alternative to content-md5 without a clear understanding of how it
>interacts with content-md5. I will object myself in my capacity as a member
>of the Applications Area Directorate if it comes down to it.

Fine.  Glad I can count on your vote. :(.  When it comes time to use SHA
or some other hash -- or multiple hashes -- you will vote against a single
combined header rather and would rather have two headers.  I think that
is being stupid, but I will not write 2K of text trying to convince you
otherwise.  In fact, I hope to write no more after this note.

>If it doesn't matter then what are your objections to content-md5?

Did we really have that big a communication gap?  MD5 is a fine hash, it's
performant enough for now and seems solid.  (Was it MD4 or MD5 that just
had the collision?)  I would rather not have the hash name appear in the
header, based on my implementation experience.  (Arguably the first
widepsread use on Usenet, if not the Internet.)  After disucssion with
one of the RFC authors, I withdrew my objection.  There is nothing in
this paragraph that is new, I only wrote it to save you a trip to the
archives.
	/r$

Received on Sunday, 5 November 1995 16:34:58 UTC