Editor's note: These minutes have not been edited.
Minutes recorded by Ned Freed <ned@innosoft.com>
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.