John C Klensin wrote:
--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
No, that is illogical and that was discovered with FTP as well. You want
to use a inconsequential code that is would not be interpretation as
either negative or positive.
You need to use a code that is not typically used to interpret an
initial negative or positive condition. It would be illogical do to so.
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.
Agree. So if you don't wish to make it a normative text, then lets leave
it alone between the test of time has solidify it anyway.
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.
Doesn't apply because it wouldn't be how it be used. It needs to be an
inconsequential code not a "heads up" code that may change status as you
point out.
--
HLS