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.]
FWIW, it was my understanding that the document was to be changed to restrict
the encoding to one of 7bit, 8bit, or binary. However, the document doesn't
appear to have been reposted since July, so this has not been done.
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.
Unless of course they understand that this is a composite type. But the entire
point of this type is to avoid composite treatment, of course.
In any case, I agree that this type really needs to be moved under the message
primary type, making it message/mime, not application/mime. This has the
effect of fixing the encoding problem right off the bat. I also see no downside
to this -- the type message/delivery-status has been widely deployed of late
with no observed interoperability problems being reported.
With this change in place I have no objection to this moving forward. I
continue to believe that this isn't likely to solve as many problems as people
think it will, but I also continue to believe that done right there is little
if any downside to defining such a thing.
Ned