Editor's note: These minutes have not been edited. Minutes recorded by Ned Freed December 9th, 1996 Minutes for the DRUMs meeting at the San Jose IETF 821bis document (John Klensin editor): John stated that conversion to ABNF is incomplete; it will be completed once the ABNF specification is done. In addition, examples won't be revised until everything else is complete. Discussion of outstanding 821bis issues: (a) It has been tentatively decided that the definition of the Received: field will be moved from 822bis to 821bis. The logic here is that MTAs are the things that need to deal with this field so it should be defined in the MTA document. There was no objection to this change. (b) The domain name in HELO/EHLO commands is problematic for some clients. The proposal is that clients should insert their domain name if they know it. The document editor will generate a proposal for what to do if the domain name is not known. (This is likely to be some combination of domain literals for IPv4 addresses and strings that are identifiable as not being domain names.) The language in RFC1123 regarding the need for servers to accept arbitrary HELO parameter values will be retained; the RFC1123 requirement that HELO parameters conform to domain syntax may or may not be retained. (c) Jim Conklin raised the issue of back references the 821bis document to RFC821. If the intent here is to produce an entirely new specification such references are inherently problematic. John responded that such references only appear to cite obsolete or deprecated features we really want to go away. Dave Crocker then suggested that such references be moved to an appendix. John will see what he can do to resolve this. (d) Eric Allman pointed out that the current text says that out of multiple MX records you need to pick one and it should say that they need to be randomized. John will fix this. (e) Loop detection. The group feels that: (1) Counting received lines is an easy and effective way to detect some loops. A limit of 100 seems like an acceptable default. (2) Other mechanisms may prove to be problematic. (3) This entire issue needs to be addressed in detail in another document. ABNF document (Dave Crocker editor): Discussion of outstanding issues: (a) The precedence of alternation and concatenation need to be changed. It was pointed out that the present precedence causes problems when /= is used. The section also needs to make it clear what "high precedence" means. A suggestion was made to use "binds more tightly" or "binds more loosely", as these have fairly obvious meaning. Examples are probably appropriate here. (b) The group feels that ABNF string literals should always be considered to be case sensitive. When case sensitivity in the grammar is needed it should be done as a concatentation of literals. (c) The precedence of ".." needs to be specified and isn't. Dave will fix this. (".." binds more tightly than any other operator.) (d) The group believes that digit values need to be specifiable in bases other than 10. Dave will take suggestions and work up a proposal to address this. (e) The group cannot reach consensus on whether to use ":=" or "=" as the rule definition operatior. As such, the chair proposed that in the absence of consensus to change an existing conventions we must retain the existing convention, which is "=". This appears to be acceptable to the group. (f) There was some discussion of using a single unified syntax for all sorts of literals, e.g. %t"string", %d"decimal-number", %h"hex-number". This seems to be finding favor in the group and will be taken to the list for further discussion. (g) It was suggested that we allow set subtraction. Pete Resnick pointed out that range constructs seem to cover most of the cases where subtraction might otherwise be needed without undue complexity (822bis is an example of this), the 822bis document might use this construct to advantage in defining things like other-fields so that it does not include existing fields. However, Pete also feels that this is messy and better handled by prose comments. (h) Dave had to leave at this point, terminating the discussion. 822bis document (Pete Resnick editor): Discussion of outstanding issues: (a) Pete brought up the issue of what sort of white space is allowed after the initial colon in a field -- whitespace, whitespace plus comments, etc. John proposed that whitespace plus comments be allowed after a colon in structured fields. This appears to be acceptable; details will be thrashed out on the list. (b) More explanation is needed in regards to handling of Bcc: lines in replies. (c) The issue of how reply-to/from should be used in generating replies. The current document says to use reply-to by default if it is present and if it is not use from instead. It was then pointed out that this is an on-wire protocol document, not an MUA behavior document, and as such needs to deal with the meaning of the fields, not their use. The suggestion was made to define reply-to as the field where "the originator suggests replies will be sent". The text that says that reply-to should not be used when it is the same as the from field needs to be removed, as this is actually used in some situations with different semantics than those of a bare from. (d) Pete has picked up from the list that resent- is effectively trace information. John pointed out that if this is done both resent-reply-to and resent-subject need to be deprecated, as they do not make sense as trace. The group seems happy with this. (e) Ned Freed objected to the requirement that resent-from and resent-date be present. John brought up the SMTP "251 user has moved". Keith and Pete pointed out that resent- is supposed to be reserved for manual resending operations only. Ned pointed out that manual versus automatic is hard to distinguish. The group seems to feel, however, that the present text is correct as written. (f) The issue of header order and how to insert new headers was raised. The consensus is that resent- headers should be prepended to a message (note the lower case "should"), and thus Received: headers may appear after resent- headers. An attempt will also be made to describe the difference between resending and forwarding. (g) The current grammar allows continuation lines containing only whitespace. This will be changed to require some characters (possibly only a comment), so as to allow interpreters to treat lines containing only whitespace to be resolved as either a header continuation line or as a break to the text. What is appropriate for interpreters to do has yet to be resolved. (h) Chris raised the issue of whether the sender is a deliverable mailbox or simply a trace field. (Chris had a slide that should be attached here.) Keith proposed that as RFC1123 requires all of these fields to be deliverable mailboxes this should be addressed by the more general rule. Keith proposed language saying that sender is distinguished from from either by (1) Message sent on behalf of someone else or (2) Message sent on behalf of several people, of which the sender may or may not be one. In this case the sender should be the person who sent the message, the from is the person or persons on behalf of whom the message was sent. This will be discussed further on the list although there seems to be consensus at the meeting. (i) Really out of time; group adjourned.