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-4922Received on Friday, 9 November 2001 15:37:42 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:29 GMT