Date: Tue, 04 Aug 1998 14:13:35 -0700 (PDT)
From: DRUMS WG Chair <Chris.Newman@innosoft.com>
Subject: Call for Concensus on Recent issues
To: Detailed Revision/Update of Message Standards <drums@cs.utk.edu>
Message-id: <Pine.SOL.3.95.980804135710.29185B-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM

This is an attempt to reach closure on most of the minor issues which
have been raised recently with the SMTP spec.  If there are fewer than
two objections to any of the proposed resolutions here, I will assume
rough concensus has been achieved.  Please read carefully and object
only if you feel further debate on the issue is important enough to
merit potential delay of the completion of the SMTP spec and the DRUMS
WG.

(1) One WG participant believes SMTP fails to achieve the goal
statement and that the goal statement should be removed.  Others
disagree.

> The objective of the Simple Mail Transfer Protocol (SMTP) is to
> transfer mail reliably and efficiently.

Proposed resolution: no change to draft

(2) Section 1 paragraph 3 is confusing.  One WG participant wants it
removed, others want it clarified.  Replacement text has been proposed
by Nick Shelness and Philip Hazel.

Proposed resolution: Document editor will clarify draft based on
suggested text.

(3) Section 2.1 paragraph 1 model is too restrictive.  Replacement
text has been proposed by Nick Shelness and Philip Hazel.

Proposed resolution: Document editor will clarify section based on
suggested text and remove some restrictions.

(4) Section 2.1 paragraph 2 is too restrictive for Internet mail.
Amendment has been proposed by Philip Hazel.  The chair observes the
current text is technically correct given the section is restricted to
the "SMTP model," but has no objection to proposed amendment.

Proposed resolution: Document editor will clarify section somewhat
based on suggested text.

(5 & 6) Section 2.2.1, last paragraph uses MUST for support of EHLO.  One
participant wants requirement removed, others believe it's important
for servers, but less important for clients.  It was observed that
this section refers to "contemporary implementations."

Proposed resolution: Weaken client requirement slightly so that
clients are required to support EHLO, but are not required to
preferentially use it.  This is a compromise between those we want a
high standard for contemporary implementations and the reality of some
implementations.

(7) Section 2.3.1, Paragraph 4 implies MIME is the only form of
structured body.  Philip Hazel and Nick Shelness have proposed text.
Chair observes that MIME and RFC 1049 are only standards track formats
for structured body.

Proposed resolution: Document editor is changing this to just
reference MIME as the standards track form for structured bodies.
This is a minor issue not worth a lot of debate.

(8) Section 2.3.5, paragraph 1 definition of domain is deemed overly
strict by some.  Philip Hazel proposed text.

Proposed resolution: Document editor will clarify based on Philip's
proposed text.

(9) Section 2.4.1, paragraph 2, a "command" or "reply" in the generic
sense may be case sensitive, while a command word is not case
sensitive. Philip Hazel and Nick Shelness have proposed alternate
text.

Proposed resolution: Document clarify based on proposed text.

(10 & 11) Section 2.4.1, paragraph 3, 8-bit rules
(23) Section 4.1.2, 3rd paragraph from end.

The issue of 8-bit was extensively discussed and closed long ago in
the WG due to lack of concensus.  No change from RFC 821/1123 rules
will be made in this spec (namely that 8-bit isn't permitted anywhere
without a suitable extension).  The chair considers 8-bit issues a
rathole.

Proposed resolution: Document editor will make no technical changes to
this section, but may clarify the restrictions at his discretion.
Chair considers this issue closed.

(12) Section 2.4.2, 3rd paragraph identifies an implementation problem
with no suggestion for a workaround.  Nick Shelness and Dan Bernstein
have proposed text.

Proposed resolution: Document editor may at his discretion delete the
paragraph or revise the text along the lines of that proposed text.
If it would unduely delay publication, no change will be made as this
is a minor issue.

(13) Section 3.1, paragraph 4, some object to the requirement not to
send EHLO-style response to HELO command, others don't object.

Proposed resolution: no change to draft

(14) Section 3.3, paragraph following MAIL command syntax has a MUST
requirement which forbids deferred rejection of MAIL FROM.  Extensive
replacement text has been suggested by Philip Hazel and Nick Shelness.

Proposed resolution: Discuss on list and at IETF.  Document editor may
use his discretion for the time being.

(15) Section 3.5.1, paragraph 2, "response MUST include the mailbox of
user" only applies to 250 responses.  Some would prefer removal of
MUST.  Chair observes that MUST is in spirit of what RFC 821 says.

Proposed resolution: revise section to address concern about scope of
requirement.

(16) Section 3.5.1, paragraph 5, "the multiline response ... MUST give
the mailboxes on the mailing list" only applies to 250 responses.

Proposed resolution: revise section to address concern about scope of
requirement.

(17) Section 3.5.2, paragraph 2, requirements deemed unreasonable by
two participants, deemed reasonable by others.  Current text is
directly from RFC 1123 so is the default without a rough concensus to
the contrary.

Proposed resolution: no change to draft

(18) Section 3.5.4, paragraph 1.  Some people consider the first
sentence inaccurate, others do not.

Proposed resolution: no change to draft

(19) Section 3.7, last paragraph, requirement to not inspect headers
forbids hop counting.  Philip Hazel has suggested text.

Proposed resolution: revise text so hop counting is permitted.

(20) Section 3.9, paragraph 2.  One WG participant believes
requirement that server not intentially close the connection without
sending a shutdown notice to the other end is too restrictive, others
disagree.  It has been observed that crashes are not "intentional."

Proposed resolution: no change to draft

(21) Section 3.10, paragraph 1.  Recommendation to support both
aliases and lists is deemed unreasonable by some.

Proposed resolution: Issue will be raised on list and/or at the IETF
meeting.  For time being, document editor will use his discretion.

(22) Section 4.1.1.10, paragraph 2. Client MUST NOT intentially close
channel without sending QUIT and waiting for reply deemed too
restrictive by some, not by others.

Proposed resolution: no change to draft

(24) Section 4.1.2, last paragraph.  Some participants want language
about what to do if requirement is violated.  Others don't want such
language added.

Proposed resolution: no change to draft

(25) Section 4.3.2, 501 response code to DATA/NOOP/RSET with excess
arguments.  Discussed extensively on mailing list and at WG meetings.
Chair is unable to find record of decision in WG minutes although he
recalls a lot of debate.

Proposed resolution: measure rough concensus at next IETF meeting.
Until then, no change to draft.

(26) Section 4.4, local time preferred to UT in Received.  One WG
participant disagrees with language.  Some want reason for preference
explained.

Proposed resolution: Document editor will add justification for this
preference.

(27) Section 4.5.3, rejection of messages with fewer than 100
recipients is violation of specification.  Rule considered
unreasonable by one WG participant, others disagree.

Proposed resolution: no change to draft

(28) Section 4.5.4.1, paragraph 3.  Retry algorithm MUST be
configurable.  Requirement deemed unreasonable by some, useful hint by
others.  Text is from RFC 1123, so default if no concensus is to leave
it.

Proposed resolution: no change to draft

(29) Section 4.5.4.1, last paragraph. "When the same message will be
delivered to several users on the same host, only one copy of the
message SHOULD be transmitted."  Rule deemed imprecise by some, wrong
by one WG participant.  Text suggested by Philip Hazel and Nick
Shelness.  WG chair observes that many need one copy per 100 recipients.

Proposed resolution: Document editor will clarify recommendation.

(30) Section 6.1, paragraph 2.  Requirement not to generate
notification in response to <> excludes postmaster response.  Text
suggested by Philip Hazel.

Proposed resolution: Document editor will clarify text to make it
clear "no response over the network" is appropriate.

(31) Section 6.2, paragraph 1.  Word "trivial" in loop detection
requirement makes it vague.

Proposed resolution: Relatively minor issue -- given lack of clear
alternative text, no change will be made.

(32) Section 6.3 paragraph 2.  One WG participant finds hypothesis
about split-UA mail readers exacerabing problems implausible.  Others
disagree.
(33) Section 6.3 paragraph 3.  Some find assertion that message
rewriting was a result of weak clients to be false.

These are completely non-normative issues.  It's too late in the cycle
to waste time on them.

(34) Section 7.1 paragraph 1.  Statement that SMTP mail inherently
can't be authenticated/integrity-checked at transport level is deemed
inaccurate by some.  WG Chair observes there are two proposals in IETF
last call which can provide authentication and integrity protection at
transport level, both are deployed in real-world products.

Proposed resolution: reword to state that transport-level
authentication and integrity protection provides inherently inferior
security to that provided by end-to-end services.

(35) Section 7.2, paragraph 1.  Recommendation about copying RCPT
information into headers needs to be clarified.  Some suggest there's
no problem with one RCPT, one thinks envelope leakage into headers is
bad on any relay.

Proposed resolution: Relatively minor issue, document editor may
clarify.