DRUMS Meeting Minutes Intro WG Chair Chris Newman outlined the agenda for the two DRUMS mtgs 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. ABNF In introducing Dave Crocker, the ABNF editor, Chris noted that perhaps only 1 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 , , and . 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 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. 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: 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, ie, 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" is inadequate. The consensus was that mandating only one instance each of these fields in the generate grammar, but allowing multiple instances in the accept grammar was 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. This was proposed by Chris Newman and Robert Elz. 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. Reply-to 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. 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 this all substantive issues will be incorporated into the next draft, with one more to handle minor textual revisions. With that we returned to 821bis. 821bis 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. NULs in DATA 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 seem 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. 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. 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 Dec IETF meeting. There being no further business, the chairman adjourned the meeting. john noerenberg jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com -------------------------------------------------------------------- "We need not to be left alone. We need to be really bothered once in a while." -- Ray Bradbury, Farhenheit 451, 1953 --------------------------------------------------------------------