Re: I-D ACTION:draft-klensin-email-envelope-00.txt

I agree with you. I believe SMTP can be used to offer a "dual" state
transaction model.   Yes, design and implementation confusion can be an
issue. However, I believe this only means it would become one of many
aspects for the new design to address and minimize.

I would like to suggest an approach borrowing old concepts such as Fidonet
when it was faced with new industry needs and state machine protocols.

The original and standard protocol was called FTSC1.   This was mostly based
on a kludged XMODEM handshake. A second one called WAZOO offered an easier
session handshake and introduced ZMODEM for data transfer.  A 3rd one called
EMSI addressed the session handshake issues. EMSI introduced text based tags
or attributes that defined and establish the compatibility level between the
client and server.  It also introduced new tags to define new file transfer
protocols.

If EMSI or WAZOO was not established,  the fallback was FTSC1.    As a side
note, for historical perspective, the demise of Fidonet was not helped by
the fact that the Fidonet or FTSC (Fidonet Technical Standards Committee)
protocol police insisted on backward compatibility.  WAZOO/EMSI flexibility
allowed for growth including new "internet readiness."  As new developers
come aboard to support the new direction (internet), most used the easier to
implement WAZOO/EMSI protocols and avoided FTSC1 mostly due to the fact it
was a complex outdated modified XMODEM7 binary protocol handle shake which
is probably akin to the idea of SMTP having no states other than DATA!   It
didn't fit well in packet switching networks. Security was weak and it
created conflicts between the development community and the FTSC.  Fidonet
operators or members found to be using non-FTSC1 compliant mailers were
excommunicated from Fidonet.  To get an Fidonet address (akin to getting a
MX record maybe),  your HOST (akin to maybe an ISP) would check for FTSC1
compliance.  Of course, IETF does not have strong "network" membership
requirements such as this, but I would hate to see the demise of the IETF
because it could not or was slow to address the current industry issues
and/or needs. It is all deja vu when you hear news that YAHOO is taking the
lead in changing the SMTP specification.

In any case,  WAZOO/EMSI was established with the SERVER answering with
special greeting allowing for EMSI or WAZOO detection.  The compatible
client detected either one and choose its method.  If the server did not see
a response within X seconds, it finally issued a FTSC1 detection packet.

With SMTP, I believe it would be a lot easier because SMTP is already
Text/Tag based.

The initial greeting 220 line can be used to define the SMTP attributes.  In
a way, we sort of having something like this now.   The BCP for the greeting
line is to use a "ESMTP" tag to indicate an Extended SMTP ready server.
However, I am not sure if anyone uses this since '2821' requires you to use
EHLO first anyway.

But we can use the greeting to define the server attributes which compliant
clients can read and use.

In Fidonet, to support WAZOO, WAZOO tag was used in the server greeting.
For EMSI, it used a EMSI tag. In addition, if EMSI was detected a handshake
was done to exchange and establish the session attributes.

With SMTP, it is easier:

examples:

220 host,  SMTP, SMTP3 [product info] Server Reader
220 host,  SMTP3 [product info] Server Reader

SMTP indicates old SMTP state support.   SMTP3 indicates the new state
support.    Non-compliant clients would not know the difference.  Only
clients looking for SMTP3 will know the level of support this server offers.
Whether backward support is required, I leave it to you guys to debate.
Please just remember what I noted above.  Confusion and conflicts is reduced
when developers (old or new) do what is only demanded by the market needs.
If old support is mandatory and is conflictive with security issues, then it
needs to be discussed whether old support is going to complicate migration
and acceptability.  The concept of allowing it to be option for system
administrators to decide should be discussed.

Once the SMTP3 session is established, the new state machine prevails!

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com




----- Original Message ----- 
From: "Keith Moore" <[email protected]>
Sent: Sunday, January 25, 2004 7:27 PM
Subject: Re: I-D ACTION:draft-klensin-email-envelope-00.txt


>
> I'm all for separating the envelope from the message content, but I'd
> be interested in investigating an even more radical change - (probably)
> scrapping SMTP entirely or (less likely) branching out of the SMTP
> state machine very early.  Or in other words, I could see making the
> new protocol similar enough to SMTP that a single server could
> implement both, but that might just invite confusion.
>
>