Re: canonical MIME headers

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 
engines.

> 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
:-)

Cheers.

---
Steve Hole
Chief Technology Officer -  Electronic Billing and Payment Systems
ACI Worldwide - MessagingDirect
<mailto:Steve.Hole@MessagingDirect.com>
Phone: 780-424-4922

Received on Friday, 9 November 2001 15:37:42 UTC