--On Wednesday, 11 April, 2007 15:07 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
I honestly don't grasp the resistance. If this has all to to
do with your RFC time-line, thats one thing, but lets not try
to continue to look for reasons to not legitimize what is
really a wide practice. What is being suggested isn't breaking
ANYTHING and it has MORE value than for the future that what
is being suggested otherwise.
Let me try to explain at least one source of what you are
characterizing as "the resistance". Ignore your desired
special use of 1yz codes for the moment. We tell clients that
they are supposed to be able to take action on the codes alone
and the first digit of the codes in particular.
Suppose a particularly strange server responds to a RCPT command
with
250- I think that address is ok...
550 Whoops, never mind.
or with its symmetric relative
550- Don't think I can reach that one
250 Ah, I found a path
Now, in spite of the "you can probably just look at the last
one" recommendation in 821, there is no requirement that the
client wait for the last one before starting to set processing
up... or even getting fairly far along with it. What happens
here depends critically on whether the client picks the first
one or the last one. Worse, if one had a three-line sequences
of
550-
250-
550
or
250-
550-
250
It is even less clear what the poor client is to do.
While I cannot imagine the conditions under which a real server
would do this sort of thing, if we explicitly permit mixed-code
responses, we have to either deal with _all_ of the cases or
explicitly exclude some of them.
For example, one could fix this by saying "the codes must all be
the same unless they are non-final values starting in 1 or 0",
but that would constitute adding significant new functionality
since we have never specified an interpretation or actions for
either 1yz or 0yz codes in the past.
And _that_ is where at least some of "the resistance" is coming
from.
john