home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
mailext
/
mailext-minutes-94dec.txt
< prev
next >
Wrap
Text File
|
1995-02-28
|
8KB
|
190 lines
CURRENT_MEETING_REPORT_
Reported by C. Allan Cargille/MCI
Minutes of the Mail Extensions Working Group (MAILEXT)
Agenda
o Introduction, participants, approval of minutes, revise charter,
revise agenda.
o Individual work items:
- 521 status codes proposal (John Myers).
- Language tag proposal (Harald Alvestrand).
- File transfer body part MIME mapping (Ned Freed).
- Pipelining SMTP extension (Ned Freed).
- Checkpointing SMTP extension (Dave Crocker and Ned Freed).
- Binary and chunking SMTP extensions (Greg Vaudreuil).
- A-BoMBS and C-BoMBS (Jerome Houttein).
- Text/html proposal from the HTML working group (Eric Huizer
presenting).
Jacob Palme asked if this group is an appropriate forum for discussion
of work being done in the X.400/OSI community on incorporation of
Internet addressing. John Klensin responded that this is not an
appropriate forum for such discussion, but that it can be discussed if
time permits.
521 Status Codes Proposal
John Myers presented an overview of the 521 status code proposal. In
brief, this proposal is something that network entities that do not
support e-mail would support. It causes mail to immediately bounce when
an attempt is made to send it to such an entity. Currently such mail
tends to sit in some queue somewhere until it times out and is returned.
Keith Moore raised the issue of how MX records pointing at such entities
should work. The current specification says that the message should
bounce. Keith argued that it would be preferable to try other MX
records instead.
John Myers then pointed out that he had recently realized that this
proposal is not necessary. It is almost as easy to implement a simple
SMTP parser that returns a 5xx code to any RCPT TO command. This
approach has the advantage it works with existing broken implementations
that effectively ignore the initial banner status.
Harald Alvestrand and others countered by saying that standarding the
meaning of 521 in this context is useful in its own right. In addition,
John's proposal is problematic in that it could be construed that the
postmaster address should always work.
Harald also suggested that this proposal needs to be tried to be
assessed. If it is deployed and is useful it could be moved to
standards track. If not, it should be dropped. This in turn argues
that the document should be issued as Experimental. Allan concluded by
suggesting that the document authors should attempt to reach consensus
on the list for the documents moving forward as Experimental.
Language Tag Proposal
The group considered the language header proposal. Harald summarized
this proposal as one that allows labelling the content of a message or
part of a message as being in a particular language.
Jacob asked if the language concept extends to computer languages.
Harald said it does not, but it could be extended to cover this.
Nathaniel Borenstein asked about how multi-lingual text is handled -- it
is done by specifying multiple language values.
Ned Freed noted that this work may be part of future efforts in
extending MIME to uses in non-messaging environments. This should not
preclude moving the document along the standards track now, however.
John Klensin pointed out that the syntactic use of dash differs from
previous usage in RFC 822. Harald responded that this is by design, in
that while the dash is a syntactic element he wants to capitalize on the
effect it has of making it look like a single token. Dave Crocker added
that this needed to be made explicit in the text.
Dave Crocker also raised the issue of why this does not make sense as a
content-type parameter. Ned countered by pointing out that global
content type parameters are not allowed in MIME, and that this
information spans multiple content types.
The group concluded that this document should be submitted for
consideration by the IESG as a Proposed Standard.
File Transfer Body Part MIME Mapping
Ned presented his file transfer body part, SMTP pipelining, and SMTP
checkpointing extension. Ned prefaced his remarks by stating that only
the pipelining extension is a candidate for advancement at this time.
The file transfer body part work is a result of work undertaken by the
EMA Message Attachment Working Group (MAWG). The specification seeks to
map X.400 file transfer body parts into appropriate MIME objects and
vice versa.
Discussion focused on the need for a general file transfer mechanism in
MIME and whether or not this mechanism should be extended to provide
this facility. Ned pointed out that since the EMA's use of file
transfer body part is to provide a MIME-like mechanism for object
encapsulation, not to use the mechanism for the (obvious) purpose to
transfer files per se, and as such the mapping specification seeks to
provide an object mapping rather than a file transfer mechanism.
Eric Fair noted that in the best of all worlds it would be possible to
specify generic formats for generic object types. Dave Crocker and
others noted that while this would be desirable it is not present-day
reality, and is not likely to become reality in the foreseeable future.
The discussion concluded with Ned stating that he wants to consider the
various issues brought up by the group and see how the document needs to
be changed (or not changed) to accommodate them.
Pipelining SMTP Extension
Ned reported that, as tasked by the working group, he had communicated
with Eric Allman about the issues of implementing the pipelining
extension in sendmail. Eric had responded that the problems with
implementing pipelining in sendmail (e.g., the use of a fork system
calls in the middle of the SMTP dialogue) would probably be addressed in
the long term by other planned modifications. As such, Ned recommended
moving the document forward for consideration as a Proposed Standard
without any sendmail-specific changes, and the working group agreed.
Checkpointing SMTP Extension
The checkpointing proposal was discussed. One of the coauthors (Ned)
had thought of this proposal as something of an academic exercise.
However, the other author (Dave Crocker) disagreed and so did a
considerable fraction of the group. It was accordingly decided that
implementation of this proposal is needed, and if it proves to be useful
the working group should consider moving this work forward on a
standards track.
Binary and Chunking SMTP Extensions
Greg Vaudreuil presented his chunking and binary SMTP extension
specification. Discussion centered on interoperability testing and
issues surrounding binary MIME. The latter were ruled out of scope for
the present discussion, but the former are of such concern that the
working group decided to ask for some indication of interoperability
before advancing the document to Proposed Standard.
A-BoMBS and C-BoMBS
The BoMBS documents were reviewed. A large number of substantive
comments were made about both documents. Dave Crocker stated that this
work is extremely important and long overdue, and that the best approach
would be to charter a separate working group to deal with these
documents in detail. This suggestion was favorably received by the
working group.
Text/html Proposal from the HTML Working Group
Eric Huizer presented a proposal for the handling of text/html, which
was worked out by the HTML Working Group (which met in parallel with
Mail Extensions Working Group). In brief, the HTML group has decided on
a canonical form that agrees with MIME text/plain (i.e CRLF line
terminator sequence). Clients are supposed to support a wider variety
of terminators, but text/html is supposed to be in this form. This
proposal was very favorably received by the Mail Extensions Working
Group.
Eric Huizer also presented a proposal for a MIME testing service. A
document will be posted to the list describing this service.
Conclusion
Allan Cargille concluded the meeting by thanking the various document
authors for the work they have done on these proposals.