From: Laurence Lundblade <lgl(_at_)qualcomm(_dot_)com>
Subject: Re: some typological errors
Date: Thu, 11 Sep 1997 10:39:58 -0700
That should not matter at all. Transfer encoding is completely orthogonal
to character sets.
I don't think so. Each charset has its own proper MIME encoding.
Before any 2022 interpretation is done all the QP
encoding will be removed. All it will see is "From ".
The difference between Base64 and QP is whether or not *partial*
encoding is possible. QP is possible and Base64 is not. If ISO 2022
text is encoded with QP partially(e.g. only spaces in ASCII part),
it is likely that encoded ISO 2022 cannot be decoded. This is real.
Experience says that QP is not suitable for ISO 2022 family.
What I suggested is to clarify that technic found in RFC 2015 is
suitable for charsets whose proper encoding is QP.
I believe this is covered by content-disposition and other. The file name
is not so important here anyway as the main purpose is using the three
letter extension as poor man's type information.
I have no experience for RFC 2148, however, I'm afraid that confusion
will occur due to three major charsets in Japan.
If suffix is important, how about restricting filename to US-ASCII?
Please note that I don't know that this solution is the best.
(3) 3.4.2.2
The protocol parameter MUST be "application/pkcs7-signature". Note
that quotation marks are required around the protocol parameter
because MIME requires that the "/" character in the parameter value
MUST be quoted.
It's nice if you clarify that the value is case-insensitive.
That's covered by the MIME standard.
To my understanding, RFC 2045 says that values of MIME parameters are
case sensitive in general. And I cannot find any sentence to define
that the protocol parameter is case-insensitive in RFC 1847. If there
is one, please tell me what page in which RFC.
--Kazu