Aapp/mime got a number of public reviews, most especially on the
non-ietf
s/mime list (egad, a summer ago)? Out of all that it looked like folks
were generally comfortable with it.
I'm not sure it has been well reviewed by the MIME community. The type
does appear to violate section 2.2.1 of RFC 2048, so its movement onto
the standards track is an amendment of the base MIME spec. It may well
be necessary to amend MIME in this way, but the change and its
implications should be called out.
I definitely understand that some modificaiton or exception to the "no
recursive encodings" rule of MIME is necessary to support digital
signatures. I currently would prefer a more limited appliation/signed
type (application/signed being identical to multipart/signed except for
the lack of transfer encoding restrictions and default handling) but
could be convinced of the need for the more general type.
An application/mime can transport a binary MIME object. It is the first
It can?? I thought c-t-e binary wasn't currently part of the
standard, at
this point? In any event, please elaborate. How can it do that?
c-t-e binary is currently part of the spec. It's just that, in the
e-mail domain, there aren't a whole lot of existing transports that are
capable of transporting it. Those transports that are capable of
transporting it are in different domains and/or enclaves (e.g. voice
mail, http)
Application/mime creates a way to transport these things within the
e-mail domain. One can create a binary MIME object, place it within an
application/mime, apply a transfer-encoding (base64) to the body of the
application/mime, and transport the result over a 7-bit or 8-bit
channel.
It needs to be understood that
implementing application/mime will require rewriting these MIME
There just might be some other outcomes, I suspect, if we seek them.
In
any event I had the impression that c-t-e binary is not in widespread use.
Why will app/mime change that? Why will objects encoded in c-t-e binary be
put into app/mime with any more frequency than they are now?
c-t-e binary is not in widespread use because the vast majority of
transport systems and mailbox formats are incapable of handling messages
with arbitrary binary data. Most problematic are CR or LF octets which
are not part of a CRLF pair. Many mailbox formats or runtime libraries
represent CRLF pairs as a single LF octet--such systems are incapable of
representing the existence of a lone LF octet in the original message.
Many MIME readers are written to only read MIME messages which have had
their CRLF pairs encoded as single LF octets, and thus are incapable of
handling arbitrary binary MIME messages.
application/mime changes this because it permits the tunneling of a
binary MIME object through these non-binary-clean transports and mailbox
formats. A MIME reader which is extended to interpret application/mime
recursively now has a channel by which binary MIME objects can get to
it.
The application/mime document is also entirely missing an explanation of
the canonical encoding implications of the type. The contents of an
application/mime are in canonical (CRLF-separated) form, and this must
be made clear. Many MIME parsers deal with MIME entities which have
had CRLF sequences encoded into a local form of line break. Such MIME
Well, there's certainly nothing wrong with reminding the spec reader
that
objects being exchanged over the Internet are required to be in network
standard form. On the other hand it would be interesting to see an
implementor try to send off a locally-encoded object -- inside app/mime or
any other standardized form -- and claim that recipients should be able to
handle it.
Experience seems to show we have to keep belaboring this point. Make
sure to mention it MUST be in canonical, CRLF-separated form, and give a
reference to section 4 of RFC 2049.