ietf-822
[Top] [All Lists]

Content-Canonicalization: crlf?

1995-12-08 14:15:07
I have recently been looking at what's involved for implementing MIME with
the new security multiparts draft and have come upon what seems to be a
general MIME ambiguity.  For a received message, it's not clear when one
should convert a body part from canonical line ending to local line ending.

Current practice seems to be to either let it be done by the mechanisms in
place now which convert non-MIME messages (e.g., the UNIX MTA).  This works
for body parts that have either no or qp transfer encoding.  Then, in the
case of base 64 to undo the canonicalization for types text/* and
message/rfc822.

I've taken a look at 1521 and the MIME conformance draft and it's very
clear how a message should be constructed, but it's not clear how a message
should be unpacked.  It seems this should be clarified at the very least.

Another possible solution seems to me to be the introduction of a
content-canonicalization: header to indicate canonicalizations have been
applied and should be removed when unpacking.  I think this may be a good
solution since it is canonicalization is appropriate with different
content-types: (e.g., application/postscript is a candidate for line ending
canonicalization).  Also canonicalization should not be associated with
transfer encoding.  At the moment line ending canonicalization is the only
obvious transformation, but there might be others.  One other one I can
think of might be conversion to IEEE standards for binary representation of
floating point numbers.

Thoughts?

Laurence Lundblade     <lgl(_at_)qualcomm(_dot_)com>
Qualcomm, Inc.         619-658-3584