Message-Id: <199512062114.QAA24141@info.cren.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 6 Dec 1995 16:19:03 +0100
To: drums@cs.utk.edu
From: conklin@info.cren.net (Jim Conklin)
Subject: Notes on Tuesday's WG meeting


Meta-issues
-----------

    Keith Moore chaired the Working Group meeting and began it with a
brief review of the WG activities and mission.  He noted that the
mission of the WG is to:
        * clarify ambiguities
        * fix broken things
        * unify documents
        * not add new functionality
Discussion highlighted the cost of breaking the installed base.

    Keith presented the scope of the WG as:
        * native Internet mail
        * don't relax standards for gateways (clearly specify conformance
                requirements)
        * doesn't include gateways, news, or MIME
        * does include header/envelope of mailing lists
        * specify 821 language (not UA functionality)
        * recommend UA behavior (but UA's have a lot of lattitude)

    He raised several meta-issues he wanted the WG to address, including
        * What does it mean to be broken?  (Criteria for brokenness)
        * How do we deal with  intractible issues (on which WG consensus
                appears impossible)?
        * Criteria for making decisions (cost vs. benefit)
        * Possible choices, from recommending no change to deprecating an
                old feature and replacing it with a new one

    Discussion included what to do about references to RFC 821, and the
extent to which the new document is to be all-inclusive.  There was at
least rough consensus that a guiding philosophy should be to create a
document that is sufficient to guide implementation of a modern SMTP
agent.  This allows reference to 821 for non-deprecated features which
are not recommended or required to be supported by a current SMTP agent.
Discussion on deprecation suggested that is would be useful to
distinguish clearly between what is
        * forbidden
        * undesirable but not forbidden
        * unused and probably not harmful, but not generally useful either

    Discussion suggested that brokenness includes situations in which:
        * mail is lost or mis-delivered, with no error message returned to
                document the unsuccesful delivery
        * situations occur in which compliant behavior causes unnecessary
                "user astonishment"

    The new document should update and clarify 821 in areas which have
developed since it was written, it should clarify any other ambiguities,
and it should document the oral traditions that clarify 821 and its
successor RFC's.  An example of a development subsequent to 821, for
which clarification is desirable, is the domain name system.  The
document should address protocol errors, configuration requirements, and
operational requirements.  Where ambiguities exist in 821, they should
be explicitly called out and either resolved, or (if the WG can't agree
on a resolution) described with the effects of the various
interpretations and the trade-offs they involve.

    When the WG cannot reach consensus, it should at least document the
problem, as indicateda above.  The WG could punt to the current practice
as a way of solving the problem, and it could spin off a separate group
to pursue the issue and perhaps draft a new RFC proposing a solution.

    Criteria for decisions involving changes from previous practice
should include the anticipated benefit versus the cost (disruption) to
existing systems and the cost of implementation.  It must take into the
account the long transition from an old behavior to the new behavior,
with coexistence of both during this transition.


The Nature of the Document(s)
-----------------------------

    Discussion moved on to the nature of the document(s) that the WG
will produce.  It was agreed that an introductory overview was not
desirable, because it (based on previous experience) tends to be read
without the subsequent details as the specification.  However, a
separate informational RFC providing such an overview was generally
considered to be a good idea.

    There was consensus that multiple documents would be better than a
single, all-inclusive document.  (This is already the case, since mail
depends on the underlying transport protocols described in separate
documents.)  One document should describe the underlying model for
Internet mail (as a detailed specification, separate from the
abovementioned overview).  This should be referenced by the "821-bis"
document currently being drafted, and also by the anticipated "822-bis"
document.  This document should provide references to all the associated
RFC's (probably including those that describe the underlying transport
protocols).  Keith noted that additional editors, with close
collaboration among them, will be needed for this approach to be
effective.

    The desirability of a separate document defining the ABNF was raised
later in the discussion, with general agreement that such a document
would be desirable and should also provide the ABNF definition of a
common set of the "terminals" used by other RFC's (such as "character",
"digit", etc., but not including, for example "domain").


Addressing and Routing Issues
-----------------------------

    Concern was expressed about the handling of the forward path in the
draft, in light of 1123's efforts to encourage the use of MX records to
replace source routing (which the draft did not seem to reflect).  There
was general agreement that the document should be revised to encourage
use of MX rather than of source routing, but should also describe the
proper behavior of the SMTP agent when presented with a source route.
There was no consensus as to precisely how this should be done, or
whether it should be moved into a separate document.  (1123 suggests 3
alternative possibilities, each of which is acceptable.  As I recall,
they are: use the source routing; ignore the source routing, using MX to
resolve the mailbox address; refuse to send the source-routed message.)

    Klensin noted that the draft already incorporates material from RFC
974 on MX records, which should help encourage compliance with 974's
requirements for MX.  No objection was raised to that.  Klensin also
noted that the final documents would resolve the differences between
RFC821 and 822 regarding mail routing and addressing.

    Keith promised to work with the individual authors and editors to
resolve the issue of whether mail addressing and routing should be
handled in a separate document or left in the present draft.


Other Commands
--------------

    There was an extended discussion about EXPN and VRFY.  Concerns were
raised about the close linkage between the two in the present draft, and
about whether each should be required (and whether the draft said they
should).  Discussion indicted that VRFY was felt to be more important
than EXPN, and that a stronger verification than presently required
(provided) would be useful.  There seemed to be a consensus that both
are useful for debugging purposes and should be required for debugging
use only.  Participants were encouraged to send their suggestions to the
list.

    It was noted that there was no mention of the 521 reply code.  The
explanation was that it's only an experimental protocol at present and
that there are evidently problems with part of it.

    TURN also evoked considerable discussion, with the consensus being
that it should be deprecated in favor of other mechanisms now being
discussed to solve the same problem.  (Despite the fact that there are
also proposals in progress to provide adequate security, no one spoke in
favor of retaining TURN.)

    There was consensut to explicitly deprecate SAML, SOML, and SEND,
while retaining them as commands that could be used by older systems
without violating the new standard.  (The alternative of remaining
silent about these three was discussed and rejected.)

    As mentioned earlier, it was agreed that a separate document should
define the ABNF notation and a limited set of basic ABNF definitions of
broad relevance, for reference by the other documents.

    A concern was raised about how to handle time-outs, but the meeting
timed out without resolution of this issue.

    Folks should refer to Keith 12/01 proposed agenda, in preparing for
Firday's follow-up meeting.


Submitted by Jim Conklin.