Please review and send editorial changes to me personally. Technical
discussion on specific points is welcome. Please keep in mind that we
are working toward completion of this document. New features and
major changes in structure to either the message format of the Header
Character set documents are expressly discouraged at this time.
Greg Vaudreuil
Internet Message Format Extensions Chairman
Internet Message Format Meeting Report
Reported by Greg Vaudreuil/ CNRI
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 Marshal 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
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.
1) 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.
2) 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 ``___'' 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.
1) PostScript
Adobe has defined Postscript in such a way that it does not 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. Machintosh postscript files, which normally require a
laserprep header to be printable, must be sent with the laserprep
headers to avoid the need to externally label the files as Machintosh
files.
2) .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 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 as usable markers. Trailing spaces are not
permitted. When spaces are used in a marker, the entire marker must
be quoted.
i) 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.
j) 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 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.
k) 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.
l) 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
m) 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.
n) Internal reference in Text-Plus
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: Harald Alvestrand -- 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.
c) Use of Spaces in encoded words
Keith?
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(_dot_)alvestrand(_at_)delab(_dot_)sintef(_dot_)no>
Mary Artibee <artibee(_at_)sgi(_dot_)com>
Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
Ronald Broersma <ron(_at_)nosc(_dot_)mil>
Cyrus Chow <cchow(_at_)ames(_dot_)arc(_dot_)nasa(_dot_)gov>
James Conklin <conklin(_at_)bitnic(_dot_)educom(_dot_)edu>
Robert Cooney
<cooney(_at_)wnyose(_dot_)nardac-dc(_dot_)navy(_dot_)mil>
Mark Crispin <mrc(_at_)cac(_dot_)washington(_dot_)edu>
Erik Fair <fair(_at_)apple(_dot_)com>
Ned Freed <ned(_at_)innosoft(_dot_)com>
James Galvin <galvin(_at_)tis(_dot_)com>
Jisoo Geiter <geiter(_at_)gateway(_dot_)mitre(_dot_)org>
Russ Hobby <rdhobby(_at_)ucdavis(_dot_)edu>
William Jackson <jackson(_at_)manta(_dot_)nosc(_dot_)mil>
Borka Jerman-Blazic
<jerman-blazic(_at_)ijs(_dot_)ac(_dot_)mail(_dot_)yu>
William Jolitz
<william(_at_)okeeffe(_dot_)cs(_dot_)berkeley(_dot_)edu>
Neil Katin <katin(_at_)eng(_dot_)sun(_dot_)com>
Tom Kessler <kessler(_at_)sun(_dot_)com>
Jim Knowles
<jknowles(_at_)trident(_dot_)arc(_dot_)nasa(_dot_)gov>
Vincent Lau <vincent(_dot_)lau(_at_)eng(_dot_)sun(_dot_)com>
Eliot Lear <lear(_at_)sgi(_dot_)com>
Gordon Lee <gordon(_at_)ftp(_dot_)com>
Jack Liu <liu(_at_)koala(_dot_)enet(_dot_)dec(_dot_)com>
Paul Milazzo <milazzo(_at_)bbn(_dot_)com>
Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
Mark Needleman <mhn(_at_)stubbs(_dot_)ucop(_dot_)edu>
Daniel Newman <dan(_at_)innosoft(_dot_)com>
Michael Patton <map(_at_)lcs(_dot_)mit(_dot_)edu>
Harri Salminen <hks(_at_)funet(_dot_)fi>
Keld Simonsen <keld(_dot_)simonsen(_at_)dkuug(_dot_)dk>
Gregory Vaudreuil <gvaudre(_at_)nri(_dot_)reston(_dot_)va(_dot_)us>