Folks,
MIME as defined in RFCs 1341 and 1342 was published as a Proposed
Standard in June 1992. It has been a Proposed Standard for over 6
months and there is significant implementation experience. It is my
hope that we can quickly come to closure on a new version to be
submitted to the IESG shortly after the March 93 IETF meeting in
Columbus Ohio.
From RFC 1310
3.2.2. Draft Standard
A specification from which at least two independent and
interoperable implementations have been developed, and for
which adequate operational experience has been obtained, may be
elevated to the "Draft Standard" level. This is a major
advance in status, indicating a strong belief that the
specification is mature and will be useful.
A Draft Standard must be well-understood and known to be quite
stable, both in its semantics and as a basis for developing an
implementation. A Draft Standard may still require additional
or more widespread field experience, since it is possible for
implementations based on Draft Standard specifications to
demonstrate unforeseen behavior when subjected to large-scale
use in production environments.
This is understood to mean that for a document to reach Draft Standard,
all features have been implemented and understood to be stable. If any
major new functionality is to be added to MIME itself, it must be
re-cycled as a Proposed Standard. For functionality to be added to
MIME it must meet the requirements for Draft Standard also, meaning it
is has been implemented and tested by multiple people and it is know to
interoperate. Note: new content-types can be added in separate
documents and need not be part of the MIME standard itself.
There are two activities that need to be completed for Draft Standard.
First we need documentation of implementation experience and
documentation of at limited operational use. If you have released a
mime implementation, let me know! In particular, let me know if there
are any features not implemented. The header character set
enhancements are part of the MIME standard and should be implemented.
Second, we need to revise the MIME rfcs, 1341 asnd 1342 to fix any
known bugs and to trim any un-implemented or unstable features. Below
is a list of such bug-reports and other items that need to be
addressed. I have noted what I understand to be reasonable remedies.
Please review this list. Please post additions if there are any
problems over-looked and post alternatives if any of the remedies are
unacceptable.
Greg Vaudreuil
Chair, RFC822 Message Extensions WG.
Issues for MIME
from Implementation experience
1) Dot in tspecials adds unneeded complexity.
Proposed Solution: Remove the "." from the list of tspecials.
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.
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
4) End of data in Base 64 is not tagged
Proposed Solution: Add an optional "====" to the end of the base64
encoding
5) A content ID is useful for caching external messages
Proposed Solution: Make Content-ID manditory for external body
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.
7) Message Integrity Check needed in MIME
Proposed Solution: Add a new optional content header for a MIC based on
MD5.
8) Suggested filename requested for all content-types
Proposed Solution: Add the filename parameter to all content-types
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.
10) Mail servers which use the subject line need to be supported
Add a parameter "subject" to the message/external-body.
11) CRLF before the first boundary marker is unsightly to non-mime readers.
Make the CRLF before the first boundary marker optional.