Minutes from DRUMS WG, 42nd IETF, Chicago, IL Chris Newman (WG chair) calls the meeting to order. Dave Croker (ABNF document editor) reports on the ABNF spec: * He'll put out one more minor revision, and then the document will be ready for last call. Pete Resnick (822bis document editor) reports on the 822bis spec: * The spec needs to be checked for consistent use of the term "token". Several people volunteered to contribute to the scouring of the text (which has since been done) and the editor will make corrections as needed. * There was discussion about whether bare CR and bare LF should be allowed at any level in the grammar. Consistency with RFC822 is desired, but existing implementations differ as to what they allow. Discussion continues along the line of allowing them in the accept grammar but not in the generate grammar. No clear consensus emerges. WG chair determines that, lacking consensus, the spec will remain as it is. * There was discussion about handling of two-digit years. Consensus is that two-digit years should have 1900 added (that is, you cannot have years prior to 1900). The text will be changed to reflect this. * There was discussion about allowing various special characters in header field names. Consensus: allow them, for consistency with RFC822. * The -06 level of the spec will go to "working group last call". John Klensin (821bis document editor) reports on the 821bis spec: * The editor explains his use of RFC1123 conventions, rather than RFC2119 conventions. There is some discussion about this, the result of which is that changing the entire document over to RFC2119 will require clarifications to RFC2119 terminology and will delay the document too long, therefore, the document will remain with RFC1123 conventions. Specifically: The goals of this document are to remove ambiguities and to clarify both current and recommended practice -- that is, to define what SMTP is meant to be, and to describe the behaviour of existing SMTP implementations. RFC2119 is good for describing desired behaviour, but not for describing actual current behaviour. * There was extensive discussion about appropriate responses to VRFY (and EXPN, though the discussion centered aroung VRFY). At issue is whether implementations that always reply 252 to any VRFY command may be considered compliant. Comment: sites need to have the flexibility to configure the behaviour based on their security and debugging needs. The editor has been given text for this section, but the text differs from what's in RFC1123. It's agreed that it's OK to diverge from RFC1123 here. Consensus is for 821bis to specify that VRFY SHOULD (not MUST) be implemented, and that security implications must be explained. The document will be silent on the issue of configurability or default setting. * There was discussion about whether the sender's address may or may not be deleted from an expanded address list. Consensus is that expansion MUST be complete, with no deletions. Existing language is imprecise, and the editor is looking for wording to make it clear. * There was discussion about whether clients MUST, SHOULD, or MAY use EHLO. At issue are firewalls that block EHLO and server implementations that do suboptimal things when they receive EHLO (rather than just rejecting it as an invalid command). Further, some feel that there's no reason to force a client to use EHLO if HELO will do. Consensus is that "SHOULD use EHLO" be dropped, and a client that doesn't need extensions may use EHLO or HELO at the client's discretion. * There was discussion about whether a client must send QUIT and whether it must then wait for the server's reply. Some don't want to send QUIT at all, but some server implementations lose messages that way. Suggestion about a "flag day" to phase out is rejected as being bad for interoperability. Consensus is to leave QUIT as a "MUST send". As to waiting, it's claimed that having the client wait puts the TCP timeout wait on the client, where it belongs. It's then counterclaimed that NOT having the client wait (that is, having the client close the socket first) is actually what puts the timeout wait on the client. Consensus is to change "MUST wait" to "SHOULD wait" (and some would prefer "MAY wait" or nothing at all). * There was discussion about whether a server should be required to reject spurious parameters on commands such as RSET, which don't have any parameters. The document currently says that servers MUST reject such commands. The consensus is that the spec should be changed to say that clients MUST NOT send them and that servers SHOULD reject them. * There was discussion about allowing the underscore character in domain names. Currently the document says that servers MUST reject invalid characters in domain names. DNS rules also do not allow underscores in domain names, but some existing implementations do allow them. Despite that, there is no consensus to change the 821bis spec. * There was discussion about whether to use local time or GMT in Received headers. Argument for GMT is consistent time zones. Argument for local time is that it's sometimes useful to know the local time at the relay, and that conversions to GMT can suffer from time zone errors. Consensus is to stay with local time. * There was discussion about the use of response code 571 when rejecting a RCPT TO for delivery policy reasons. Alternative suggestions are 550 and 553. Claim: 553 is used for something else and isn't appropriate. Claim: can't add another code because that will break existing clients. Claim: RFC1123 says that if the client doesn't recognize the code, it should use the first digit to determine what to do. Claim: despite what RFC1123 says, existing clients get confused with unknown codes. The consensus is that no new code should be added, and that code 550 should be clarified for use in this situation. * The editor reports that because of the amount of work still needed on the document, multiple revisions will be needed before last call. * The issue of allowing bare CR in SMTP commands was brought up. Consensus is that bare CR is NOT permitted in commands. Time is up, and the WG chair closes the meeting. The scribe regrets that because some of his notes were lost, the names of those who volunteered to provide bits of document text are not available. Many thanks to John Noerenberg of Qualcomm for helping to fill in the gaps. Because of the missing notes, any errors or omissions are mine.