Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/822ext/822ext-minutes-93mar.txt

Text File | 1993-05-10 | 5.5 KB | 130 lines

CURRENT_MEETING_REPORT_


Reported by Greg Vaudreuil/CNRI

Minutes of the Internet Message Extensions Working Group (822EXT)

The Internet 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 agreed to disband after publication of the revised document.
Several new working groups will be formed 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:


   o Encoding of Content-Type Message
     RFC1421 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 would
     be 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.

   o 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 the possibility
     that when this occurs the current filename mechanism may not be
     adequate.  After lengthy discussion during which the Group
     considered the possibility of using an encoded word from RFC1342,
     it was agreed that no changes should be made at this time and that
     when needed a new content-type could be defined with an enhanced
     mechanism.

   o Definition of Charset
     The Working Group agreed to significantly trim the definition of a
     character set and to eliminate specific wording about specific
     unregistered character sets.  The discussion of specific character

                                   1





     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 be the subject
     of a new working group chartered to address the character set
     issues in a more general IETF context.

   o 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 unlikely 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; 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.


Attendees

Harald Alvestrand        [e-mail]
Gabe Beged-Dov           [e-mail]
Nathaniel Borenstein     [e-mail]
Kevin Carosso            [e-mail]
George Chang             [e-mail]
William Chung            [e-mail]
James Conklin            [e-mail]
Al Costanzo              [e-mail]
Urs Eppenberger          [e-mail]
Erik Fair                [e-mail]
Roger Fajman             [e-mail]
Ned Freed                [e-mail]
James Galvin             [e-mail]
Christine Garland        [e-mail]
Terry Gray               [e-mail]
Alton Hoover             [e-mail]
Jeroen Houttuin          [e-mail]
Marko Kaittola           [e-mail]
Neil Katin               [e-mail]
John Klensin             [e-mail]
Jim Knowles              [e-mail]
Mary La Roche            [e-mail]
Keith Moore              [e-mail]
Masataka Ohta            [e-mail]
Emmanuel Pasetes         [e-mail]

                                   2





Francois Robitaille      [e-mail]
Marshall Rose            [e-mail]
Carl Schoeneberger       [e-mail]
Gregory Sheehan          [e-mail]
Einar Stefferud          [e-mail]
Gregory Vaudreuil        [e-mail]



                                   3