--On Sunday, October 30, 2011 11:10 +0100 "Peter J. Holzer"
<hjp-ietf-smtp(_at_)hjp(_dot_)at> wrote:
On 2011-10-29 19:51:16 -0400, John C Klensin wrote:
In reverse order... most of the extensions so far are "server
offers"/"client wants". There are exceptions, such as
ENHANCEDSTATUSCODES and PIPELINING (note that the former works
without a client request precisely because SMTP doesn't
specify syntax for the portion of replies that follow the
three-digit code).
The "structured text" responses are very similar to the
enhanced status codes in this regard. A client which doesn't
know about them will just see them as part of the human
readable portion of the message and ignore them. Only a client
which does know about them will look for them (and potentially
confuse some random text with a structured text response).
And, of course, that possible confusion and the server knowing
whether there is any reasonable likelihood that the client will
pay attention to its requests are the argument for a client
request. Arguably, the reason why an ENHANCEDSTATUSCODES
announcement was needed at all was so that a client could know
that digits would appear at the beginning of the reply text
actually meant something and what they meant. It is not clear
to me that the same relationship applies here, especially if the
server, by making the announcement, doesn't _obligate_ itself to
use the structured information in the code. A server might want
to provide the information for some senders and not others; at
the time it sends the EHLO response, it doesn't know what the
reverse paths are going to look like. I don't know whether that
is worth the trouble or not, but it is a consideration.
That said, I was mostly talking about what would be needed if
one wanted to bind the traffic management (or whatever)
extensions to a new primary code or code, one that extends the
5321 code model. For that, one would almost certainly want
explicit "server offers"/"client requests" to avoid the risk of
the code being interpreted in some entirely different way or,
worse, having the client abandon the transaction and bounce the
message to wherever it came from because the server did
something sufficiently unexpected.
So, a new extension STRUCTUREDTEXT could be modelled after
ENHANCEDSTATUSCODES:
220 server.example ESMTP server
EHLO client.example
250-server.example Hi client.example
250-SIZE 10000000
250-ENHANCEDSTATUSCODES
250 STRUCTUREDTEXT
mail from:<me@client.example> SIZE=543210
250 2.1.0 Ok
rcpt to:<you@server.examle>
450 4.7.0 wait:55 greylisted
...
This doesn't allow the inclusion of structuredtext in the
greeting (or at least there is no way to alert the client to
its presence).
Right
Keywords also need to be defined in (standards track?) rfcs and
registered to prevent conflicting use. So maybe a generic
STRUCTUREDTEXT extension isn't a good idea after all.
Worse, while one can work the odds, nothing prevents those
things you want to define as keywords from showing with
unstructured text following a 45x reply. That is the advantage
that one gains with a client request -- independent of anything
else, it is a client acknowledgement that syntax and keywords
will be interpreted in accord with a particular specification
and registry.
Please understand that I'm not pushing any particular approach
here or in other notes in these threads; I'm just trying to
expose some of the design options, considerations, and tradeoffs.
john