Progress and consensus

[John C Klensin <KLENSIN@xxxxxxxxxxxxxxx>]

The note that follows is a summary, mostly  for people not at IETF, of
decisions reached in the WG meeting this morning.  This is "speak or 
forever hold your peace" time... if you are not here, and don't like any of
these decisions, the time to express your disagreement with coherent 
technical arguments and alternatives is right now--I'm going to start closing
things out tomorrow and finishing with that process as of Thursday before/
during the session.

The comments that follow are all based on the multipart document that Ned
posted last week.

We agreed this morning to focus on substantive issues, rather than editorial
things and to try to identify and then go through the substantive things
one at a time.  The list, as of the end of todays' meeting, was:

Document format:  Three+1 (Service extensions, Size, 8bit + informational)
or three+2 (... plus informational and folklore (Julian's doc)).  Decision:
that model, not one document, but with the expectation of advancing the three
together, i.e., "three documents, one standard".

SIZE:
  Change from kilo-octets to bytes, with supporting language.  Agreed to.
  Use of a single number versus several numbers (e.g., the old LIMIT).  Agreed.

This closes SIZE and I will assert that consensus exists on the current 
document unless someone complains immediately, raising new issues.  Any minor
editorial changes should go to Ned.


Service extensions/EHLO:
   Model that commands that don't take arguments should be extended (if at all)
with new verbs, not by adding parameters.   Deferred until Thursday.  Please
make any comments ASAP.
   
   Decisions to use multiple parameters on existing commands in preference to
adding a lot of new verbs.  Reviewed and agreed.

   Handling of error codes to distinguish between errors as a result of basic
verbs and errors from particular parameters.  No distinction among parameters
except in the ASCII text.  Consistent with tradition and the spirit of RFC1123,
things either succeed or fail and we do not provide for tricky negotiation or
alternative-seeking.   Agreed (this implies a change to Ned's drafts).


8bit clean:
   There was an extended discussion about the existing "8bit clean" vendors
and the supporting facilities they needed.  It was concluded that the 
CONVERT/NOCONVERT facilities did them no good and that, if the investment
was made to send EHLO, then it was plausible to make the further
investment to send MIME.   Hence, the WG agreed, following RFC-ZZZZ,
that "8bit" implies MIME.   This change removes the NOCONVERT/CONVERT/
and MIME keywords from the EHLO response, and eliminates the need for
conversion to application/octet-stream and  character set "unknown".  A
separate, non-standards-trace, document will be developed to suggest
transition strategies.   Status: Agreed, but see below.  This implies
changes in the documents, mosty excisions.

Relaying:  RFC1123 attempted to discourage relaying in the Internet,
Sending clients in quest of relays who could perform a conversion after
receiving a rejection from a target host probably represents bad policy
(although there is neither need nor desire to prohibit static
determination of conversion gateways).   Leaving the "go find a relay"
alternative in the text as a means of coping with rejections implies
error message complexities that are not worth the trouble.  Decision:
remove the text that appears to encourage finding a relay if mail cannot
be delivered as originally specified.

MIME-MIME conversions:  As things now stand, the text contains several
statements about MIME processing that effectively create two-way
crossreferences with the MIME document.  ZZZZ resolved this problem by
simply insisting that any conversions produce valid MIME, believing that
the definitions of "valid MIME" belonged in MIME documents, not in SMTP
extensions ones.      Question: should this text be moved back out and
dumped on the MIME effort?
    Status: deferred until Thursday.

Trace/received syntax: The document now overloads the Received phrase
"with" (specified in 821/822 as specifying a transport protocol) to
include conversion statements, e.g., "with 8bit-to-base64".  This
changes the semantics of the 821/822 definition, however subtly.  It
also produces a significant potential for misunderstanding, as evidenced
by the example in the text, e.g.,
    Received: from baiji.dbc.mtview.ca.us by dbc.mtview.ca.us
        with 8bit-to-base64
It is now clear what this means, since the translation/conversion would
normally occur intra-host.  One would expect to see either:
    Received: from dbc.mtview.ca.us by dbc.mtview.ca.us
        with 8bit-to-base64
(continuing the overloading but showing this as an intra-host
transaction)    or
    Received: from baiji.dbc.mtview.ca.us by dbc.mtview.ca.us
        with smtp convert 8bit-to-base64
(retaining the binding of "with" to a transport mechanism and adding a
simplified version of the ZZZZ model in which the conversion, performed
on "dbc.mtview.ca.us", is explicitly documented.)
   Status: deferred until Thursday.


The conversion issue: We are back at the point (a variation on the
"wretched solution") of expecting that any MTA who is willing to accept
8bit traffic must be prepared to convert to 7bit [MIME] if needed.  This
implies the ability to parse MIME and make per-body-part decisions,
raising the threshold of effort that must go into such an MTA and
forcing inclusion of a facility that will be unneeded if we ever get to
an entirely 8bit world.  The WG agreed to this in San Diego and did not
raise it again in Washington, nor was the issue raised during the Last
Call discussion /cries of agony.  It has, however, been suggested that
there never was real consensus, just exhaustion.   I don't want to see
this issue reopened unless
someone has something new to say.  However, if the alternative is that
people within the WG would otherwise raise the issue during Last Call,
I'd rather get it over with now.
   Status: This is closed unless someone raises a new, and coherent, 
argument for reopening it.

MXE:  SHould this proposal for a DNS extension be withdrawn?
    Status:  NOt discussed yet.




If you disagree with decisions made already, please post your reasons
and explanations.   If you have opinions about the open or deferred
issues that you would like considered, please post them.   I expect to
make a decision about shortening the Thursday session by late afternoon
Wednesday, so please get comments in by then if possible.

   --john