home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
mailext
/
mailext-minutes-95apr.txt
< prev
Wrap
Text File
|
1995-05-26
|
6KB
|
142 lines
CURRENT_MEETING_REPORT_
Reported by Allan Cargille/MCI
Minutes of the Mail Extensions Working Group (MAILEXT)
The MAILEXT Working Group met once at the Danvers IETF on 4 April. The
minutes of the meeting were taken by Laird Popkin and edited by Allan
Cargille.
Administrative Items
The agenda was presented and revised:
o Introductions
o Revise agenda
o Mailing list
o Document review
The group mailing list was moved from cs.wisc.edu to list.cren.net. To
subscribe, send a message to listproc@list.cren.net. The subject line
is ignored. In the body, include a line of the format:
subscribe mailext Firstname Lastname
Document Review
Documents were reviewed in order of least controversial to most
controversial.
o draft-ietf-mailext-smtp-521-03.txt -- Alain Durand.
The primary author was unable to be present at the IETF. John Myers
asked to be removed from the document as an author. There was
discussion on whether to recommend this convention or merely make
it Experimental. The document actually describes two mechanisms
that could be used, but does not recommend one over the other.
There was consensus in the group that establishing MX records for
non-SMTP hosts is maintenance-intensive and should be discouraged.
None of the working group members present felt strongly that the
document should proceed on the standards track. It was recommended
that the document should be progressed as an Experimental RFC, with
a note that implementation experience is encouraged and people are
requested to report experience to the MAILEXT mailing list.
o draft-ietf-mailext-checkp-00.txt -- Dave Crocker, Ned Freed.
Discussion: this was viewed as important for a noisy world where
lines break, but the Internet has relatively reliable links. One
or two people said they would implement it. The working group
recommended that it be progressed to Experimental.
o draft-ietf-mailext-smtp-binary-06.txt -- Greg Vaudreuil.
There was a long discussion about this document. There are a
number of companies who are either implementing this or plan to do
so. However, there were not multiple independent interworking
implementations at the time of the IETF. The author, Greg
Vaudreuil, needed a stable document to come out of this IETF so
that companies would have confidence implementing the standard.
Greg preferred to see it progressed as standards track, but would
rather progress it as Experimental rather than see it delayed
another IETF. There was concern in the working group about
progressing it on the standards track in the absence of
interworking implementations. There was also concern that the
conversion between 7-bit and 8-bit is complex and may not be
specified clearly in the MIME standard. There was also discussion
about whether the SMTP extension verbs used in he document should
be standard verbs or XVERBs. In the absence of further input from
the IESG, the chair was hesitant to progress the document with
standard verbs. (Note: since the IETF, the MIME revision has been
clarified to allow Experimental RFCs to use standard verbs.) The
author requested that the document be progressed as Experimental,
but that the working group chair supply text emphasizing that the
working group views this work as important and would be pleased to
progress it on the standards track once interworking
implementations are available.
o draft-ietf-mailext-smtpas-01.txt -- Klensin, Freed, Moore, Houttuin.
The document is intended to be standards track but is not ready
yet. The document requires broad community acceptance. It was
recommended that a separate mailing list be created for reviewing
this document, to obtain greater community participation. This
document may be moved to the 821/822 rewrite effort discussed
below. Otherwise, hopefully one or two revisions will be produced
by Stockholm and it can be progressed there.
o draft-ietf-mailext-mime-check-00.txt -- Erik Huizer.
The MIME responder tool has had high usage levels, over 1000
requests per day. The author would like the document to be
released as an Informational RFC with working group review. He
will send out a new version to the list and the chair will send out
a last call to the list. There was discussion on whether this
document should be expanded to include other aspects of e-mail user
agents. There was consensus in the group that a more comprehensive
user agent feature checklist would be a helpful contribution, but
that this should be a separate document pursued in a different
group. (It was also clarified that people have different ideas
over what features are important in a user agent, so the document
should merely catalog the many features which might be included in
a UA.) This document will be added to the group's charter and
should be submitted before Stockholm.
o draft-ietf-mailext-mail-attributes-00.txt -- Jacob Palme.
This document is intended to become an Informational RFC with
working group review. The document should be added to the groups
charter and forwarded prior to the Stockholm IETF.
o draft-ietf-mailext-new-fields-01.txt -- Jacob Palme.
Initially, this document will be referred to the new group that
works on UA to UA issues and hopefully incorporated into
broader work. If that process proves slow, then the
non-controversial of these fields can be submitted in its own
document. Group consensus that it should be a standards track
document. It was asked if someone was going to draft a charter for
the new group?
o RFC 821/822 Rewrite Discussion -- Klensin/Myers.
There was consensus that an 821/822 rewrite is a ``Good Thing.''
Unclear whether this should incorporate changes to 821/822 or
merely document what is already valid and/or in general use. A
number of volunteers (John Myers, Dave Crocker, Keith Moore, and a
few others) volunteered to work on the new charter.
AOB
The working group should conclude its work by the Stockholm IETF. (Note:
the Area Directors would like to see the group conclude its work prior
to the IETF.)