ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-01 Issue 18: Usability of 1yz replies

2007-04-11 13:16:52

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


<Prev in Thread] Current Thread [Next in Thread>