transfer-encodings on subtypes of "message"

[John Gardiner Myers <[e-mail]>]

One issue I raised around 24-28 Feb '95 on this list with 
Subject: Issues with downconverting 8BITMIME to 7bit
hasn't been addressed, I'll restate the problem:

An MTA/gateway which is able to convert 8BITMIME messages to 7bit
needs to know, for each possible media type, whether or not it is
allowed to apply a content-transfer-encoding of "base64" or
"quoted-printable" to objects of that type.  It needs to know this
even if it has no knowledge of the specific media type--consider the
type was created after the MTA conversion code was written.  It is
impractical to get all the converting MTAs in the world reconfigured
in response to a new media type registration.

With the 1522 and 1341 documents, this was possible.  Subtypes of the
"message" and "multipart" top-level types could not be so encoded,
subtypes of all other top-level types could.

In draft-ietf-822ext-mime-imt-01.txt, this has changed.  The
requirement that no subtype of the "message" top-level type have a
transfer-encoding other than "7bit", "8bit", or "binary" has been
removed.  Section 7.2 just states that each subtype of message may
impose restrictions on what encodings are allowed.  All of the defined
subtypes of "message", however, still restrict encodings to at most
"7bit", "8bit", or "binary".

This change then simply allows new subtypes of "message" to permit
additional transfer encodings, such as "base64" and
"quoted-printable".  A converting MTA encountering an object of a new,
unrecognized subtype of "message" which contains 8bit or binary data
would not be able to know whether or not it is permitted to encode the
object using the "base64" or "quoted-printable" transfer encoding.

This change in the specification gives no real advantages to offset
this problem.  Any new type that needs to permit transfer-encodings
other than "7bit", "8bit", or "binary" could be (and in my opinion
would be better off being) made a subtype of "application".

I would like to request that this substantive change be un-done.

-- 
_.John G. Myers		Internet: [e-mail]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up