Kazu,
Just in case you misunderstand my opination. I'm not objecting to 7bit
restriction of Multipart/Security at this time. (Yes, I don't like it
but the point is not that.)
I'm asking not to recommend (ie SHOULD) MIME encoding for "7bit"
character set. ISO-2022-{JP,KR} is 7bit (not 8bit) and almost all user
use it as raw (i.e. without base64) in daily life even with MIME UAs.
I'm trying to understand your point, but still have difficulties.
You are basically arguing that
(1) iso-2022-{jp,kr} is a character encoding which can be
represented in 7bit data,
(2) base64 is the encoding best applied when MIME encodings are used
at all, and
(3) this will make messages unreadable to most mail user agents used
in Asia.
Is this correct?
I suppose that your preferred solution would be to mandate
binary-mode signatures, so there is no need to give extra protection
to trailing whitespace. However, specifying this would mean that
most current implementations don't conform to the spec, unless I'm
severely mistaken. Florian?
Anyway, we do of course have these two options:
- Break working implementations by mandating binary mode signatures.
- Break MUAs which aren't MIME-aware by requiring the application of
MIME encodings when they aren't necessary from a pure MIME point
of view.
What do people think about this?
While we are on it, I think we should restore the section from draft
-01 concerning "From " lines, and move it, so that section 3 would
look like this now (changed line tagged with "!", added lines tagged
with "+"):
------------------------------
3. Content-Transfer-Encoding restrictions
Multipart/signed and multipart/encrypted are to be treated by agents
as opaque, meaning that the data is not to be altered in any way [2],
[7]. However, many existing mail gateways will detect if the next hop
does not support MIME or 8-bit data and perform conversion to either
Quoted-Printable or Base64. This presents serious problems for
multipart/signed, in particular, where the signature is invalidated
when such an operation occurs. For this reason all data signed
according to this protocol MUST be constrained to 7 bits (8-bit data
MUST be encoded using either Quoted-Printable or Base64). Note that
this also includes the case where a signed object is also encrypted
(see section 6). This restriction will increase the likelihood that
the signature will be valid upon receipt.
! Additionally, if body parts to be signed contain trailing whitespace,
implementations SHOULD use either Quoted-Printable or Base64 to
protect these body parts against corruption by transport or delivery
agents. Applying this rule also ensures that trailing whitespace in
the data encoded cannot be modified without invalidating the
signature. Applications SHOULD ensure that no trailing whitespace is
present after the MIME encoding has been applied.
Note: Trailing white space does not alter the actual contents of a
Quoted-Printable or Base64 encoded body part, or the meaning of
MIME headers. However, the presence of trailing white space may
trigger a compatibility problem which was introduced in [1]: With
traditional implementations of PGP, trailing whitespace was
included with signatures of canonical text documents. [1] changes
this behaviour in an incompatible way, by specifying that trailing
white space is ignored in signatures of canonical text documents.
+ Note: If any line begins with the string "From", it is strongly
+ recommended that Quoted-Printable encoding be applied and that at
+ least one of the characters in the string is encoded using the
+ hexadecimal coding rule. This is because many mail transfer
+ agents treat "From " (the word "from" followed immediately by a
+ space character) as the start of a new message and thus insert a
+ right angle-bracket (>) in front of any line beginning with "From"
+ to distinguish this case, invalidating the signature.
Data that is ONLY to be encrypted is allowed to contain 8-bit
characters and therefore need not be converted to a 7-bit format.
Implementor's note: It cannot be stressed enough that applications
using this standard follow MIME's suggestion that you "be
conservative in what you generate, and liberal in what you
accept." In this particular case it means it would be wise for an
implementation to accept messages with any content-transfer-
encoding, but restrict generation to the 7-bit format required by
this memo. This will allow future compatibility in the event the
Internet SMTP framework becomes 8-bit friendly.
------------------------------
Cheers,
--
Thomas Roessler <roessler(_at_)does-not-exist(_dot_)org>