NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
Chris Newman <chris.newman@innosoft.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
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 Interent-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
Request For Comments:
RFC |
Status |
Title |
RFC2234 |
PS |
Augmented BNF for Syntax Specifications: ABNF |
43 IETF DRUMS working group meeting minutes
Met on Wednesday Dec 9 at 1:00 p.m.
Recorded by: John-Paul Sicotte <John-Paul.Sicotte@execmail.com>
Agenda
- Discuss 822bis draft
- Discuss 821bis draft
- Discuss ABNF draft
- Discuss closure of working group
- Discusss what new things people would like to see done in the area of messaging once DRUMS work complete.
822bis
Issues with draft-ietf-drums-msg-fmt-06.txt
The postmaster requirement from RFC 822 is no longer in the 822bis spec. Do we still need it? Consensus is to leave it out and to change the 821bis postmaster reference to be strictly internal.
There was a concern about the text describing the proper use of message ids. Sec 3.6.4 the paragraphs starting
'The "Message-ID:" field provides a unique message identifier that refers to a particular version of a particular message. The uniqueness of the ...'
The complaint was that it confusing with regards to what exactly should require a new message id to be used. It was mentioned that the examples given in the text of when to change the message-ids were just examples and that the exact mechanisms which require the message id to change need to be evaluated on a usage by usage basis. There is no SYNTACTICAL way of determining that messages are different and a semantic change needs to be evaluated in context to determine if it requires a change in the message id.
Consensus is Pete Resnick will post clarifying text to the list.
It was suggested that the text regarding the use of Re: in section 3.6.5 was unclear and that Re: should be made a requirement rather than optional. This was countered with the statement that the draft already had too many SHOULDs/MUSTs which are not required for interoperability. Group consensus was to leave the text alone unless the list could reach consensus on replacement text before the end of December.
This draft is currently in working group last call and there was strong consensus that these last few changes will be incorporated in to draft 07 which will then go to IESG last call.
Pete Resnick agreed that January 8th is deadline for 07 publication.
821bis
There are still some loose ends in the document. These have been around for quite a while without comment so unless there is rapid list consensus the editors will decide. They will post decisions to list.
The following known loose ends are mentioned in the draft.
- trace fields: John Klensin has received no comments and unless they come in current text will stand.
- syntax differences with 822 but not with 821
- definitions for link and receipt fields.
A few new issues were brought up.
Section 3.3 - Section needs a bit of clarifying text added. This will be done.
Section 5, Paragraph 4 - "Multiple MX records contain a preference indication that SHOULD be used in sorting (see below)." Suggestion that SHOULD be changed to MUST. No objections from the room. This will be changed.
Section 5, Last paragraph - "If it determines that it should relay the message without rewriting the address, it MUST sort the MX records ..."
The exact concern revolves around the sentence containing the last MUST in the paragraph. There is a conflict between RFC 974 which allows a MAY and 821bis which requires MUST. John Klensin recounted an explanation from one of the RFC 974 authors that states it was a mistake in RFC 974 and so 821bis shouldn't be required to match 974. People have mentioned that mta's can be configured to behave as described in 974. It was countered that this is bad behaviour.
Summary of problem:
If you go through a list of MX records and none of them can successfully be used to route the message, can you then use an A record. This is different than finding no MX records and finding an A record.
There are some options if none of the mx records are viable: you can smart host, bounce the message or use the A record. Consensus is that using the A record is not a good idea, but concern was that people may be using this mechinism.
A records have been used in the past but this may not prevent current restrictions. It is not the intent of the text in 821 to prohibit smarthosting.
Rough consensus is this isn't important enough to force a change to the text. John Klensin wants some people to examine the text to insure that prevention of the smart host option is not present or implied.
The small changes brought up will be put into draft 09 before end of IETF and this will go to working group last call.
ABNF status
The current draft is in working group last call. Dave Crocker agreed to have all minor outstanding revisions into a new draft before next Friday. Consensus was that this new draft will go to IESG last call.
Getting working group documents to RFC.
There was strong consensus from the group that due to the long duration of DRUMS and the extensive review the documents have undergone that unnecessary delays should be minimized.
There was strong consensus that, as a point of process, comments, other than straight forward editorial changes, require at least 4 visible people with support before they will be considered. Visible means that they themselves bring up or show support for a point; they can't just be mentioned.
What to do after DRUMS?
This was an opportunity for people to discuss things in the messaging area that they would like to see done after the DRUMS working group is shutdown. Some of the following minutes are done in a stream of consciousness style because that is the way the discussion was going. This section of the meeting was used to throw out ideas and judge peoples' interest.
Summary of MAILCAP by Keith Moore
The problem: You have a mail address and want to get information about it.
- Can they accept color? Multipart/Alternative?
- Language, charset, UA Capability
- Security supported with keys or URL's to keys.
- other ways to contact this person like voice address (Suggestion was that this point may be out of scope.)
This is intended to allow the sender to discover what is legal before a message is sent. The same problem exists when you have a phone number or a URI and want information on them.
Proposed plan is to have separate group (ENUM) to do phone numbers. URIs and EMAIL addresses would fall under MAILCAP.
Some stuff has been done with the URI problem (NAPTR/SRV) Schema definition is not meant to be part of the scope. Although registration procedures could be done. There was a security concern mentioned about the potential to use this service to discover information about what email addresses are valid. There was also some discussion on the types of solutions for this problem.
A draft charter has been made. Chairs are chosen and a mailing list is operational. Send mail to <mailcap-REQUEST@cs.utk.edu> to join the list. The charter has not yet been circulated.
Revision of Delivery Status Notifications
Suggestion is that we should look at this with the possibility of re-forming the Notification Working Group. One perception was that we have fairly wide deployment of the server support but few clients. A counter statement was made that there are bugs in implementations that are not being exposed because of lack of use of the service. Can this problem be fixed with a working group or better by someone like the IMC with an interoperability event like MailConnect. Suggested informational document on client uses of DSN. Did we solve a problem which doesn't exist or did we solve it the wrong way?
Are positive acknowledgements of delivery useful? Are these only for diagnostic purposes? One of the powers of these is that they could be dealt with by software. FAX community does expect the use of these, including positive acknowledgements. We need to consider that there may be classes of mail, like there is in the paper world, that may make use of DSNs (e.g. registered mail).
Routing Slips
Routing slips are used to route a piece of mail sequentially through a list of address rather than to all of the address at once. This is useful for "workflow" type problems. For example if you have a purchase order which first has to go to your boss, then to his boss and then to the President before you get approval.
One problem mentioned was that you can't really send these out without knowledge that all members can handle this or the messages get dropped.
821 recipient list extension
One of RFC821's limits is that you can place at most 100 recipients on one line. Removing this limit could be done as an extension to EHLO. Suggestion was that this could be proposed through an individually submitted draft.
Several small issues
- Work on support for server to server authentication
- Loop Control
- Mailing lists
- Filtering
- The issue of security when applications are sent inside mail
Randy Gellens takes photo of the group. Round of applause for Chair and Editors. Meeting adjourned.
None received.