John,
At 02:36 PM 10/1/97 -0700, John Myers wrote:
1) The type is not registered and does not have a referencable
specification.
That is because it is being submitted through the standards process.
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.
From the discussion which ensued when you raised this point, I did not
see
a consensus view which agreed with either your assessment that there is a
violation or that the specification would need changing.
3) The possibility of a reader encountering binary MIME objects
underneath a transfer encoding applied to the application/mime object is
not adequately documented.
Correct. This improvement to the document needs to be made.
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
that was not what the author said. he said that there was not intent to
violate transfer encoding requirements that represent hard-won lessons with
MIME. During the previous discussion on this point, someone suggested that
this was really just like Multipart or Message and the author chimed in
that that sounded fine and that the spec probably should stated that
multipart c-t-e rules apply.
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.
This requires the least initial effort for s/mime. it require more,
long-term work to overcome the specialized nature of this trick, since
there will then be two ways of doing a single s/mime function set. It will
also require more long-term work because there is no reason to believe that
s/mime is the only activity with this requirement. Any activity which is
in the realm of Multipart/Related must also solve this problem.
gee, maybe we should try to solve it once, for everyone.
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.
this, of course, makes imap no longer work with the signed content. one
must first break open the application/signed type, knowing how to handle
such a thing.
one could say the same for application/mime, but then we go back to the
"do this task once and only once and then you don't need to keep adding
special types that do it for individual applications". application/signed
is in the latter category.
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.
I think that message/mime, or somesuch, would be fine except that my
recollection is that message/* is closed for general enhancement, based on
discussion one or 3 years ago.
d/
--------------------
Dave Crocker
dcrocker(_at_)imc(_dot_)org
Internet Mail Consortium +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 USA info(_at_)imc(_dot_)org,
http://www.imc.org
Member, interim Policy Oversight Committee http://www.gtld-mou.org