Subject: Minutes from Chicago?

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 24 Sep 1998 13:40:10 -0700

I was unable to have fun in DRUMS last month because I had to be in PKIX (I
think). But I haven't seen the minutes yet, nor have I seen any last calls
or new drafts. When might we see the minutes?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Barry Leiba" <[email-masked]>
Date: Mon, 28 Sep 1998 12:05:45 -0400

Paul Hoffman asks
> When might we see the minutes?

I have to give profound apologies to all the DRUMS folks: I was responsible for
taking notes but, for a few reasons, I haven't put together the minutes yet.  I
will give it my first priority now, and will try to have them posted to this
list today.

Barry Leiba, Multimedia Messaging  ([email-masked])
http://www.research.ibm.com/people/l/leiba

---

From: "Barry Leiba" <[email-masked]>
Date: Mon, 28 Sep 1998 15:56:55 -0400

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".

* 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 (so, in particular, "00"
  means "1900", not "2000").
  
* 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; please let
me know of any errors of substance.

Respectfully submitted,

---

From: Pete Resnick <[email-masked]>
Date: Mon, 28 Sep 1998 16:19:25 -0500

Two additions/corrections:

>* The spec needs to be checked for consistent use of the term "token".

Addition: Several people volunteered to contribute to the scouring of the 
text (which was done very well I might add) and the editor will make 
corrections as needed.

>  means "1900", not "2000").

No, the issue was whether the text implied that you could have years prior 
to 1900. The text will be corrected to reflect that you cannot.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

---

From: Robert Elz <[email-masked]>
Date: Wed, 30 Sep 1998 11:26:24 +1000

Date:        Mon, 28 Sep 1998 15:56:55 -0400
    From:        "Barry Leiba" <[email-masked]>
    Message-ID:  <[email-masked]>

By this time in the meeting was everyone asleep and/or bored?   This looks
to the the worst of all possible outcomes.   The first part (clients MUST NOT
send) is fine.  But "servers SHOULD reject" is simply silly.   That way
everyone loses.  The only two reasonable alternatives are "servers MUST reject"
or "servers MUST ignore junk".   Either of those would be tolerable,
"servers SHOULD ignore" looks as if people thought it was a reasonable
compromise position - and it isn't.   The effect is that in practice servers
must check for, and reject if they see, any spurious noise after these 
commands, just so the server can claim conformance the way they'd prefer (one
less explanation to give - the implementation cost of this check is small
enough that having to explain why it isn't done all the time would be worse).
On the other hand. because the spec doesn't actually require all servers to
reject the noise, it will never be possible to assume that non-broken servers
actually do reject it.

Please, let's revisit this decision, and pick one of the two reasonable
choices, rather than attempting to half appease everyone by picking something
that isn't right for anyone.

As I've said before, I (slightly) prefer "servers MUST reject" but it is
much more important that a sane statement be made than that it be that
particular sane statement.

Here I have no problem with the outcome, but was there no-one at the
DRUMS meeting this time who understands the DNS?   There is no DNS rule
anywhere that prohibits underscores in domain names.   None.   Nowhere.
There's certainly 821 and 822 rules that prohibit them in e-mail, and if the
consensus is not to change that, that's just fine.   But please, let's not
pretend that we're in any way constrained by DNS rules here, we aren't.

kre

---

From: "Barry Leiba" <[email-masked]>
Date: Wed, 30 Sep 1998 17:51:03 -0400

> pretend that we're in any way constrained by DNS rules here, we aren't.

It's entirely possible that this is due to my fuzzy memory and unfortunate
loss of some of my notes.  Can someone else who was there clarify this item
and say whether what I report above is or is not something that was actually
said at the meeting?