NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Chris Newman <chris.newman@innosoft.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
General Discussion:drums@cs.utk.edu
To Subscribe: drums-request@cs.utk.edu
Archive: ftp://cs.utk.edu/pub/drums/mail-archive/
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:
· Simple Mail Transfer Protocol
· Augmented BNF for Syntax Specifications: ABNF
· Mail Header Registration Procedure
· Message Format Standard
Minutes of the Detailed Revision/Update of Messaging Standards (DRUMS) Working Group
Reported by: Chris Bonatti, IECA, bonattic@ieca.com (Session 1)
John W. Noerenberg, jwn2@qualcomm.com (Session 2)
Agenda
Tuesday Introduction/Administrative - 5 min (Chris Newman) 822bis document - 50 min (Pete Resnick) SMTP document - 35 min (John Klensin) ABNF document - 20 min (Dave Crocker) FridayReview agenda/updates since Tuesday - 5 min (Chris Newman) SMTP document - 60 min (John Klensin) 822bis document - 70 min (Pete Resnick) ABNF document - 20 min (Dave Crocker)
References draft-ietf-drums-abnf-02.txtdraft-ietf-drums-smtpupd-04.txtdraft-ietf-drums-msg-fmt-01.txt (update posted to mailing list)Session 1 (Tuesday, April 8, 1997)I. 822bis Document Brief
DRUMS Message Format Open Issues 1
Address parsing (should "[" and "]" be removed from specials. > Propose, no. We can't permit local parts and phrases that are illegal in 822. Must accept what's in 822 within reason. May need to think about lexer advice (e.g., treat "[" and "]" as part of the domain). No violent objections. Some feeling that reply-to function should be SHALL rather than SHOULD. "Should" versus "Must" -- distinction in behavior is that "must" says there are no legitimate situations for varying the behavior; should means it must be done except in special cases. Consensus was that this is a request for the user to reply to that address. Also noted that this is not easily testable/measurable. Fix typo in document to indicate that any message line should be 78-chars or less (plus CR/LF). May refuse to accept: "foo".bar@baz, linear-white-space between local part and domain elements? Propose, no. Propose the following litmus test: How widely is it used? What is the burden on implementation? How many people have messed it up in the past? Does changing rule simplify ...(see slides). No objections to these rules.
DRUMS Message Format Open Issues 2
MAY refuse to accept: foo@bar.[128].baz? Yes, by litmus test. Can't interpret reasonably anyway.
[Address Generation] Recommend phrase form of mailbox SHOULD use phrase form because comment form has ambiguous meaning in practice.
Source Routes in mailbox? MUST NOT generate, MUST accept MUST NOT generate linear white space in domain & dom-literal. Yes.
Phrase SHOULD be encoded as single quoted-string or "." Separated atoms? No, due to i18n & human aliases.
Local-part SHOULD be encoded as quoted string or dot-atom. Yes, as in current spec.
ALL FIVE OF THE ABOVE ACCEPTED
DRUMS Message Format Open Issues 3
Phrase should not contain specials other than "." No. Okay as implementor advice but not spec material. No free specials either.
Local part should not contain specials or LWSP-chars. No. Okay as implementor advice but not spec material.
Comments should not be generated. SHOULD NOT generate within address, otherwise okay. Linear-white-space should not be used except limited cases SHOULD NOT generate within address, otherwise okay.
Domain literal should be IP v4 or IP v6 syntax. Leave as 821bis issue. Leave 822 as before (possibly simplified a bit). How do we know if it's IP v6 or v4, etc.? Might want to transfer over other protocols (e.g., HTTP). Quoted part should NOT be used in domain literals.
Don't quote local-part when can be represented unquoted. No.
MUST NOT generate unquoted "." in phrase? Yes. Too much chance for people to screw it up.
DRUMS Message Format Open Issues 4
Date Header Issues, as in current spec, except:
SHOULD NOT generate comments except at end.
Human time zone name comment in examples, otherwise not mentioned specifically.
Seconds only to 60 for leap-seconds.
Include recommendations for Year 2000 interpretation.
Proposal: linear-white-space, comments, etc. should be allowed only AFTER date/time fields. General agreement (more detailed refinement later).
Received headers: Treat 822bis syntax as a superset of the 821bis syntax.
Be more explicit than the word "superset" specifying with "prefix," "suffix," etc. Suggest that all the syntax rules in 821bis be removed. Participant reminded group that since the 821 engine generates these, that they are semantically appropriate there. Also noted that 821 is one engine that might generate such syntax. Providing a clear distinction between user-to-user fields and transport fields would be useful. Asserted that "received-" fields are appropriate to 821 because they are do not need to parsed; counterexamples were also given. Chairman terminated discussion.
Do we want to move the "received-" fields back into 822? No clear consensus to straw poll. What are downsides of moving syntax back into 822? Syntax is painful :-). Semantics are provided by the transport system. We MUST NOT end up in a situation where they are defined in both places. Trying to separate them requires looking up the stack from 821, or down from 822. Neither may be desirable.
The "received" fields have proven to be quite useful. MUAs may begin to use these to support advanced functions. MUA developers don't necessarily need to understand 821, but SMTP developers CAN'T get away without understanding 822.
Propose modifying to incorporate all common fields into 822, and deal with transport-dependent fields as extensions in 821. Four-digit years are a SHOULD in 822bis, but have become MUST in 821bis. Numeric time zones are also in both. Is there any reason to put comments any place BESIDES the end of date fields (i.e., date names)? No.
Deprecate use of comments and linear white space between:
· ":" and date · "+" and time zone · Left side of the "," · or between the digits :-)
Proposal to move all these into the ABNF document (would entail white space folding issue, etc.). Counterpoint expressed that this is beyond the scope of ABNF since that document should not be field-specific. Consensus was that such a move was not a good idea. Perhaps another document for generic "use of" ABNF is required. Chris Newman's document on time formats might serve this function. Year 2000 input sought for input to the Year 2000 BOF; contact via e-mail.
Deprecate use of linear-white-space between field-name and ":"? MUST ACCEPT, MUST NOT generate.DRUMS Message Format Open Issues 4
Inclusion of hostname/IP address in received headers 821 issue -- loosened grammar should permit it.
What to do with Resent-*? User-initiated re-introduction. Use only as trace information. Prepend only. NOT TO BE INTERPRETED. Resent fields are also NOT to be counted.
User confusion between resent and forward. Suggest deprecation of "resent" headers, and specify a more formal means of "forwarding" which may differ from the current mechanism.
Other views were expressed that the trace was critical to avoid misuse of comments. Something needs to be done about the user confusion.
Clarify issue of no aliases in domain.
Domain Literal Syntax. As proposed in current draft Use ":" or "." In IP v6 literal? Already discussed.
MX targets and Section 5. See Section 5 in current draft. Local-part interpreted after removing quoting. As in 4.1.2, quoted and unquoted forms are considered the same. May MTA add stuff if header is missing it? Originating SMTP client MUST NOT send illegal stuff. Handling of improperly formatted messages in destination MTA is outside scope. Relays don't mess with message headers (don't peek). MAY refuse message if envelope sender illegal.
What can MTA do with unnegotiated/unlabeled 8-bit? Pass on what can pass on. Don't peek. MAY refuse illegal messages. Many current implementations DO peek, and encapsulate unlabeled 8-bit into MIME. Implementations sending 8-bit SHOULD NOT be allowed to assume that the message will be fixed later in the transport path. Note that an MTA that is a "Gateway" (neither purely an originating MTA nor relay MTA) MAY do some of these things.
Proposal to have 821bis enumerate the 3 types of MTAs, address ONLY the relay type, and prohibit all behavior that is not desired in the pure relay case. This is not a good idea because the current trend is to "prohibit" (too strong a word in my view, try "avoid") relays in favor of direct transfer from submitting MTA to recipient MTA. Discuss problem with duplicate elimination? Proposed, out of scope.
New %d10, %xF5, %b10001101 literal syntax. Good. Octal representation is omitted. Is this a requirement? Consensus is no. Strings are case-insensitive.
%d10.5.7.8 for concatenation, %d10..12 for alternates range. Good. Provides a shorthand repetition and range syntax. Chairman dissents because the "." and ".." syntax is similar, but mean very different things. For example, combinations of the two syntaxes can be confusing (%d10.5..12.14). Editor stated that ABNF should not allow the above example. This syntax has already been used in (at least one) I-D. Suggestion that these may violate the "rule of excessive subtlety," and may result in making the resulting syntax obtuse. Several more skeptical views expressed. Suggested that range syntax is more useful than the concatenation syntax. Editor stated that there are actually two range syntaxes. Confusion between the concatenation operator and the Boolean OR operator may result. The concatenation syntax aids in the dealing with alternate cases in value specifications, but the original intention was to deal with 8-bit values. Several examples of ambiguous syntax were discussed including:
· %xab..c · (%x41/%x61)..(%x5a/%x7a) · ((%x41..%x61)/(%x5a..%x7a)) · %d10.5..12.14
Further discussion is required before a clear consensus can be reached.{ } don't work in 822bis document because it's hard to distinguish item which may occur multiple times in set, versus Items which occur multiple times in sequence. For example: { *foo bar *baz}. No recommendations.
Session 2 (Friday, April 11, 1997)
The agenda given Working Group Chair Chris Newman assigned the majority of the meeting to the ABNF document. The Working Group concurred there are few outstanding issues for either 821bis or 822bis that merit discussion.
I. ABNF document (Dave Crocker, editor)
Three principal concerns for ABNF, the language, were raised and discussed at the meeting:
1. Range syntax 2. Set syntax 3. # operator
Whether set syntax is necessary was also under consideration by the Working Group. The Chair indulged a lengthy meta-discussion on the applicability of ABNF for other protocol specifications.
Range Syntax:
The editor proposed the alternative notations (for example):
%d01..05%d01-05For the numeric range 1-5 decimal, eliminating a "%<base>" string to introduce the end-of-range. The Working Group agreed this simplification did not hurt the range syntax. Debate over ".." or "-" as the separator range origin and terminus began with the sense of the group preferring "..", but ended with the conclusion that "-" would be preferable to avoid confusion with the "." operator.
There was considerable discussion about lexical ranges, and their semantics. The principal desire to include lexical ranges seems to be to formalize the 'abcdef' convention for representing the hex characters for %d10-15. However, during the meeting, the Working Group could find no general interpretation of lexical ranges especially when the string starting the range was of different length than the string ending the range. Moreover, uncertainty over the specification of the character set for a lexical range makes lexical ranges likely to have little practical utility. Accordingly, the sense of the Working Group was to drop lexical ranges from ABNF.
Consequently, the Working Group meeting consensus is that ABNF will represent ranges as:
range = %"base"1*"base-numerals"-1*"base-numerals" base = "b" / "d" / "x"; binary, decimal, hexadecimal base-numerals = have the obvious definition (the note taker cheats)Having disposed of ranges, the Working Group turned its attention to sets. Or rather, it attempted to turn its attention there. Instead, the discussion quickly sequed into a meta-discussion about meta-languages, in which several meta-points were raised and argued. Some of them related to whether or not set notation should be included in ABNF. It also ranged over the applicability of ABNF to other protocols. The Chair permitted the discussion with the proviso this discussion be put to rest at this meeting. These points included, but were not limited to:
There already are numerous meta-languages. Do we really need ABNF?
Consensus is that, yes, ABNF is useful. The original motivation to make the meta-language defined in RFC822 independent of a message object definition, and more generally available for use with other protocols still holds.
What does it mean for ABNF to be a standards track document? It doesn't specify bits on a wire. What is interoperating here?
No resolution on this point was apparent to the note taker.
Should ABNF define a machine-parsable language, or is it intended primarily for human consumption?
Sentiment for both yes and no was heard. No clear consensus was apparent.
Protocols must be completely expressed in some unambiguous grammar. Reliance on prose descriptions of protocol actions leads to confusion.
There was a general hum of assent to this, but not without reservations. However, this assertion leads to:
Set notation is necessary to simplify the expression of 822bis.
This continued the protracted discussion. After dizzying ourselves over these and similar meta-arguments, without significant resolution on any of them, the document editor proposed considering the specific syntax proposals for sets to see if, at least, that was worthwhile. In deciding that, we might discover some insight for some of these other issues. This was agreeable to the Working Group.
Pete Resnick, Dave Crocker, John G. Myers, Chris Newman gave examples of set rules from ABNF, and their productions. In each case, the rules yielded ambiguous productions, or least whose interpretation was unclear, when set members included rules that could repeat. After several of these attempts, it became clear that the set notation of ABNF didn't offer significant improvements over what the 822bis editor could achieve with an appropriate prose description of a (possibly) complex rule.
Consequently, the sense of Working Group was set notation should be dropped from ABNF.
It was observed by several members of the Working Group that their attempts to use # in their protocol specifications saw them desire to redefine its meaning because comma-separated elements in their lists didn't match their particular needs. Nor was their consensus on a form that was sufficiently variable to produce the kinds of lists that various authors wanted. The rough consensus of the Working Group meeting was to drop # from ABNF. That concluded the ABNF discussion.
II. 821bis -- SMTP (John Klensin, editor)
Items discussed were:
· Relation of draft to 1123 language · 550 response to Mail From: · Mailing lists and From envelope · Year 2000 problems
A request was made to include 1123 language explicitly rather than by reference. Suggestions will be sent to the editor. The editor graciously accepted the offer.
550 responses should be explicit that it is *not* permissible to try again later. The address is not acceptable. Some broken mailers interpret 550 to mean it's ok to try later. Further, responses to subsequent commands (except RSET & QUIT? -- note taker) should produce an out-of-sequence response. Editor agreed to verify and clarify the language as needed.
It must be clear that mailing list mailers should change the envelope from address when the message is redistributed so that undeliverable responses are returned to the mailing list mailer, and not the original author. The current draft loses this distinction. 1123 is clear on this point.
Year 2000 problems were fixed in 1123, although 821 missed it. This concluded discussion of 821bis.
III. 822bis (Pete Resnick, editor)
Open issues for 822bis (now that sets have been disposed of) listed by the editor:
1. Line length 2. NUL handlingWorking Group attendees also raised:
3. Deviations from 1123 language 4. Date: field syntax
The Working Group meeting agreed to the following:
· MIME specifies an explicit line length limit of 998 + CRLF. 822bis will adopt this limit. · NULs are not a legal character, ever. · As with 821bis, it was suggested the 822bis adopt 1123 language explicitly, instead of by reference. The editor will accept suggestions (graciously). [Note taker needs help] Current draft has no provision for WSP on either side of ":" in orig-date rule. I don't recall if the Working Group wanted WSP allowed, or wanted to be sure it was prohibited -- probably allowed, but not sure.] The current draft permits comments between the day name and the ",", for example, "Tue (Shrove Tuesday), 18 Mar 1997". However, there is no white space allowed between the "," and the month day. The editor agreed that white space should be allowed. This concluded discussion on 822bis, the business of the Working Group meeting. The Working Group adjourned, and everyone split for the airport.