Re: Content-MD5

> Content-MD5 represents a message attribute.  Content-Digest does not.
> Content-MD5 allows the recipient's semantic parser (the step after
> message parsing) to determine if an MD5 has been calculated without
> parsing the contents of any particular field.  Content-Digest does not.
> Content-MD5 will make it easy for me to define a generic IMS construct of

>     GET / HTTP/1.1
>     Unless: Content-MD5 eq "qyeur87168587646846109hgs=="

> or

>     PUT /happy HTTP/1.1
>     Unless: Last-Modified ne "Mon, 06 Nov 1995 00:51:58 GMT"

> Content-Digest would not.

> From a perspective of having designed several HTTP systems, Content-MD5
> (and Content-SHA, Content-Sum, etc.) is a better design choice for the
> HTTP protocol.  Until it is proven otherwise, Content-MD5 will be the
> preferred choice for HTTP.

Roy, this is a very interesting point, and its one I admit I hadn't given
adequate consideration to. In fact I think I finally see what John Myers, one
of the coauthors of the content-md5 specification, was driving at in a
conversation we had one time about this stuff. I believe his implementation 
uses rules similar to what you've described to convert MIME into an internal
format.

The issue I've always thought of in the past with having multiple algorithms is
that when it comes to adding a new digest scheme most of the work lies in
adding the code to support the new digest calculation anyway, not in the rather
trivial changes needed processing another header field. And I still think this
is the case. But as long as the MD5 value could only appear in one place I
didn't care so much where it was, and while I did favor the "put it in the
header content" approach I now see that there are actually some advantages to
putting it in the field name.

				Ned

Received on Monday, 6 November 1995 02:13:09 UTC