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.
Actually, I don't think it violates 2.2.1 at all. 2.2.1 says:
Media types must function as an actual media format: Registration of
things that are better thought of as a transfer encoding, as a
character set, or as a collection of separate entities of another
type, is not allowed. For example, although applications exist to
decode the base64 transfer encoding [RFC 2045], base64 cannot be
registered as a media type.
This requirement applies regardless of the registration tree
involved.
Now, obviously the part in question is whether or not application/mime is an
media type which is "better thought of as as a collection of separate entities
of another type". But the entire point of application/mime is to have an
composite object where the entities inside should NOT be thought of as
separate.
So the real question is, is the case for having such a media type sufficiently
strong? If it is then the registration process allows it, if it doesn't then
the registration process effectively bans the registration of this type.
Note that I'm not taking a position here. I'm fairly ambivalent about
application/mime -- while I think it may solve an immediate problem, the
long-term result will be that gateways will learn to treat application/mime as
a composite object (mine already do) and hence we'll be back to square one. The
only long term solution is to get gateways to Do The Right Thing when presented
with multipart/signed. However, the cost of application/mime, modulo the
encoding issue, which can be gotten rid of, is small. But so are the long term
benefits.
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.
Hmm. An interesting idea. It would certainly eliminate one level of MIME
structure and would limit the utility of this type. And perhaps gateways would
learn to leave this alone, since its function is clearly associated with
signatures. I think I like it... Note, however, that the implications of 2.2.1
would also apply to application/signed.
Ned
P.S. I had the registration of things like application/mime in mind when I
wrote 2.2.1, BTW.