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

Re: (INTEGOK) rough consensus

From: <hallam@w3.org>
Date: Mon, 01 Apr 96 22:14:13 -0500
Message-Id: <9604020314.AA07259@zorch.w3.org>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: hallam@w3.org
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/149

>        Content-MD5     = "Content-MD5" ":" md5-digest
>        md5-digest      = <base64 of 128 bit MD5 digest as per RFC 1864>

No, you really should remove the claim to be per RFC 1864 since the spec
as given has no connection with RFC1864 except in using the same hash function.

RFC 1864 in sofar as it says anything states that the entity is canonicalized
before the digest is applied. I believe that we have (rightly) decided not to 
introduce the canonicalization step. Therefore we are not doing the base64 of
the digest "per RFC1864)" we are doing the base64 of the digest.

>> MIME, the digest is computed over the entire entity-body, even if it
>                   may be computed

No, Roy this is wrong the disgest IS computed. If the digest is there the 
value is MD5(entity) there is no provision to allow MD5(cononical(entity)).

As specified I think that we are being given a pig in a poke. If one gets a
Content-MD5 header with this spec one will not know what the digest was
calculated on. Are implementations to be required to perform both checks on
the offchance that canonicalisation was used?

If people want to reuse an existing tag then they should accept whatever
baggage goes with it. If that involves irrelevant canonicalization steps
then so be it. If the spec diverges one should specify a new tag.

Received on Monday, 1 April 1996 19:17:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC