2.1.6 Detailed Revision/Update of Message Standards (drums)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.


C. Newman <chris.newman@innosoft.com>

Applications Area Director(s):

Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

Applications Area Advisor:

Keith Moore <moore+iesg@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 that have been identified through experience with Internet mail protocols. New functionality is expressly inappropriate.

Goals and Milestones:



Issue a first Internet-Draft of the revised SMTP document.



Issue a first Internet-Draft of the ABNF document.



Issue a second Internet-Draft of the revised SMTP document.



Issue a second Internet-Draft of the ABNF document.



Issue a first Internet-Draft of the revised message format document.



Issue a third Internet-Draft of the revised SMTP document.



Issue a third Internet-Draft of the ABNF document.



Issue a second Internet-Draft of the revised message format document.



Issue a fourth Internet-Draft of the revised SMTP document.



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.


No Request For Comments

Current Meeting Report

Minutes of the DRUMS Working Group

I. Introduction

WG Chair Chris Newman outlined the agenda for the two DRUMS meetings this week. In addition to consideration of current issues for ABNF, 822bis and 821bis, we would spend ~10 minutes on a new proposal from Jacob Palme to consider a mail header registry. On Tuesday, we took up ABNF and outlined issues for 821bis. On Friday, we covered 822bis, 821bis and Jacob's proposal.


In introducing Dave Crocker, the ABNF editor, Chris noted that perhaps only one more draft of ABNF would be required before advancing. As Dave got up, he jokingly assured the working group there would indeed, be only one more revision. The working group fervently hopes he is right.

Dave summarized the consensus the list construct be removed. He noted there were some minor editorial changes, and there is a single range construct.

The only remaining issue to be settled is the list of "core set" definitions in Appendix A. He proposed removing <PCHAR-NRB>, <PCHAR-NDQ>, and <LWSP>. During the meeting, we agreed to replace the symbol "HT" with "HTAB", as more descriptive of the character's typical rendition. While we considered adding UTF8 to the core set. The lack of consensus regarding UTF8 outside of drums led us to removing it from the literal list. We agreed to add the rule OCTET (= %x00-FF) and agreed to remove %x00 from CHAR. [Did we remove CHAR altogether? My notes indicate this, but I don't clearly recall. - jwn2]. After some debate, we chose to define VCHAR (= %x21-7E) replacing PCHAR.

The last discussion regarding ABNF during the meeting considered the use of "<" and ">" in <prose-val>s. Some interpreted the rules to yield multiple, ambiguous definitions of the use of these characters. This would make machine parsing of ABNF impossible. [jwn2's note: I don't see this interpretation in -03. I'm not sure this paragraph has any relation to what really occurred...]

Before adjourning for the day, we briefly discussed 821bis issues. The editor and WG agreed to defer thorough discussion until Friday.

III. 822bis

The 822bis editor, Pete Resnick, led the discussion on 822bis open issues. There are a number of issues to consider that hadn't been resolved on the mailing list. The goal is to get all substantive issues into the next draft, and allow one final draft for small editorial changes.

addr-spec needs better name, addr-spec is probably the one used

Pete is searching for a better name for addr-spec than "addr-spec." Without some inspiration from someone in the working group, he'll choose addr-spec, and wish he had something better.

msgid syntax is message-id: <lhs @ rhs>

While there is no dispute that message-id conforms to lhs@rhs, handling the requirement that message-id be globally unique has proved difficult. The draft should include some guidance for implementors on how to insure uniqueness. The description should roughly follow this plan:

If the rhs is unique, then any lhs is ok. Otherwise, implementors must use some convenient method to insure the lhs is unique. They must take care that message-id doesn't reveal more information about the originating station than is revealed by other headers. The rhs should conform to dns name generation rules, although it is not required the rhs be a name valid in some domain. In addition, the editor was encouraged to identify potential pitfalls in name choices.

empty mailbox list item

The editor sought guidance on handling empty mailbox list items. In particular, should their use be discouraged? It was observed there are times when an empty list item is convenient, so it was agreed they would remain in the accept grammar, i.e., constructs which are obsolete, but should not be allowed in the generate grammar, the grammar used for new implementations.

3.6 to, cc generate max 1 list

It was observed that the requirement to generate a single instance of addressee fields (to, cc, bcc) invalidates the practice of old versions of sendmail. However, all understood that 822's statement that implications of this form as "undefined" are inadequate. The consensus is that mandating only one instance each of these fields in the generate grammar, but allowing multiple instances in the accept grammar is the best course.

cfws in group

The editor had noted there was no consensus whether cfws in groups should be allowed for both accept and generate grammars. Those in attendance had no objection to it appearing in both places.

phrase -> formalname in mailbox (group-name in group)

Pete wants to use a more descriptive term for "phrase," one that is more reflective of phrase's use. "Display name" was offered as suggestive of the purpose a MUA could make of the phrase. There was no objection to "display name," so it will be adopted.

in accept grammar 2/3 digit year "MUST" or "SHOULD"?

The discussion was brief, although somewhat testy. Mostly it was "let's get past this one". The group converged on "SHOULD". (3-digit years --bleah!)

CFWS after field name in obsolete syntax (accept grammar)

The -02 draft allows *CFWS between the field name and the ":" marking the end of the field name token. The WG attendees preferred *WS or *FWS, and disallowing comments.

X- Headers

During the meeting it was observed that no X-* header has any standard semantic value. Nevertheless, they are an important mechanism to explore new possible semantics. So their use and interpretation

should be discouraged. [jwn2's note: Still this sounds suspiciously like where we left multiple recipient list fields, and see where that led.]

Should a header registry be included in this document?

Jacob's proposal for a header registry was noted, and the WG agreed that, at most, 822bis should refer to this registry.

Received / Return-Path

One of the knottier remaining problems for 822bis is semantics for Received and Return-Path headers. Clearly the information contained in the headers is generated by the MTA. The audience for 822bis is conceived of being MUA authors, so discussion of these headers in 822bis seems misplaced. However, 822bis must define the syntax, including a mechanism for extending the header. Chris Newman and Robert Elz proposed this. Dave Crocker wants to be sure that 822bis defines the syntactic entities commonly found in the header. Strong consensus among the attendees was lacking. Finally the editors of 821bis and 822bis agreed to work out between them what is discussed where, and propose their resolution to the list.

3.6.6 "forwarding" and Resent-*

The discussion of forwarding in 3.6.6 was thought to lack sufficient clarity and objectivity. The editor was encouraged to rephrase the discussion and add examples.


The last substantive issue was semantics of the Reply-to header. Two different semantics were described: the "From:" field isn't changeable, you should use "Reply-to:" value instead; ignore the rest of the recipient list, reply here, instead. [My notes are unclear on the resolution of this discussion -- jwn2]. The recommendation of the group is that description of "Reply-To:" make clear its use in the context of a mailing list.

IV. Administrivia

Remaining issues were administrative ones, regarding 822bis. The editor promises examples in the next draft. He encouraged and requested careful examination of the examples. It was suggested he borrow heavily from the examples provided in 822. It is anticipated that all substantive issues will be incorporated into the next draft, with one more to handle minor textual revisions. With that we returned to 821bis.

V. 821bis (cont.)

6.3 MTA editing

The current draft prohibits smtp relays from editing the message content beyond the addition of trace fields, while allowing an originating smtp node to edit the message to complete required fields omitted by a mua. There has been some discussion that relays be allowed more latitude to edit messages, as that occurs in current practice. Those in attendance at the meeting, however, prefer this not be allowed. The consensus of the meeting was to leave the language as it stands.

Size Limits (line length limits)

This discussion (which began in the first meeting) considered whether there was any better way to express

the consequences of dealing with arbitrarily long lines of text in the mail data than was offered by the editor in the draft. The conclusion was, "no." So the text was left as it stands.

452 vs 552 response codes

Another issue provoking much discussion on the mailing list was the intended use of these response codes. The WG conclusion is that 552 is in response to a specific "rcpt to" command -- the receiver could not handle this particular command. It is not invalidating all recipients gathered up to that point. The editor will offer new language on the difference between 400 and 500 response codes to clarify this difference.

multiple MXs at the same level

RFC974 permitted this, but 821bis does not. After discussion at the meeting, the editor agreed to reexamine his wording.

IPv6 address format

Those in attendance at the meeting agreed to replace the space separating the identifier from the value with a colon. Currently 821bis refers to a Proposed Standard for the address format that must be recycled. So the editor, chair and possibly AD(s) will attempt to prevail on the IPv6 working groups to provide DRUMS with an updated description.

"LF.LF" disallowed

Eric Allman (through a proxy) registered his dislike for this condition. However, the WG consensus is that future versions of sendmail will have to live with this in order to be compliant.


It was noted that 821bis doesn't prohibit NULs in DATA. However, 822bis' generate grammar forbids them. Some thought this was inconsistent. However, it was pointed out that 821bis may be used to transmit objects other than 822bis messages for which NULs may be acceptable. So eliminating NULs from 821bis is a Bad Idea. And so the language will be unchanged.

3.5.2 VRFY

The description of VRFY in 821bis still doesn't resolve the ambiguities between RFCs 821 & 1123. It was also claimed that descriptions of ehlo provide conflicting descriptions of VRFY. [But I don't see them -- jwn2]. The language on the addr-spec response to VRFY by the server needs to be clarified.

4.4 Received "for" phrase

Concern was expressed for the security implications of multiple recipients listed in the For phrase of a Received header. It was pointed out that 822/822bis BCC'd addressees may appear in this field, compromising their identity. In different cultures, violating the secrecy of Bcc can have severe consequences. The phrase "SHOULD NOT generate a multiple recipient 'for' phrase when there are multiple RCPT TOs" was suggested. The editor agreed to take this under advisement and add this to the security considerations. That completed discussion of 821bis.

VI. Mail Header Registry

Jacob Palme gave a summary of a draft protocol to register message headers. The principle purpose of the registry is to avoid semantic ambiguities in headers. Jacob defined homonyms as a header with multiple interpretation, and synonyms as different headers with the same or similar interpretations. A goal of establishing the registry is to avoid both homonyms and synonyms in message headers. It will be possible for anyone to register a header. Registrations are subject to peer review before they are accepted. The draft describes the review method.

The chair solicited opinions from the WG attendees whether such a registry would prove beneficial. The rough consensus is it would be worthwhile. The chairman accepted the document as within the WG's scope. He will modify the charter accordingly and submit it to the Area Directors.

VII. Chairman's Summary

ABNF should be ready for a WG last call by the end of August. It is desirable for a 3rd revision of 822bis be presented to the WG by the end of August as well. He expects that comments elicited by the 3rd draft may require a 4th draft, but the 4th should result in a WG last call. A new revision of 821bis should be made ready in early September, and be the basis of a WG last call. Finally, a revision of the registry draft should be prepared by the end of August for consideration by the WG. It is expected that comments from the WG last calls will demonstrate the need for a meeting at the December IETF meeting. There being no further business, the chairman adjourned the meeting.


DRUMS Issues

Attendees List

go to list

Previous PageNext Page