[Top] [All Lists]

Re: deferred RCPT responses

2004-04-03 15:15:53

On 4/3/2004 12:23 PM, John C Klensin wrote:

Actually, yes it is, especially given operational experience
with clients that won't even accept a multiline response in that
situation but are sure that the only possible responses are:

Why would the client negotiate an extension it couldn't handle? Of course,
that applies to almost of the potential response models, so as far as that
goes, any of them will be fine if whatever does get chosen is clearly
defined and requires negotiation--if they all suck then its just a matter
of which form of suckiness do we want right.

The thing I like about 353/.../250 is that it leaves the intermediary
response codes clean and transparent, while all of the others result in
semantic difficulties ("250-550" is confusing as heck, while "250-2.1.5"
is non-conformant) or break other parts of the model ("250-"/"550-"), and
is why I used it in the draft last week.

At this point the whole thing is mostly an intellectual exercise. The best
solution is what I pondered in the original message--put it off until a
replacement service is developed that can handle this kind of stuff from
the beginning.

Eric A. Hall                              
Internet Core Protocols

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