Date: Tue, 02 Jul 2002 19:39:46 -0700
From: Dave Crocker <dcrocker@brandenburg.com>
Message-ID: <5.1.1.2.2.20020702193306.03284c00@jay.songbird.com>
| Keith, your term "overloading" suggests that RCPT-TO parameters are being
| invented here. They aren't.
First, let me say that I haven't read the draft, and don't intend to.
So, if you want to ignore my comments (questions really) feel free.
But from what I have picked up from the (smallish) number of messages
from an even smaller set of people (no great surprise, fax is dead
technology, who cares???) on the ietf list in the past day or so, I
surmise that this protocol work something like the following.
Note: I am not asking for education, I don't care, but if I have
guessed incorrectly, all the relevant parties may want to assure
themselves that there is very good reason for why my assumptions
about how this is intended to work aren't what was adopted.
It sounds as if what is being proposed is that the SMTP client
sends
RCPT TO:<address> "I want 1200 dpi"
(I have no idea what kind of capabilities are able to be negotiated
here, nor does it matter).
Then the SMTP server says
250 OK
which must mean that the capability requested is fine (as is the
address, as best it was verified at this stage), or the SMTP server
sends
567 "Best I can do is 600 dpi"
with a 5xx reply code which was not defined before, so the client
knows that the problem is with the negotiation, and can then parse the
error text to determine what is possible. Since this is a 5xx error
code, the address listed will not be included in the set of addresses
to which the message will be sent.
Or, the server does
467 "Best I can do, right now, is 600 dpi"
which is essentially the same as before, except, as with all 4xx codes,
suggests to the client that if it want to try again later, the capability
it requested just might be available.
Upon receiving a 5xx or 4xx reply of this kind, the client has several
choices, it can bounce (or queue for retry in the 4xx case) the message.
It can decide to take the 600 dpi, and send the RCPT To again, using the
same address, but now with the capability requesting only what the
server says it could offer (and then in the DATA, use no more than the
smallest capability it requested on any RCPT TO - downgrading any earlier
ones - of course, this works only if capabilities exist in a strict
hierarchy, but as people have been talking about downgrading, I assume
that's OK).
Or it can just defer the recipients that failed, send the message to any
that were accepted by the server, and then start again with a new MAIL and
send a separate message to the recipients that failed (because of capability
negotiation) the first time through. This time, the responses that were
received the first time can be used to guide the selection of capabilities
so usually, nothing should fail (the client may break the set of remaining
recipients into groups that should all work together, if it desires, or
just pick the set of capabilities that will allow all of them to work).
If this is how it works, I don't understand why people are talking about
doing RSET? Surely the protocol isn't built in a way where the server
says "no" to a request, and yet still includes the address in its list
of recipients. That would be such a brain damaged perversion of all
that SMTP has ever been that I can't imagine it could ever have gotten as
far as IETF last call.
If I'm right about how the protocol works, then it would seem that it
should come pretty close to satisfying everyone who has expressed an
opinion that I have seen.
Keith's operational plan can be done by sending RCPT TO (where he would
send RCAP) and terminating the sequence with RSET. This way the RCPT
TO acts just as the RCAP would act in his model (as I understand it).
Sure, it isn't as clean by any means, and makes the server do a little
extra work, as it doesn't know the RCPT TO's aren't real ones when it
receives them, but as a trade off, it seems OK.
Others who prefer just to send and see what arrives, just do that, and
it all works the way they expect, with down grading, so the data only
ever needs to be sent once, or with separation of capabilities in the
cases (I am guessing this probably doesn't happen often, and most times
a server will offer the same capabilities to all addresses it can handle?)
So, why is there a big argument here?
kre