NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98
Chair(s):
Chris Newman <chris.newman@innosoft.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
R Gellens <Harald.Alvestrand@maxware.no>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Mailing Lists:
General Discussion:drums@cs.utk.edu
To Subscribe: drums-request@cs.utk.edu
Archive: ftp://cs.utk.edu/pub/drums/mail-archive/
Description of Working Group:
The goal of this working group is to develop and review revised versions of RFC 821 and RFC 822, incorporating the revisions in RFC 974, RFC 1123, and RFC 1651.
In addition, the group will review other RFCs related to messaging, and determine the applicability of each of these to the future direction of the messaging in the Internet. The group may choose to incorporate, deprecate, or write applicability statements for such documents, as necessary to produce a clear statement of requirements for overall interoperability of Internet electronic mail.
The documents produced by the working group are intended to be submitted to the IESG for consideration as Internet Standards.
Items appropriate for inclusion in documents produced by the working group include corrections, clarifications, and amplifications to reflect existing practice or to address problems which have been identified through experience with Internet mail protocols. New functionality is expressly inappropriate.
Goals and Milestones:
Done |
|
Issue a first Internet-Draft of the revised SMTP document. |
Done |
|
Issue a first Internet-Draft of the ABNF document. |
Done |
|
Issue a second Internet-Draft of the revised SMTP document. |
Done |
|
Issue a second Internet-Draft of the ABNF document. |
Done |
|
Issue a first Internet-Draft of the revised message format document. |
Done |
|
Issue a third Internet-Draft of the revised SMTP document. |
Done |
|
Issue a third Internet-Draft of the ABNF document. |
Done |
|
Issue a second Internet-Draft of the revised message format document. |
Done |
|
Issue a fourth Internet-Draft of the revised SMTP document. |
Done |
|
Meet at Memphis IETF |
May 97 |
|
Issue a final Internet Draft of ABNF document. |
May 97 |
|
Issue a fifth Internet-Draft of the revised SMTP document. |
May 97 |
|
Issue a third Internet-Draft of the revised message format document. |
Jul 97 |
|
Issue a final Internet-Draft of the revised SMTP document. |
Jul 97 |
|
Issue a final Internet-Draft of the revised message format document. |
Aug 97 |
|
Meet at Munich IETF. |
Aug 97 |
|
Submit documents to IESG for publication as RFCs. |
Internet-Drafts:
· Simple Mail Transfer Protocol
· Mail and Netnews Header Registration Procedure
· Internet Message Format Standard
· Use of Reply-To in Internet E-Mail messages
· The ''Message-ID'' header
· Reply-To-Meaning Proposal
· The ''Mail-Followup-To'' header
· Reply-To Personal Proposal
Request For Comments:
RFC |
Status |
Title |
RFC2234 |
PS |
Augmented BNF for Syntax Specifications: ABNF |
Minutes of the Detailed Revision/Update of Message Standards (drums) Working Group
Version 0.53 1998-04-16 11.14 MET DST
Chair: Chris Newman <chris@innosoft.com>
Minutes: Lars-Johan Liman <liman@sunet.se>
Area Director: Keith Moore
I. Agenda
The agenda was presented by Chris, and accepted by the group.
Chris noted that DRUMS suffers from "Aging Working Group Syndrome" and he strongly encouraged the group to help bring the current documents to their final state and to not bring any new issues to the table, so that the working group can be close down.
II. 821bis Issues
John Klensin, document editor, had not yet arrived, so the agenda point was moved to after Message Header Registry Issues.
III. Registration of Message Headers
The group felt that it was absolutely necessary to include registration of HTTP and MIME headers in the document, else the entire effort would be meaningless. This insight led to the conclusion that the issue is out of scope for DRUMS, and that it would have to be attended to in some other working group, possibly its own.
Keith Moore, Area Director, noted that the important thing was that the same label _not_ be used with different meanings in different contexts. It is of less importance in which working group the issues are discussed. It might even be beneficial if the discussion is spread outside DRUMS.
John Myers strongly suggested to start a new working group so that DRUMS could be closed down.
The document editor, Jacob Palme, claimed that this _is_ in scope, but the consensus of the group was that it would be better to have the discussion in a separate working group.
Humming lead to "defer until 821bis and 822bis are sent to IETF last call"????
IV. 821bis
John Klensin, document editor, forwarded a strong hope that there would be no more open issues after the next revision of the document.
None were brought forward in the meeting.
V. 822bis
CR and LF issues
Pete Resnick, document editor, asked the group for input on the issues of bare CRs and LFs in the message body. Currently the drafts says CRLF is line divider and may not be immediately preceded by a bare CR or LF.
Robert Elz had suggested to the mailing list that the rules be opened up to allow for local storage conventions.
Pete strongly pointed out that RFC 822 means having CRLF as line separator.
Rob countered that how the message is stored locally doesn't matter.
John Myers noted that using just CR, just LF, or CRLF makes a big difference when calculating checksums, e.g., to assure message integrity.
Something is missing here. What is the significant improvement text about?
Pete asked Rob to send in "significant improvements" of the wording in the draft, if he wanted something to be changed.
Rob jokingly commented that "anything would be that". :-)
John M volunteered to work with Rob on such an improvement.
Control characters in the message body
The current text says that most control characters are "should not" in the generation grammar, except for HTAB. Rob had suggested to the mailing list that BS and FF should be included in this group of allowed characters.
Keith stated that "should not" was rather hard. He suggested to focus on the responsibilities for the _recipient_ UA on how to treat them, and not regulate strongly what the sender is supposed to do and not do.
This was supported by the group, and leads to that only one paragraph needs to be changed.
Pete is to change 3.5, and therein
· strike "should not"
· leave "may"
· add "discourage"
· add a note about the meaning of all this, containing text to the effect that such characters are "not required by the recipient UA to be displayed in any way".
Group
Eric Allman complained that under section 3.4, "group" is not defined semantically, the point being "What gets in the SMTP envelope from the UA?"
John M suggested to simplify the grammar by saying that a group consists of a display name. The suggestion was accepted by the group, but the text will have to include clarifications saying that only a single form of display name is to be used when only a single form is needed, to avoid misinterpretations like, horrors:
To: Pete.Resnick: Pete Resnick <Pete.Resnick@qualcomm.com>;
Domain literals
Eric then questioned the use in 4.1 of "dtext" in domain literals. Having it this "free" generates problems when parsing them. After some discussion the group consensus was to leave it as it is. Domain literals will always need special attention in parsing, and what goes in there is transport dependant and is not supposed to be defined by DRUMS.
CR immediately before linebreak
Rob noted that the current draft specifies that CR is not allowed directly before the line separator CRLF. This is change from RFC 822.
Pete countered that this was intentional since such use of CR causes "serious brokenness" in some implementations.
After some "Buddhist monk-like humming" the group came to the consensus to remove bare CRs and LFs from the accept grammar, and bring this suggestion to the mailing list to see if he consensus continues to stand there. An application receiving bare CRs and LFs may "do whatever it likes" about it. The group decided to discuss the problem on the mailing list.
"." in phrase
Pete is going to specifically mention that the use of "." in phrase is illegal and why.
Header folding
Pete is going to clarify that folding means nothing but to insert CRLF in such a way that it is immediately followed by white space.
It was noted that it is a different issue if it is a structured header field.
2-digit
Due to "intentional misinterpretation," Pete is to clarify that 2-digit (e.g., used in time stamps) cannot have white space between them.
VI. "X-" Headers
Dave Crocker violently suggested to take away the special meaning of "X-" in headers. He claimed that there was perfectly good reasoning behind the construct, but "it didn't work" due to misuse.
Keith worried about losing the convention of "experimental." It is used in many protocols.
Rob stated that looking at label to judge its standardization status is stupid.
Dave continued by suggesting to remove "X-" and use just "<vendor>-header:".
Pete concluded that the current document is silent on the issues of "X-", and wanted to push the discussions to the header registry forum.
There is the apparent problem with having "X-" headers that need to be standardized but cannot. If one does standardize them, and removes the "X-", two headers with the same meaning will be in circulation on the Internet, and John Myers concluded that that generates non-interoperability problems, so it is not a good engineering decision.
There was a weak consensus to leave the text as it is, but the group was far from unanimous.
VII. Replay-To
A week ago Pete sent an alternative suggestion to the list with the essential content that Reply-To: replaces From:, and it purposely says nothing about how to handle To: and Cc:, and leaves that up to the implementor. There are two interpretations for Reply-To "out there" and they cannot be implemented at the same time in the same product. Keith stated that the UA function "Reply to Author" should not go to the Reply-To: address.
Einar Stefferud noted that "Reply To" replaces "From" in the paper world, and that it would be a good idea to mimic that.
A discussion on whether To: and Cc: should be included in a UA function "Reply To All" erupted, much in line with the recent "discussions" on the mailing list.
Roger (Fajman?) wanted to make sure that it is clear in the text that a UA can provide any assistance to the user it sees fit.
Jacob Palme found it important that the outcome of the discussions should not be "leave it 'undefined'".
Pete countered by noting that that having it "undefined" has always been the case in RFC 822.
Keith, with support from Chris and John M, suggested to describe what the installed base looks like, and recommend implementors to be consistent with that if they want to be compatible, followed by a note describing that there was controversy in the room on whether this was the right thing to do.
Pete kept his standpoint that "If you were going to use From:, use Reply-To:. To: and Cc: are your problems." and that semantics regarding that should not be dealt with by this document.
Keith suggested to spin the issue off to a design team with sensible people from both sides. This seemed to be the consensus of the group.
VIII. Any Other Business
A question was posed on where to discuss stuff that has been ruled out of drums.
Keith strongly suggested to start new list, since this tends to keep separate issues apart, and makes it easier to filter mail and to handle mail archives.
None Received