Minutes of the RFC 822 Message Extensions Working Group
The IETF RFC 822 Message Extensions Working Group met twice in
Columbus to review and approve the MIME protocol for submission as a
draft standard. With a handful of changes, the MIME protocol was
approved. The Working Group further agreed to disband after
publication of the revised document in favor of several new working
groups to define extensions to the MIME protocol and additional
content-types.
The solutions listed in the latest MIME issues list as distributed
periodically to the IETF-822 mailing list were accepted with the
following additions and changes.
Encoding of Content-Type Message.
RFC 1421 prohibits the use of a content-transfer-encoding other than
7bit, 8bit, and Binary on the message type. This was designed to
ensure that both the structure of a MIME message is visible without
decoding and that nested encodings were not generated. Implementation
experience has uncovered several problems with the use of
message/partial and message/external-body when conversion is required
in a gateway. In particular, using a non-null of a partial 8 bit
message for 7 bit transport is prohibited. Even if it was allowed,
re-encoding the message into a 7 bit encoding is likely to cause
message size growth, defeating the intent of using message partial in
the first case.
The question for the group was whether to limit encoding of any
message type to 7 bit or only message/partial. The group agreed to
modify the prohibition to allow only content-transfer-encoding of 7bit
for the message/partial content-type.
Representation of Filenames in Message/External-body.
The inclusion of filenames in the content-type headers has the effect
of requiring that all filenames be 7 bit ASCII. The Working Group
discussed the likelihood that new operating systems will require a
richer character set for filenames and possiblity that when this
occurs the current filename mechanism may not be adequate. After
length discussion, including the possibility of using an encoded word
from RFC1342, the WG agreed that no changes should be made at this
time and that a new content-type could be defined with an enhanced
mechanism when needed.
Definition of Charset.
The Working Group agreed to trim the definition of a character set
significantly and eliminate specific wording about specific
unregistered character sets. In particular, the discussion of
specific character sets not currently listed with IANA was eliminated.
See the revised document for the new wording. Agreement was reached
to remove Appendix F.2, the procedure for IANA registration in favor
of a statement pointing to the IANA for the procedure. It is expected
that this procedure will evolve independently of MIME.
Issues related to the application of the general principle of a
"charset" to specific current and future character sets is not part of
the charter of this working group and will bet he subject of a new
Working Group chartered to address the character set issues in the
more general IETF context.
MIME-Version: 1.0 Header Semantics
The Working Group discovered that the MIME-Version header was
insufficiently defined to be used for true versioning and that the
interpretation of this header was not uniform across current
implementations. Understanding that backward compatible changes to
MIME were unliely and that changing the version in the current header
will cause at least one implementation to fail to recognize the
message as valid MIME, the Working Group agreed that this header
should now be considered a string constant and any version specific
notes should be encoded as an RFC822 comment in the MIME-version
header line, a feature available in all other rfc822 headers.