Dave Crocker / IMC wrote:
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.
Application/mime went to a Last Call as an individual submission quite
some number of months ago. At that time, I sent in these comments as
objections. There has been no action since.
I believe there is sufficient controversy over the technical aspects of
the type to warrant a forum (perhaps a Working Group) to resolve them.
In any case, it should be understood that anything which references
application/mime will be held up until application/mime completes the
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.
I certainly don't see a consensus view which disagrees with my
assessment. For example, Ned Freed states in his message of July 28
12:11:52 that "The current application/mime proposal is in clear
violation of the MIME specification." [In the context of section 6.4 of
RFC 2045.]
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.
This requires the name of the type be changed to place it under the
"message" top-level type. If it is placed under any other top-level
type (excepting "multipart", which is not applicable) then existing
intermediaries will feel free to apply a base64 or quoted-printable
c-t-e to it.
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.
There are at least two ways of doing a single s/mime function set
(signing) under any proposal. With the application/mime proposal, there
is:
* multipart/signed
* multipart/signed under application/mime
* multipart/signed under application/mime under application/mime
and so on.
(Why anyone would ever intentionally do the third way, I don't
understand, but it is handled as a special case in the current
application/mime proposal. The reason for special-case requirement in
the application/mime proposal I don't understand either.)
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.
Clearly there is OpenPGP, which would be able to use proposal (b).
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.
In the case of application/mime, it is my firm opinion that the solution
is worse than the problem. It is so general, it is capable and
extremely likely to crop up in places which are entirely unexpected,
causing opacity problems for various pieces of software.
If they are to exist at all, it is important that these opacity hacks
have limited scope. More on this later.
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.
This is the same for any of the proposals, including application/mime.
If you want IMAP or other signature-unaware MIME applications to work
with the signed content, you have to use multipart/signed.
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.
So your IMAP comment has no relevance to the relative worth of proposal
(b) versus application/mime, and your only substantive comment is the
"once and only once" comment.
Adding different types for different applications is part and parcel of
what MIME is about. It is why we have a registry in the first place.
One may re-use pre-existing methods, structure, and syntax (as proposal
(b) does), but having different media type labels for different
applications is fundamental to MIME and key to its success.
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.
Well, message/delivery-status was created about two years ago, I don't
know what would have changed since then.