--On Wednesday, 11 April, 2007 09:25 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
...
I hope everyone understands that nothing in 2821 prevents an
extension from being designed, proposed, and adopted that, if
appropriately agreed to between server and client, changes any
or all of those rules. If 2821 is not clear on that topic,
then it should be and I would welcome appropriate text for
2821bis.
To the extent to which the concern is that making these rules
more specific (or implied prohibitions more clear) in 2821bis
would prevent such extensions, I think we need to clarify that
the concern is groundless.
Does that bring our positions closer together?
If I understand the question, you are saying that an I-D
proposal can update and even go as far as change an RFC and my
"assumption" that it can not is an incorrect assumption?
An I-D cannot. But the current flavor of SMTP, from RFC1425
forward, is rather carefully designed, and I hope clearly
documented, so that a standardized extension that is offered by
the server and invoked by the client, may change just about any
aspect of SMTP behavior. "Just about" because an extension
clearly cannot change either the behavior of the greeting
message nor the syntax and semantics of EHLO and its reply.
Other than that, it is pretty much open season. The protection
against stupid things is the review and standardization process,
not words in 2821 or its successors that say "the extension
mechanism can never be used to do so-and-so".
So I think your implied assumption that text in an RFC saying
"this is forbidden" prevents doing exactly the same thing via an
extension is incorrect in two respects. First, to all practical
intents and purposes, any statement in 2821 that permits or
forbids something must be read to include "unless a specific
extension that is offered by the server and invoked by the
client changes this". And, second, in that you take those
statements as banning particular styles of extensions.
In particular, while I can think of several approaches I would
prefer to it were it proposed, there is no restriction in 2821,
and no restriction anyone has considered putting into 2821bis,
that would prevent
Extension reply value: KEEPALIVE150
New command: ENKP (enable keepalive)
Semantics: If KEEPALIVE150 is included in the EHLO reply from
the server, the client may issue the EKNP command before a mail
transaction is initiated (e.g., before a MAIL command or after a
RSET or completion of a DATA command and before the next MAIL
command). Once issued, the EKNP command applies for the rest of
the connection. With the EKNP command in effect, a 150 reply
code is to be taken as a "keepalive" by the client with any
associated text ignored. The 150 may appear as part of a
multiline reply, in which case the client's timers for timeout
purposes are reset but the line is otherwise ignored. If it
appears as the code on a single-line reply, or as the final code
in a multi-line reply, the client must respond with either (i) a
QUIT or RSET command, with the usual meaning or (ii) a NOOP
command, to which the server may respond with either a reply
containing a 250 "ok" code or one containing another 150 code.
That would, with a few more details, be a valid proposal
regardless about what 2821 said about unextended SMTP. Again,
I'm not suggesting it would be either optimal or wise -- that is
a separate discussion.
It is my understanding that an proposal can propose changes to
current spec.
But I have a hard time answering that because whether you
believe it or not, I am extremely pragmatic and conservative.
I don't want to break operations for anyone nor for us. Thats
the last thing I want.
And that is exactly why these things should be done, if at all,
by extensions to which the server and client must explicitly
concur rather than by tweaking the text to open up more
loopholes and/or make existing conforming behavior invalid.
Here is my opinion above the above items:
Not what I asked. I was only trying to check whether, even if
those restrictions were stated in the very restrictive way in
which I stated them, you understood that an extension could
override them. It is still not clear to me that we agree on
that.
However, to try to clarify one thing...
I don't (iii) is necessary because
it is SUBJECTIVE plus you have no control over this usage.
(iii) was "multiline replies MUST NOT be used as an attempt to
affect client timing or timeouts". I don't think that is
subjective at all. The server implementer knows his or her
intent about the codes being sent. And this authorizes the
client to treat any sort of "150- Please wait" line as lying
well outside the standard and then decide whether to simply
ignore or generate a command at its earliest convenience that
would probably be "RSET" or "QUIT".
...
At this point, maybe Hansen had the best (personal hat on)
advice:
"don't do anything now that would prevent such an
extension
from being written."
And no such thing has been proposed. By anyone.
john