Agenda of the MIME Working Group meeting

[Greg Vaudreuil <[e-mail]>]

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.