CURRENT_MEETING_REPORT_
Reported by Greg Vaudreuil/CNRI
Minutes of the Internet Message Extensions Working Group (822ext)
Agenda
o Discuss and resolve outstanding issues in Quad-x
o Discuss and complete the header character set proposal.
Minutes
1. Resolve outstanding issues in Quad-X
A list of outstanding issues was reviewed and amended. Note, the
term Quad-x was coined for RFCXXXX at this meeting, and is used
throughout these minutes.
(a) Audio format
The Working Group was presented with two proposals for the
format of audio/basic. Both proposals were based on the NeXT
audio formats, one had attributes in the content-type headers
and the other had the attributes in the file header in the
body. After discussion, the Working Group concluded that it
had no basis for choosing a standard #extensible# audio format
and left the work for a future group. The NeXT format was seen
by many to be too machine dependent, and had too many options,
even as profiled by Marshall Rose.
A simple format was agreed to for audio/basic which has no
options and is not extensible. This definition for audio basic
was defined as u- law, 1-channel, 8 khz. The data in the
bodypart is straight u-law.
(b) Message integrity check
The Working Group expressed a strong need to define a message
integrity check for message bodies. This was felt to be more
general than would be available be adding a checksum to the
base 64 encoding. No clear specification was available at this
meeting. In the interests of making forward progress, the
Working Group agreed that not having a MIC was not a show
stopper, and if a solid proposal is ready, and can be approved
by the list by December 16th, it would be included in the
document.
ACTION: Ned Freed and Jim Galvin -- Write a MIC proposal to
1
include the preferred MIC as suggested by the SAAG.
(c) Multipart/Alternative
Multipart alternative was enthusiastically endorsed as a
transition mechanism to encourage the sending richer formats
than may otherwise be used. By allowing a sender to send both
a richly formatted document and include in a systematic way a
simpler version, one which may be ``cat'ed'' to the screen,
concern for the lowest common denominator will not have to be a
restriction on the use of new features.
(d) Character set issues
The Working Group specified the definition of a character set
for the purposes of quad-x to be a unique mapping of a byte
stream to glyphs, a mapping which does not require external
profiling information.
i. ISO 2022-jp
ISO 2022 is not strictly speaking a character set. It is a
switching mechanism which requires an external profile to be
useful, The Japanese have defined such a profile, and that
profile will be documented and considered a character set
for the purposes of Quad-x.
ii. Mnemonic
Keld Simonsen's mnemonic proposal as currently written
requires the external specification of a character set and
an escape character. As such, it does not fit the general
requirements of a character set. A lunch sub-group defined
a profile for mnemonic, with a lead in character of ``&''
(ascii 38) and ascii as the default character set. With the
profile, the Working Group accepted mnemonic as a acceptable
character set for Quad-x.
(e) Application specifications
The Working Group agreed upon several criterion for the
specification of new application subtypes to be defined in the
quad-x proposal. A new application must include in
attribute-value pairs the profile, macro packages used, and any
external pre-processors needed to use the included data. The
security implications of using the particular applications data
without authentication must also be discussed.
i. PostScript
Adobe has defined Postscript in such a way that it does not
2
require profiling information. A security considerations
section was written by Ned Freed, essentially pointing out
the nature of the risk associated with file operations, and
recommending that they be disabled. Macintosh postscript
files, which require laserprep header, as well as other
postscript files generated by programs such as FrameMaker
which call external libraries, must be sent with all such
libraries prepended the mailed postscript to avoid the need
to externally specify profiling information.
ii. .nroff and TeX
No person in the Working Group felt comfortable writing a
complete profile for the use of either TeX or .nroff. The
specification of these popular applications was left as a
future effort.
(f) Alphabet for boundary markers
The current alphabet for boundary markers makes it difficult to
construct markers which are compatible with RFC934 and existing
digesting software. The addition of space as a valid character
would satisfy this need. Further discussion resulted in the
adoption of a more general alphabet, to include the invariant
set of characters defined for the use of Base-64 to be used in
boundary markers. Trailing spaces are not permitted. When
spaces are used in a marker, the entire marker will have to be
quoted in the header.
(g) Binary type definition
An unscheduled discussion on the need for the Binary type was
held. With the clarification of the Applications type, and the
difficulty of specifying exactly what initial content-types
Binary should have, the Working Group without objection decided
to drop it in favor of Application/Raw.
This was a natural progression from the realignment of
content-types in terms of system resources begun before the
Atlanta meeting. Application and Binary both require the
ability to handle arbitrary Binary data, and require external
programs to use the information.
(h) Application/External-Reference
External Reference was seen by the Working Group to be a very
useful feature, but as inadequately defined in Quad-x. The
current syntax provides no mechanism for multiple simultaneous
retrieval mechanisms, the specification of syntax for
mail-servers, or prioritizing the retrieval order. The use of
specific application/ftp and application/NFS when used with
multi-part/alternative seems to be a reasonable approach, and
3
was to be written up Borenstein.
As with the MIC, this absence of this feature was not seen to
be a show-stopper. A new proposal will be submitted to the
mailing list and if acceptable will be included in the
document.
ACTION: Nathaniel Borenstine -- Write up and submit to the
mailing list a new proposal for application/external reference.
(i) Use of defaults
The current quad-x document specifies defaults for only
selected content-types. In the case where defaults are not
specified, and when the specified default may cease to be
useful, possible ambiguity results. A strong view expressed
before this meeting by Dave Crocker was supported by most
attendees that defaults should be prohibited and that the
subtype should always be specified. For broken mail which is
send with incomplete content-types, behavior of the reader is
left up to the implementor and user. It was felt that because
the message was already ``broken'' any uniform assumption could
not be reliable.
(j) Portable End-Of-Line markers in base 64
The Working Group deleted end of line markers in Base 64,
leaving it to the specific content-type to define the semantics
of end of record. This decision has the advantage of restoring
symmetry and transport independence between Base 64 and
Quoted-Printable
(k) Compression
Compression was raised in the context of the Binary content
type. Participants have expressed a desire, and the pragmatic
realization that the use of ``compressed, uuencoded, tar''
files will continue to be sent and need to be indicated in the
message. The Working Group previously stated it's preferences
and rational for not supporting uuencode, but has never clearly
expressed it's position on compress. The issue was tabled
pending a proposal to be sent to the mailing list. Again, if
the proposal is acceptable it will be included, and it's
absence was not a show-stopper.
ACTION: Neil Katkin -- Draft a proposal for the use of the
compress algorithm in the Quad-X proposal.
i. Internal reference in richtext
4
A proposal was made at this meeting to expand the richtext
definition by including an internal-reference token. It was
envisioned that this token would allow the insertion of
objects in other parts of the message into the richtext
stream. While many people supported this idea, no concrete
proposal was submitted. If a proposal is approved by the
mailing list, it will be included in the document.
ACTION: Harri Salminen -- Draft a proposal for Internal
reference in the richtext content subtype.
Timetable for completion
With the conclusion of the meeting, five issues were left open.
A new version of Quad-x, along with the proposals for the open
issues are due on December 6th. A new Internet Draft is
expected at that time. The final comment period will end with
the posting of a final version of Quad-x in the first week of
January when the Working Group will submit the document to the
IESG for Proposed Standard Status.
2. Header character set proposal
The Working Group began a review of the proposal submitted by Keith
Moore to include character set identification and encoding
information in the headers of a document.
The discussion was unstructured resulted in a productive stream of
consiousness review. The Working Group approved of the general
approach and with the changes discussed, approved the proposal.
Below are the main issues discussed and their resolution.
ED NOTE: Please help me reconstruct this discussion and submit text
for these minutes!
(a) Multiple encoded words
The Working Group felt that it should be acceptable to use
multiple encoded words. Furthermore, the Working Group agreed
that the length of encoded words should not be limited by this
document, but rather by implementors of software in
consideration of the pragmatic guidelines in the Quad-x
document.
(b) Character set names
The Working Group committed to alligning the character set
names between the header document, Quad-x and Simonsen's
charset document. The use of the numeric identify was dropped,
both as a result of allowing longer lines by specifying
multiple encoded words, and out of consideration in making the
encoded word more user-readable with old software.
5
(c) Use of Spaces in encoded words
Keith?
Megan, If I do not send you text for this section, just delete
it.
Timetable for completion
This document will be alligned with Quad-x, and a new version will
be submitted to the Internet Drafts directory by December 6th. At
that time, the Working Group may decide to combine the two
documents, or progress them jointly as a single standard. In any
event, the Working Group committed to the submission of the header
document and Quad-x as a bound set.
Attendees
Harald Alvestrand herald.alvestrand@delab.sintef.no
Mary Artibee artibee@sgi.com
Nathaniel Borenstein nsb@thumper.bellcore.com
Ronald Broersma ron@nosc.mil
Cyrus Chow cchow@ames.arc.nasa.gov
James Conklin conklin@bitnic.educom.edu
Robert Cooney cooney@wnyose.nctsw.navy.mil
Mark Crispin mrc@cac.washington.edu
Erik Fair fair@apple.com
Ned Freed ned@innosoft.com
James Galvin galvin@tis.com
Jisoo Geiter geiter@gateway.mitre.org
Russ Hobby rdhobby@ucdavis.edu
William Jackson jackson@manta.nosc.mil
Borka Jerman-Blazic jerman-blazic@ijs.ac.mail.yu
William Jolitz william@okeeffe.cs.berkeley.edu
Neil Katin katin@eng.sun.com
Tom Kessler kessler@sun.com
Jim Knowles jknowles@trident.arc.nasa.gov
Vincent Lau vincent.lau@eng.sun.com
Eliot Lear lear@sgi.com
Gordon Lee gordon@ftp.com
Jack Liu liu@koala.enet.dec.com
Paul Milazzo milazzo@bbn.com
Keith Moore moore@cs.utk.edu
Mark Needleman mhn@stubbs.ucop.edu
Daniel Newman dan@innosoft.com
Michael Patton map@lcs.mit.edu
Harri Salminen hks@funet.fi
Keld Simonsen keld@dkuug.dk
Gregory Vaudreuil gvaudre@nri.reston.va.us
6