Subject: some requests

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 22 Jan 2001 21:42:45 +0900 (JST)

I would like to request one thing to openpgp-mime-02.txt.

Section 3 says:

   Additionally, if body parts to be signed contain trailing whitespace,
   or lines beginning with the five characters "From ", 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.
      
I feel that "SHOULD" is too strong. I have two reasons.

(1) In the ISO-2022 environment (including Korean and Japanese), for
    long historical reasons, applying CTE: breaks inter-operability
    between MUAs. Even base64, which is considered more suitable to
    ISO-2022-{JP,KR} than quoted-printable, should not be applied to
    ISO-2022-{JP,KR} anyway. So, SHOULD is too strong for this kind
    of environment.

(2) This rule implies that MUAs SHOULD search "From " pattern from
    text in a deeply nested multipart. This is too tough for many
    MUAs.

--Kazu

---

From: Derek Atkins <[email-masked]>
Date: 22 Jan 2001 11:58:18 -0500

Kazu,

It's a SHOULD: you can be perfectly compliant and NOT implement it.
That's the point.  A SHOULD is a strong recommendation to do something
that way, but it is not required to be implemented in order to be
compliant.  Indeed, it's a directive to an implementor for how to
solve the problem in an interoperable way.

Just because it's not the right solution for a couple of environments
only means that those environments SHOULD ignore the SHOULD :)

-derek

PS: How does applying a CTE break interoperability?  Any MIME-aware
client MUST implement CTE anyways, so it should decode the base64 well
before it gets up to the user.

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Tue, 23 Jan 2001 15:33:40 +0900 (JST)

Derek, 

Thank you for your reply.

From: Derek Atkins <[email-masked]>
Subject: Re: some requests

> solve the problem in an interoperable way.

This explanation sounds that it is an optional. According to RFC 2119,
options should be specified as "MAY".

RFC 2119 also says that the full implications must be understood the
SHOULD functionality. So, for instance, if any Open/PGP UAs for
"qmail", which don't have the "From " problem, don't implement this
encoding stuff, we can't call them fully-conformant.

> before it gets up to the user.

There are still many non-MIME UA users. 

BTW, do you know any region where base64 is actually used for
text/plain? If we use base64, readability becomes drastically poor.

For example, Chinese people uses GB-2321 character set, which is 8bit
and base64 is suitable if required. However, they tend to send GB-2321
text with CTE: 8bit (without base64) for readability. (Most SMTP
channels in Asia are 8bit clean.)

--Kazu

---

From: Derek Atkins <[email-masked]>
Date: 23 Jan 2001 14:58:11 -0500

> There are still many non-MIME UA users. 

Yea, but we're defining a MIME type.  We can't be defining MIME types
for people who don't use MIME.  For example, the sender doesn't know
that the recipient does not understand MIME, and if they did they
shouldn't be sending MIME in the first place.  Sure, we can TRY to be
as compatible with non-MIME-mailers as we can, but I don't believe
that we should bend over backwards just to make it easier for them,
when quite frankly those non-MIME users wont be able to read many MIME
messages in the first place.

> text/plain? If we use base64, readability becomes drastically poor.

Yes.  I've been receiving messages from someone in, I believe, Korea
(I don't have the mail in front of me, but I seem to recall it was a
.kr address) who has been sending me English text/plain using base-64
encoding.  Quite annoying, I must say.  But it's still being done.
Why?  I don't know.  What if I couldn't read it?  The sender probably
has no choice in the matter.  Is their mailer non-conformant?  I don't
know.  But honestly, if they tried to sign their base-64 message, then
what?  Well, if I couldn't read MIME, I couldn't read their original
message anyways, so what does it matter?

> channels in Asia are 8bit clean.)

I'm currently of the mind that we should not require base-64 encoding,
but we should encourage base64 encoding.  Basically if you, as a
sender, know that you have an 8-bit clear channel to your recipient
you should be allowed to send an 8-bit message.  However, if you are
not sure you have an 8-bit channel then you should base-64 encode your
message.  I just wish there were an easy way to determine ahead of
time if there is an 8-bit clean channel.

-derek

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 24 Jan 2001 12:21:57 +0900 (JST)

Derek,

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.

> messages in the first place.

Multipart/Security is designed to maintain both to non-MIME UAs and
MIME-aware-but-Multipart/Security-unaware UAs. Both users can at least
read the first. Yes, it requires 7bit restriction. 

But why should we use base64 to 7bit character set?

> encoding.

I guess this is a bug. Not represents typical UAs in Korea.

> time if there is an 8-bit clean channel.

Maybe my explanation is wrong. GB-2321 is an example that how base64
is unfriendly to the real world in Asia. Of course, base64 is required
for GB-2321 when a signature is calculated.

Encourage base64 encoding for any and all character sets seems to me a
bad idea. A right way is to encourage people to deply 8bit clean SMTP
channels.

--Kazu