headers
IESG Secretary | 1 Sep 1992 23:45
Picon

IESG feedback on SMTP Extensions


After reviewing the extensive comments received in response to the last
call to publish "SMTP Extensions for Transport of Enhanced Messages" as
a Proposed Standard, the IESG requests that the SMTP Extensions Working
Group re-examine the protocol specification.

The Last Call illicited extensive comments, leading to IESG concern
that community consensus had not yet emerged about the specific
approach chosen by the Working Group. The IESG felt that the specific
concern about complexity, in particular the choice of a general
extension mechanism for SMTP in preference to a series of individual
extensions, was worthy of examination by the Working Group.

The IESG requests that the concerns raised be individually evaluated.
Where a concern has technical merit, i.e., it points to a technical
shortcoming in the protocol which will render it less effective than it
may otherwise be, the IESG requests that changes be made.  Where the
concern is one of engineering aesthetics, the IESG requests that the
rationale for the particular choice be reaffirmed.

Greg Vaudreuil
IESG Secretary
Permalink | Reply | 0 comments |
headers
John C Klensin | 2 Sep 1992 01:27
Picon

Request for instructions and advice on SMTP review

WG members:
  The following note was just posted to IESG in response to Greg's note 
asking us to review the complexity problem and other "concerns".  It is
my understanding (hinted at below), that a set of documents alternate to
RFC-ZZZZ will be posted by Crocker, Rose, and Stefferud (alphabetic
order) within the next day or two.  I've seen a draft, and they posit a
rather different approach to what, it might be argued, is the same
underlying protocol.  I would encourage people to study those documents
and then initiate a discussion about how to proceed.
      --john
--------------------------------------
   As chair of the WG, I'm happy to initiate the review requested.
However, as I have discussed in notes with individual IESG members, the
WG has sensed some real urgency about getting an acceptable standard
emitted.  Existing non-conforming "8 bit clean" implementations of SMTP
have apparently caused interoperability problems.  Nonetheless, there is
every indication that those implementations will continue to spread
until IETF takes a firm position on an alternate strategy for 8-bit mail
transport.  Insofar as a protocol that is not implemented by major
vendors can become pointless, the very proliferation of "8 bit clean"
implementations becomes a moving design constraint on the WG's efforts.

Consequently, if it is feasible, I would like to target doing this
review quickly enough to get IESG final action well prior to the
Washington IETF meeting.  It that is not possible, I fear that this
effort will drag on into obscurity as vendors who can convert to "8 bit
clean" convert to that behavior under considerable, and rising, customer
pressure and users and vendors who cannot make that conversion simply
get used to the damaged data and abuse which they will have to accept.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Einar Stefferud | 2 Sep 1992 09:32

New Concise SMTP Extension Specification Drafts

Hi All -- 

The draft-ietf-smtpext-8bittransport-06.txt announced in the IESG's last
call was produced by the SMTP Extensions Working Group in response
to various real-world concerns about current SMTP usage which has led to
a lack of interoperability in some parts of the Internet community.

Clearly something needs to be done as soon as possible.

However, the smtpext-8bittransport specifications have received
particularly strong community reactions, calling out that they are
overly complicated for the problems being solved.  This complexity may
very well become a barrier to adoption.

As a consequence, Dave, Marshall, and I (Stef) have developed an
alternative set of 3 drafts which concisely specify simple solutions
to the same problems.  We have taken simplicity as our key.

In particular, the 3 draft specifications provide:

1.  A framework for controlled SMTP extension and evolution

2.  A means for declaring an 8-bit SMTP transfer path

3.  A means for declaring the administrative size limit imposed by a
    server on messages it will receive.

We view these drafts as a refinement of the current working group
output.  In particular, the technical approaches are similar, albeit
simpler and expressed concisely.  As such, we are submitting these
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 3 Sep 1992 21:02
Picon

Re: ID ACTION:draft-rose-extensions-00.txt

>My major complaint about EHLO previously was that it listed the "supported"
>verbs, without being precise as to the level of support.  In contrast,
>the rose proposal lists keywords, which could well indicate levels of
>support for existing verbs, or which could imply a package of several
>new verbs.  As such it establishes a far better basis for future
>...

Neil,
   I don't know if the problem was your previous explanations or my
general denseness (probably the latter), but I now, *finally*,
understand what you were asking for/complaining about.  If I've got it
right now, I had been construing your remarks as "make the support
definition more precise" while what you were saying was "unbind the
keywords and their implications from the particular command names/
verbs".    If so, my attempts to make things more precise must have been
at least as frustrating for you as your comments were gradually becoming
for me.   Interestingly, I didn't read the distinction I now understand
you to be drawing into the Rose proposal either, but getting this right
is far more important than the present text of either proposal.
   I don't have any problems with your reading at all--at first blush, it
strikes me as a good idea.

   Have I understood correctly this time?

       --john
Permalink | Reply | 3 comments |
headers
Neil W Rickert | 3 Sep 1992 21:35
Favicon

Re: ID ACTION:draft-rose-extensions-00.txt

>Neil,
>   I don't know if the problem was your previous explanations or my
>general denseness (probably the latter), but I now, *finally*,
>understand what you were asking for/complaining about.

I'm willing to share the blame.  I probably did not make myself clear.
Perhaps because I knew what was wrong, but hadn't thought enough about
how it should be done until my exchange with you and Ned Freed a week
or two ago.

If you want to achieve extensibility with the server making an
announcement, and the client using what was announced, then you need
two requirements:

	There must be general agreement on the meaning of what is
	announced.

	The announced options must be useful.

The old EHLO proposal failed on both counts.

Implementations of SMTP vary, and whether they are compatible with some
types of potential usage (such as Ned Freed's streaming) cannot be
determined by a listing of verbs, unless the definition of those verbs
is made far more precise.

It was not useful to announce that you supported EHLO, since that was
already implicit.  It was not useful to announce that you support QUIT,
since you can't implement SMTP without it.  It was not useful to announce
SIZE, since that was a compulsory announcement you were required to make
(Continue reading)

Permalink | Reply | 2 comments |
headers
John C Klensin | 3 Sep 1992 22:42
Picon

EMAL reply interpretation and where we go next

Neil, and people generally....
   What I am going to propose to do here, pending another round of
interactions from/with IESG (presumably everyone has seen my protest
about the announcement) is to try to distill the differences--technical
and religious--between the existing document and the comments on the
list and between the existing WG document and the Rose/Crocker/Stefferud
proposals.  As they are aware from private conversations, I would have
preferred lists of comments to alternate documents, but different of us
work most efficiently in different ways.
    I don't want to do the distillation process completely myself: Not
only am I frighteningly busy right now for reasons that have nothing to
do with IETF, but it is extremely clear that I've developed some blind
spots.  But Neil's type of note, which I took as saying "ok, this is a
substantive difference between the two approaches and I like X better
than Y because..." is extremely constructive (whether one agrees or
not), because it helps focus us on what the real issues are in a way
that permits decision.
    Unless someone has better suggestions, I'm proposing that we
incrementally develop an issues list, discuss the issues identified and
try to reach some conclusions, and then determine whether either the
Rose/ Crocker/ Stefferud documents or the current WG draft are the
best basis for a rewrite and report back to IESG.

The first two items for the discussion list appear to be:
  (1) EMAL returns a comprehensive list of registered verbs  versus
      EMAL returns a list of keywords and definitions with the keywords
      registered and associated with standards-track RFCs.
  (2) Long, complicated, unified document, containing clarifications,
      implementer advice, folklore, etc    versus
      Several short documents that may leave a little bit to the
(Continue reading)

Permalink | Reply | 1 comment |
headers
John C Klensin | 3 Sep 1992 22:51
Picon

Comments on new/alternate SMTP ex (Mark Lottor)

For those of you who don't follow the IETF list, Mark Lotter just posted
the following message there.  

Mark, could we persuade you to subscribe to the WG list (if you have not
already done so) and participate in the discussion there (here)?  I think
it is everyone's intention that the proposed extensions, and alternate
presentation strategies, be discussed at some length, and the IETF list
is not the right place to try to carry out anything resembling an 
in-depth discussion.   ietf-smtp-request <at> dimacs.rutgers.edu

thanks.. 
    john
                ---------------

Return-path: <ietf-request <at> IETF.NRI.Reston.VA.US>
Received: from IETF.nri.reston.VA.US (132.151.1.35) by INFOODS.MIT.EDU (PMDF
 #2603 ) id <01GOCRJXMCF4000139 <at> INFOODS.MIT.EDU>; Thu, 3 Sep 1992 16:28:09 EDT
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa07537; 3 Sep
 92 15:42 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07498; 3 Sep
 92 15:41 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16409; 3 Sep 92 15:43 EDT
Received: from fernwood.mpk.ca.us by venera.isi.edu (5.65c/5.65+local-6) id
 <AA10287>; Thu, 3 Sep 1992 12:44:04 -0700
Received: by fernwood.mpk.ca.us; id AA25310; Thu, 3 Sep 92 12:45:36 -0700
Received: by nw.com (UUPC/extended 1.11p); Thu, 03 Sep 1992 12:34:46 PST
Date: 03 Sep 1992 12:34:45 -0800 (PST)
From: Mark Lottor <mkl <at> nw.com>
Subject: Comments on new/alternate SMTP extensions
To: ietf <at> isi.edu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil W Rickert | 4 Sep 1992 00:17
Favicon

Re: EMAL reply interpretation and where we go next

>The first two items for the discussion list appear to be:
>  (1) EMAL returns a comprehensive list of registered verbs  versus

I am taking the liberty of changing that 'EMAL' to 'EHLO' in quoting you.

>  (1) EHLO returns a comprehensive list of registered verbs  versus
>      EHLO returns a list of keywords and definitions with the keywords
>      registered and associated with standards-track RFCs.

I think I have made clear in my earlier messages that I support the
"keywords" approach.  It is far more flexible, and thus a better basis
for any future needed extensions.

>  (2) Long, complicated, unified document, containing clarifications,
>      implementer advice, folklore, etc    versus
>      Several short documents that may leave a little bit to the
>      imagination or to applicability statments (conformity or
>      "requirements" documents) yet to be written.

I am not in favor of leaving too much "to the imagination" so I suspect
that some of these shorter documents may become less short with time.
However simplicity favors the several short documents.

What is most important is that reliable 8bit clean transports be
implemented as widely and rapidly as possible.  That requires simplicity,
or else you will never get the cooperation of the many people who must
be involved in various implementations.  The old document came across
as a huge monolith which implementors could find quite intimidating.
Admittedly, once the old document was understood, it was not nearly so
frightening.  But initial appearances are important if they have the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eliot Lear | 4 Sep 1992 01:45
Picon

Re: EMAL reply interpretation and where we go next

> This ability to ignore SIZE for now, and keep the possibility open for
> the future is an example of the benefits of Marshall's approach.  It
> allows for modular development, instead of a monolithic effort containing
> features of unproven usefullness.

No, it essentially will kill SIZE dead if SIZE drags behind.  Can you
say `product cycle'?  I knew you could.

Eliot Lear
[lear <at> sgi.com]
Permalink | Reply | 0 comments |
headers
Julian Onions | 4 Sep 1992 09:54
Picon

Comments on the new drafts.


I have to agree with other users of this list that the proposed new
drafts seem a lot clearer and more consise definitions of extensions
than the previous version. It also allows much more freedom for
extension. 

Some comments I have after an initial reading, some of these are
techincal and some just suggestion for improvement of the documents.

SMTP Service Extensions

As the SMTP verbs are now split into Standard Verbs and Extension
Verbs I think it would be worth listing the standard verbs in the
paper too. E.g., the following verbs MUST be implemented, the
following are Extensions and are optional. This would then give the
definitive list of what has to be implemented and what is optional For
instance does HELO have to be implemented now? Is EHLO optional or
mandatory? Just writing these down would clear up any possibility of
confusion. 

(I think I know the answer to this one but am playing devils advocate)
Why do we require the EHLO, could we not just extend the reply code of
HELO so it was possible to tell if it was replying in new or old mode.
This would save one interaction with an old smtp server.

SMTP Administrative Maximum Message Size

I think it needs making clearer in this document that this option
should not be abused for other uses. In particular an implementation
should not attempt to assess how much spool space it has and send an
(Continue reading)

Permalink | Reply | 5 comments |

Gmane