W3C home > Mailing lists > Public > ietf-discuss@w3.org > November 2001

Re: canonical MIME headers

From: Steve Hole <steve.hole@messagingdirect.com>
Date: Fri, 9 Nov 2001 11:26:11 -0700
To: ned.freed@mrochek.com
Cc: Keith Moore <moore@cs.utk.edu>, James M Galvin <galvin@elistx.com>, discuss@apps.ietf.org
Message-ID: <EXECMAIL.20011109112611.J692@kepler.esys.ca>
On Wed, 07 Nov 2001 21:59:12 -0800 (PST) ned.freed@mrochek.com wrote:

> It would be handy, however, if we were to define a hash with the
> properties that:
> (1) Body data encodings were removed prior to hash computation, and
> (2) Each body was hashed separately and then the sequence of hashes and
>     headers hashed again.
> (3) Content-transfer-encoding indicators would not be included in the
>     hash.

Yes, it certainly would.  This would make the message insensitive to 
encoding modification in transit.   This is a highly desirable feature, 
particularly for large volume contents that would ideally be transferred 
end-to-end with BINARY encodings (audio, video, images).   Very useful.
> The advantage here would be that the result would be invariant under encoding
> changes (albeit with the remaining requirement that header ordering and
> boundaries would have to be preserved)

Yes ... I should have read on before typing above ... but I agree.

> and would allow reuse of previously
> computed hashes of body data. 

Which is highly beneficial in high volume composition and delivery 
situations like document (bills, statements, forms etc.) production 

> But all this could be done with a
> specialized micalg; there is no need to define a full canonical form.
> I've been meaning to write this up for years but I've never gotten around
> to it.

What's holding you up?   A beer?   I'm sure I could rummage one up for you


Steve Hole
Chief Technology Officer -  Electronic Billing and Payment Systems
ACI Worldwide - MessagingDirect
Phone: 780-424-4922
Received on Friday, 9 November 2001 15:37:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC