Thanks Ted,
I do understand the exasperation of the various WG attendees and
the message that delay is not appreciated was very clearly communicated.
I am willing to tone down my anti-1421 retoric if I can get the attention
of the list pem-dev list members to point out the specific shortcomings
of the MIME-PEM document so they can be addressed. I would like to
avoid great delay and the unfotunate per-plenary lock-step that the
PEM documents appear to be subject to.
Greg V.
Issues Raised
-------------
1) Content-Annotation and Content-Privacy are implementation
specific headers and should not be the subject to this document.
Proposed solution: Move the text to an informative appendix or
eliminate it altogether.
2) Boundary Marker is not compatable with rfc1421 PEM
Explanation: There is no way to make the rfc1421 PEM marker a valid
MIME marker. It is possible to construct a status MIME marker easily within
most conceivable implementations.
3) The Order of the MIME body parts is opposite of the PEM parts, the
PEM Headers follow the PEM message body.
Explanation: The order is defined to be consistant with the general
MIME idea of pushing the user unreadable data to the bottom of a
message. There is no other compelling reason to preserve this ordering
if it is shown to be significantly more difficuly to implement in the
reversed order.
4) Content-type headers are specified as an addition to 1421 and
content-disposition was deleted
Explanation: Content-Type subsumes the limited functionality defined
for content-disposition and more rigorously defines the content beyond
RFC 822.
5) Canonicalization is not well specified.
Proposed Solution: Include more specific pointers to RFC 1341-MIME
where the canonical representation and encoding processing is well defined.
6) Minimal MIME compliance is too burdensome for a PEM only message
agent.
Proposed Solution: A sub-minimal MIME profile was suggested which
required only the message parsing functionality defined in RFC1421.
Ref Mon Apr 5 "Transition of RFC1421 PEM to MIME-PEM"
7) Offering choice of Content-Transfer encodings may complicate
minimal PEM parsers.
Explanation: MIME is designed to be flexible in the face of changing
network and transport technology as well as yet to be defined
content-types and character sets. MIME pem reflects this design
choice, but a minimal profile may reduce complexity.
Proposed Solution: A ASCII text PEM-only MIME implementation should
choose to always send base-64 for encrypted and quoted-printable for
mic-clear.
8) MIME/PEM does not address X.400 translation.
Explanation: Issues of X.400 translation are not addressed in RFC1421
and are subject to a separate effort. There are no cryptographic
operations to translate to the rfc1421 approach if necessary for
conversion. MIME/PEM neither makes it easier nor harder to do the
transformation.
9) Backward compatibility is not addressed
Explanation: Backward compatability if needed can be implemented by
creating a dual-protocol implementation.