On Sun, 17 Jul 2005, Earl Hood wrote:
I think the MIMEFORM method should key off the Content-Transfer-Encoding
(CTE) and not the content-type.
For example, if the CTE is 7bit or 8bit, the TEXT canonicalization
method is used. If quoted-printable or base64, BARE is used (since
both QP and base64 protect against transmission whitespace mutations).
For x-, non-standard, encodings, use BARE (or course, verification
is not possible if the verifier does not know how to decode the x-
encoding).
The draft is written to be similar to Digest-MD5 in most core elements
including as it applies to Content-Transfer-Encoding. In RFC1544 is says:
To generate the value of the Content-MD5 field, the MD5 algorithm is
computed on the canonical form of the data. In particular, this
means that the sender applies the MD5 algorithm on the raw data,
before applying any content-transfer-encoding, and that the receiver
also applies the MD5 algorithm on the raw data, after undoing any
content-transfer-encoding.
Similar note also exists in Content-Digest-Edigest draft (section 2.4):
Note that doing canonicalization for digest computation does not mean
that such canonicalized data is actually transmitted. Conversion and
data transformation rules for data transmission are in fact covered by
content-transfer-encoding as specified in part 6 of [RFC2045]. As it
relates to canonicalization and digest computation,
content-transfer-encoding conversion should be done on original
non-canonicalized data after the digest hash has been computed and
appropriate Content-Digest header field added. When digest is being
verified, the canonicalization and digest computation are done after
undoing any content-transfer-encoding.
So as far as draft use of content-transfer-encoding is outside of its scope
and can not be used as for content-digest processing and creation itself.
I see no reason a verifier needs to worry about what the content-type
is inorder to know which canonicalization method must be applied if
MIMEFORM is specified in Content-Digest.
I've searched through MIME and related RFCs and I could not find
definitions of what MIME canonical form implies for anything other
then text/* mime entities. That is why MIMEFORM is specifies to mean
one type of canonicalization for text and another canonicalization
for anything else.
I'm not even entirely certain about this "mimeform" canonicalization
method as its just use for purposes of saying what default is. In
pre-released version I did not have it and just said that for text
data the default canonicalization is 'TEXT' and for all other data
it is 'BARE'. It is possible that doing it that way was better and
I'm open to comments about it.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net