I agree Nathaniel. Any change to SMTP needs to be significant in what it
addresses and if done, the opportunity should be use to address ALL major
contemporary mail industry issues to minimize future change or extension
requirements.
In addition, I know this may not be a popular view, I don't believe any
change (or extension) would have significant impact unless the functional
specifications make it possible NOT to be BACKWARD compatible at the system
admin policy level. In other words, allow the SysAdmin to decide the level
of compliance. In this vain, I believe that future SMTP change proposals
should begin with a design review on the concept of "client/server protocol
compliant level" identification. SMTP should be given a "IETF VERSION"
stamp, much like HTTP 1.0/2.0, etc. and it should be part of the protocol
handshake (or possibly DNS MX lookup) that clients and servers can use to
determine level of compliancy. While ELHO can be used to identify
extensions, deployment is minimized by not having an enforcement statement
in the functional specifications. Future SMTP operations require stronger
policy base operations so that if a COMPANY does not want to allow for
example, non-ENVL compliant clients, it should be allowed because the
functional specification (RFC) allows developers to make it possible.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: Nathaniel Borenstein
To: John C Klensin
Cc: ietf-smtp(_at_)imc(_dot_)org
Sent: Friday, January 23, 2004 5:52 PM
Subject: Re: I-D ACTION:draft-klensin-email-envelope-00.txt
John -- It's a pity to say this about such a nicely-written draft, but I
fear this proposal comes remarkably close to maximizing the cost/benefit
ratio. When you consider distributed costs of testing and deployment, I
would bet that implementing this proposal would cost at *least* 50% of what
it would cost to deploy a far more radical set of changes to the email
infrastructure.