(this is drifting off-topic enough that I changed the subject
line)
--On Saturday, October 29, 2011 16:21 -0700 "Carl S. Gutekunst"
<csg(_at_)alameth(_dot_)org> wrote:
John C Klensin wrote:
Before we try anything like that, we need actual feature
negotiation (not just announcements), which ESMTP lacks.
Without debating where "actual feature negotiation" starts, it
seems to me that
-- Server announces that it can supply extra reply code
information for traffic flow control
-- Client announces, via an extension argument to MAIL
or RCPT (or, in principle, via a new verb) that is it
willing to accept such codes.
-- Server uses the code iff both announcements have
occurred.
would be perfectly adequate to permit support for, e.g., 6yz
or x7z codes.
Agreed. In referring to "feature negotiation," I was actually
thinking of a new verb, since the extension would be enabled
for the entire session, not just one message; and I'm already
feeling some pain over MAIL FROM parsing. (Don't ask.) What
matters most though, IMHO, is a precedent for the next
extension that needs the same "Server Has"/"Client Wants"
interchange. That's actually something I've wished for for a
long time, and I suspect most of us have implemented privately
many times over.
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). But the original extension design specifically provided
for "eerver offers"/"client sends new verb" precisely because we
anticipated situations in which (i) adding [more] arguments to
existing verbs would be problematic (e.g., BDAT and ETRN) and
(ii) in which the option would be effective per-session rather
than per-mail-transaction. Precedent for the latter exists
already in e.g., AUTH and its friends. So, other than a large
collection of non-security examples, I'm not sure what you need
in terms of either mechanisms or precedents that you don't have
already.
Now, if what you really want as feature negotiation is a verb
that would supply a client capabilities list to parallel the
server capabilities list in EHLO, with some set of rules about,
e.g., picking the intersection, it is certainly possible under
the model. You would get pushback from some of us on the
grounds of complexity and additional complications in
multiple-relay environments (read the introduction to RFC 1425),
but that is another matter.
best,
john