The RFC 822 Extensions Working Group is schedule to meet twice
at the upcoming IETF meeting.
7:30-10:00 pm Evening Sessions *
APP Internet Message Extension WG (822ext)
9:30-12:00 noon Morning Sessions
APP Internet Message Extension WG (822ext)
At this point I would like to consider the following items.
Suggestions for additions will be considered if mailed to me. Because
of limited time I cannot assure all will be considered.
AGENDA
------
Monday
o Review the changes to RFC 1341 and RFC 1342.
It is my hope that we can reach closure on the final form of the
documents by the end of this session and submit the documents to
the IESG for consideration as Draft Standards.
A list of issues and my understanding of current Working Group
consensus is included below.
o Review the Internet Draft "Japanese Character Encoding for Internet
Message" as an Informational Document.
This document was the result of initial work done initially for
RFC 1341 and defines a subset of ISO 2022 which meets the
requirements for registration as a MIME character set.
* This is a regular 2.5 hour Working Group session. It was scheduled
in the evening to avoid conflicts with the many related working group
meetings. This meeting will begin promptly at 7:30.
Wednesday
o Review of content-language, content-disposition, and content-MIC
header fields for incorporation in a companion document to MIME.
These fields specify new optional functionality to MIME and if
included in the base specification would likely cause MIME to be
rejected as a Draft Standard.
Note: Not included on the agenda is a discussion of ISO 10646 and the
profiling of this work for MIME. If a written proposal for a MIME
character set of character sets is ready, and a Working Group review
is needed, it will be scheduled at the end of the remaining time.
READING LIST
------------
If you come to the Working Group sessions, you will be expected to
have read and understand the following documents.
RFC 1341 "MIME (Multipurposed Internet Mail Extensions)"
RFC 1342 "Representation of Non-ASCII Text in Internet Message Headers"
Internet Draft draft-ietf-822ext-mime2-00(.txt/. ps
Internet Draft draft-ietf-iso2022jp-02.txt,
The soon-to-be-posted Internet Draft revision of RFC 1342.
The MIME Issues List
MIME ISSUES LIST
----------------
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: New functionality that can be attained by use of multi-part.
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
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: Solution accepted as bug-fix
7) Message Integrity Check desired in MIME
Alternate Solution: Defer for a separate effort because this is a
major new feature for MIME.
Proposed Solution: Add a new optional content header for a MIC based on
MD5.
Status: A MIC is a new feature that is untested and should not be included.
8) Suggested filename requested for all content-types
Proposed Solution: Add the filename parameter to all content-types
Alternate Solution: Create an advisory filename as part of a new
content-disposition header.
Status: Alternate solution accepted. Separate document to be
written to deal with in-line vs attachment as well.
9) The filename parameter for application/octet-stream is "name"
Proposed Solution: Rename the "name" parameter to "filename"
Status: Change no longer needed due to alternate solution in #8
10) "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.
11) 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.
12) 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?)
13) 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
14) Content-Conversion not widely supported
Proposed Solution: Delete content-conversion parameter
Status: Accepted
15) 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.
16) 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.
17) FTP Access Type is not specified and may be mis-interpreted
Proposed Solution: Define as mode=ASCII
Status: Accepted as a bug fix
18) Trademarks for GIF and Postscript need to be explored
Status: Chair consulting with ISOC and IESG council, preliminary
text to be prepared.
19) Character set definition is a bit fuzzy
Proposed Solution: Clean up the language..
Status: new language to be added to the document.
20) Encoding of none not specified for encoded-words
Proposed Solution: Add a new encoding of 7 bit
Status: Rejected, the new encoding adds little functionality beyond
the "Q" quoted-printable encoding.