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.
