ietf-smime
[Top] [All Lists]

application/mime objections

1997-10-01 14:34:51
To recap, my objections to the document's use of application/mime are:

1) The type is not registered and does not have a referencable
specification.

2) The type violates the MIME specification, specifically section 2.2.1
of RFC 2048 and the restriction of transfer encodings on composite
objects in section 6.4 of RFC 2045.

This implies that in order to register the application/mime media type
it would be required to change to the base MIME spec, probably resetting
MIME to Proposed.

3) The possibility of a reader encountering binary MIME objects
underneath a transfer encoding applied to the application/mime object is
not adequately documented.

The author of the application/mime specification has stated that this
implication of the type was not considered or intended, and expressed a
desire to prohibit transfer encodings being applied to application/mime
objects.  The only technically effective way to prohibit transfer
encodings on the type is to place it under the "message" top level type,
as intermediaries routinely feel free to transfer-encode arbitrary
subtypes of "application".

I see three alternatives for replacing the use of application/mime in
the document:

a) signedData

This alternative requires the least specification and deployment work. 
It requires more work of gateways which want to convert between the
"tunneled" and "transparent" types.

b) application/signed

This is my proposal for a type which is exactly like multipart/signed,
except the contents are labeled "application/signed" instead of
"multipart/signed".  Since the proposed type is under application, it
may have a non-trivial transfer-encoding applied to it (implying that
readers must be able to handle binary data underneath such an encoding)
and it does not have the default-to-multipart/mixed semantics of
multipart/signed.

As application/signed would be restricted to carrying only signed data,
it would avoid the MIME violation problems in (2).

This alternative requires more work to specify.  Deployment work is
roughly equivalent to application/mime.  The work required of gateways
to convert between the "tunneled" and "transparent" types would be
trivial.

c) message/mime-entity

This is "application/mime" moved underneath the "message" top-level
type, in order to get the transfer encoding restrictions of the
"message" top-level type.

It is unclear to me whether or not such a type violates section 2.2.1 of
RFC 2048.  Such a type is incapable of carrying binary signed objects
over non-binary transports, a disservice to the voice mail community.  A
similar concern applies to 8-bit signed objects.

This alternative requires work to specify, probably equivalent to (b). 
Deployment work is equivalent to application/mime.  Work required of
gateways is probably between application/mime and signedData, as
gateways may have to deal with the case where a multipart/signed object
cannot be tunneled inside a message/mime-entity because of transport
encoding restrictions.

I personally consider this alternative to be inferior to (b).

<Prev in Thread] Current Thread [Next in Thread>