Message-ID: <004101c3e218$87970620$6401a8c0(_at_)FAMILY>
From: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: <ietf-smtp(_at_)imc(_dot_)org>
References: <E1B950CE-4DF6-11D8-85D7-000A9571873E(_at_)guppylake(_dot_)com>
Subject: Re: I-D ACTION:draft-klensin-email-envelope-00.txt
Date: Fri, 23 Jan 2004 20:22:26 -0500
Organization: Santronics Software, Inc
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_003E_01C3E1EE.9E18D740"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
This is a multi-part message in MIME format.
------=_NextPart_000_003E_01C3E1EE.9E18D740
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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.
--=20
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----=20
From: Nathaniel Borenstein=20
To: John C Klensin=20
Cc: ietf-smtp(_at_)imc(_dot_)org=20
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.=20
------=_NextPart_000_003E_01C3E1EE.9E18D740
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2>I agree =
Nathaniel. Any change to=20
SMTP needs to be significant in what it addresses and if done, the =
opportunity=20
should be use to address ALL major contemporary mail industry =
issues to=20
minimize future change or extension requirements.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>In addition, I know this may =
not be a=20
popular view, I don't believe any change (or extension) would have =
significant impact unless the functional specifications make it possible =
NOT to=20
be BACKWARD compatible at the system admin policy level. In other =
words,=20
allow the SysAdmin to decide the level of compliance. In this vain, =
I=20
believe that future SMTP change proposals should begin with a design =
review on=20
the concept of "client/server protocol compliant level"=20
identification. SMTP should be given a "IETF VERSION" =
stamp, much=20
like HTTP 1.0/2.0, etc. and it should be part of the protocol=20
handshake (or possibly DNS MX lookup) that clients and servers can use =
to=20
determine level of compliancy. While ELHO can be used to identify=20
extensions, deployment is minimized by not having an enforcement =
statement=20
in the functional specifications. Future SMTP operations require =
stronger=20
policy base operations so that if a COMPANY does not want to allow for =
example,=20
non-ENVL compliant clients, it should be allowed because =
the functional=20
specification (RFC) allows developers to make it =
possible.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>-- <BR>Hector Santos, =
Santronics Software,=20
Inc.<BR><A=20
href=3D"http://www.santronics.com";>http://www.santronics.com</A></FONT></=
DIV>
<DIV> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A title=3Dnsb(_at_)guppylake(_dot_)com =
href=3D"mailto:nsb(_at_)guppylake(_dot_)com">Nathaniel=20
Borenstein</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Djohn-ietf(_at_)jck(_dot_)com=20
href=3D"mailto:john-ietf(_at_)jck(_dot_)com">John C Klensin</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dietf-smtp(_at_)imc(_dot_)org=20
href=3D"mailto:ietf-smtp(_at_)imc(_dot_)org">ietf-smtp(_at_)imc(_dot_)org</A>
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, January 23, 2004 =
5:52=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: I-D=20
ACTION:draft-klensin-email-envelope-00.txt</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT><BR></DIV>John -- It's =
a pity to=20
say this about such a nicely-written draft, but I fear this proposal =
comes=20
remarkably close to maximizing the cost/benefit ratio. When you =
consider=20
distributed costs of testing and deployment, I would bet that =
implementing=20
this proposal would cost at *least* 50% of what it would cost to =
deploy a far=20
more radical set of changes to the email infrastructure. <BR><BR>
<BLOCKQUOTE><FONT face=3D"Courier New"=20
size=3D2></FONT> </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_003E_01C3E1EE.9E18D740--