Steve,
Your through analysis has uncovered a few hidden assumptions that a
participant in the MIME development effort would have made that may be
foreign to the PEM group. I will try to address these in the context
of your comments.
The most contentious issue I can see is the need for co-existence
between MIME/PEM and 822-PEM. This issues can be addressed in two ways,
1) if PEM/MIME is accepted soon as a replacement for RFC1421, then
there are (I think) 3 implementations that must change. I am not aware
of a high volume of production traffic that needs to be accommodated
yet. 2) if PEM/MIME is accepted as an alternative to RFC 1421, then a
rigoruous co-existence strategy needs to be worked up, including the
basic mapping algorithm from one message encapsulation technique to the
other. Because I understand the minimal requirements for MIME
compliance to be trivial, I would strongly prefer that the first option
be pursued and that any real interoperability problems between MIME/PEM
and PEM-only be stopped before they really exist.
The lack of clear direction from the last PEM WG meeting whether
822-PEM and MIME/PEM were to be "interoperable" or whether MIME/PEM was
to be a replacement for RFC 1421 has caused the MIME/PEM proposal to
have elements reflecting both options. For example, the requirement
that only base-64 be used for encrypted messages reflects a desire to
be interoperable with minimal mapping and the exclusion of MIC-CLEAR
reflects a desire to take advantage of the capabilities of MIME to
reduce complexity and increase interoperability.
The comments with which I agree or have nothing have been deleted.
1- In section 4, the text indicates that base64
Content-Transfer-Encoding is always used for an ENCRYPTED PEM message,
but that other encodings might be used for other PEM message types.
Why? Is this trying to say that a signed (but not encrypted) message
may be transferred without encoding, i.e., MIC-CLEAR? If so, can't
this be said more directly? If not, what is the intent? If I can
choose other encodings for non-ENCRYPTED messages, then why can't I
choose them for encrypted messages too? If there is a desire to be
backward compatible with 822-PEM, then I think more specific text is
needed. If the intent is to permit greater flexibility in the choice
of Content-Transfer-Encodings, then why are ENCRYPTED messages
constrained?
The Base-64 restriction reflects a desire to be able to make a 822-pem
message out of an MIME/PEM message with the simple use of a cut and
paste editor or a simple conversion routine.
MIME does not generally specify which content-transfer-encoding to use
for a body part and leaves the choice up to the UA, which has knowledge
of the actual data to be encoded. From an implementation standpoint,
the choice of base-64 vs quoted printable is often made with respect to
efficiency. If 8 bit characters are more than one third of the text
then base-64 is more efficient. Because encrypted text is generally 1/2
8 bit characters, there will be almost no case where quoted printable
will offer any advantage in an encrypted message.
Requiring base-64 does not cost much and may allow the construction of
a 822-pem document from a MIME/PEM document for the case of encryption.
With the inclusion of quoted-printable as an option for MIC-ONLY this
argument is no longer compelling and I would agree to dropping the now
gratuitous requirement.
2- The boundary parameter defined for the multipart-pem
content type, and used in later examples, differs from the marker used
in 822-PEM, but no motivation is provided for the difference. Since
this introduces an incompatibility with the existing PEM
specifications, should not the motivation for this difference be
discussed here?
There is no way to make the 822-PEM boundary marker a valid MIME
marker. MIME markers are symmetric, the start and end are identical
except for a trailing "--" on the ending marker. Once you accept the
premise that MIME message structuring is used, you have to MIME
boundary markers. One can specify a boundary marker to be any
arbitrary text, such as a marker looking very close to the "-----
BEGIN PRIVACY..." marker but if this was hard-coded it would cause a
violation of MIME in the case where there where nested PEM bodyparts.
3- The order of bodyparts in the pem Content type reverses
that currently employed in PEM and defined in the proposed standard.
The resulting format would seem to require greater modification of
current, compliant PEM implementations. The ID observes that this
transposition is motivated by a desire to make MIC-ONLY messages less
visually confusing to users not employing a PEM-capable UA.
It is not clear this makes implementations any more complex. This
choice likely reflects a design goal to reduce the crud at the
beginning of a message. I gather any arguments I will make will begin
rehashing arguments likely made years ago, but I will note that on a
non-mime, non-pem mail reader, I can reduce the normal RFC822 headers
to 3-4 lines with header filters. No such filter is available on the
body parts. If this is a major religious issue, I can live with any
placement. (Maybe crud will convince people to upgrade!)
4- Section 5 indicates a requirement for Content-Type headers,
butr makes no mention of the relationship to the existing PEM
Content-Domain header field. I've already seen some potential
confusion here, with folks transporting non-USASCII data in a PEM body
but carrying the Content-Domain as RFC822. The intent of
Content-Domain is to describe the character set and canonicalization
rules that a receiver must apply to a message. At a minimum we need
to reconcile these two fields.
In the context of the MIME structures, the content-domain does not buy
you anything not available in a content-type header. Both content-type
and content-domain have the same goal. If using MIME, It seems
reasonable to use the built-in mime mechanisms. In MIME, all non-ASCII
data must be explicitly labeled as to its type and all non-ascii text
must be labeled with the specific character set. The canonicalization
should always be performed in the normal MIME order.
8- In section 5.1, step #4, the Content-Transfer-Encoding
discussion could be clearer (and "insure" should be "ensure"). In PEM
there is a clear option for the user to select MIC-CLEAR vs. MIC-ONLY.
Here, it is not clear that such an option is intended to be user
accesible, despite the different service provided. The description
here sounds as if MIC-CLEAR functionality might become the default
(based on how one reads the warnings, recommendations, etc.). This
needs to be made less ambiguous.
I would agree with requiring quoted-printable encoding for all mic-only
which would otherwise qualify for "7-bit" encoding to increase
reliability and interoperability. If implemented well,
quoted-printable on ascii text can as readable as unencoded text.
(generally only end-of-line markers need be added.)
11- Examples are very important to understanding this proposal
and I'm gald to see some included. However, none of these examples
include ENCRYPTED messages, or recursive use of the proposed
structures. It would really help to see less trivial worked examples,
with thorough annotations, to inspire confidence that the proposed
processing algorithms are consistent and comprehensive.
I agree and will work with Ned to create a more complex example. The
issues in having PEMed parts not enclosed with a mic-only seems to be
one of the several issues that may arise with a more interesting
example.
Greg Vaudreuil