Thanks to all who sent comments on the initial list of issues and
proposed resolutions for the next MIME version. I have attempted to
incorporate all the suggestions and new issues into a single list.
Please note that I have been unable to read all the SGML/Richtext/Wide
Character discussions but have skimmed them for new issues. If I
missed something please let me know.
There are a few still-open issues. Please review this list and make
comments. In particular, a concrete proposal for solving the gateway
message/partial problem is needed and a decision to add a MIC needs to
be made.
I marked issues that seem to have reached consensus. Among those
items which are marked as accepted, I indicated a reason compatible
with the requirements for Draft Standard 1) Minor bug fix or 2) Minor
and understood enhancement or 3) Pruning of incomplete or problematic
features from the specification.
Greg Vaudreuil
1) Dot in tspecials adds unneeded complexity.
Proposed Solution: Remove the "." from the list of tspecials.
Status: Accepted as a bug fix
2) Richtext needs some changes to deal with multi-byte character sets
and new functionality. It may need to change more often then MIME.
Proposed Solution: Remove Richtext from MIME itself into a separate
document and standard.
Status: Accepted as pruning. Lots of discussion on the need for MIME
but not objecting to moving it to a separate standard.
3) Application/ODA is incorrectly defined in MIME
Proposed Solution: Remove it from MIME in favor of the definition
specified in the MIME-MHS mapping document
Status: Accepted as pruning
4) End of data in Base 64 is not tagged
Proposed Solution: Add an optional "====" to the end of the base64
encoding
Status: Accepted as a bug fix
5) A content ID is useful for caching external messages
Proposed Solution: Make Content-ID mandatory for external body
Status: Accepted as minor backward compatible change
6) Message/Partial send over an 8 bit or binary path cannot be
converted in a MIME aware gateway from 8 bits to 7 bits due to the
prohibition on encoding of the message content type and the unknown
nature of the content
Proposed Solution: Prohibit the sending of message/partial with any CTE
other than 7 bit.
Alternate Solution: Mark Message/Partial with an optional content-type
parameter to know how to re-code the material
in a gateway.
Alternate Solution2: Make an exception to the nested encoding rules for
message/partial.
Status: Please Debate!
7) Message Integrity Check needed in MIME
Proposed Solution: Add a new optional content header for a MIC based on
MD5.
Alternate Solution: Defer for a separate effort because this is a
major new feature for MIME.
Status: Please Debate.
8) Suggested filename requested for all content-types
Proposed Solution: Add the filename parameter to all content-types
Status: Accepted with language warning of security implications
9) "Printable" encoding wanted for Binary data over 8 bit path
Proposed Solution: Defer to a separate effort. Can be added as an
additional standard CTE if needed at a later date.
Status: Rejected as major change to MIME. Still possible as separate
standard.
10) Mail servers which use the subject line need to be supported
Proposed Solution: Add a parameter "subject" to the message/external-body.
Status: Accepted as minor change to MIME. No Objection but future
utility was questioned.
11) CRLF before the first boundary marker is unsightly to non-mime readers.
Proposed Solution: Make the CRLF before the first boundary marker optional.
Status: Accepted as Minor change to mime. (Is this backward compatible?)
12) Mime Version is defined as text causing odd interactions with RFC 1342.
Proposed Solution: Define mime-version as
MIME-Version := 1*DIGIT "." 1*DIGIT
Status: Accepted as a bug fix
13) Content-Conversion not widely supported
Proposed Solution: Delete content-conversion parameter
Status: Please debate
14) Compression is desired in MIME
Proposed Solution: none. Compression is likely to be a major new
function which could not be added without resetting MIME to proposed
standard again. A new content-transfer-encoding of compress-7bits
would be doable by the established extension mechanisms.
Status: Reject - Major change to MIME, defer to a separate effort.
15) MIME-version, content-type, and content-transfer-encoding headers are
stripped by some gateways
Proposed Solution: Move these headers to the body of the message.
Status: Reject. This is a MAJOR incompatible change to MIME.
16) FTP Access Type is not specified and may be mis-interpreted
Proposed Solution: Define as mode=ASCII
Status: Accepted as a bug fix