John C Klensin wrote:
I've assigned Issue 17 to the question of whether, if reply
lines constitute a continuation set, all of the codes are
expected to be the same and whether this needs clarification.
It appears that there are three options:
(i) Do nothing, leaving the text as is
(ii) Make it clear that the codes may be different and
that clients are expected to examine all of them.
(iii) Prohibit different codes and, optionally, suggest
that it is ok for a client to select one of them and
assume that all of the others are the same.
If we select (ii), we may need to make a statement about which
of the codes is the "final" one with regard to client actions,
especially if the first digits are different.
Note that this may (or may not) have an impact on various
proposals for delayed responses to RCPT, so any new text that
goes in may need explicit provisions for extensions changing the
rules.
<former opes chair hat on>
The proposed use of 1xy in the example seen the other day
150-Please Wait...
150-Please Wait...
451 Sorry, Rejected, try again later
is in the spirit of the use of 1xy, but also technically incorrect in
that the 1yz description says that the SMTP *client* must respond by
sending another command. But since it also had the continuation
character, the client was prevented from doing so until the command was
concluded. I think that the real reason it worked with most clients is
that it was *not* a 2yz/3yz/4yz/5yz code, putting them into the "punt"
category, and then they looked at the last line to determine the actual
code to believe.
The OPES team looked long and hard for a way to break out of the timeout
situation and the "150-" situation really was the best solution to get
proposed, and it actually seemed to work with current existing servers.
I'm not suggesting that this use be blessed within 2821bis. However, I
could easily see an extension I-D being written that defines and blesses
its usage. So I wouldn't want to deny its possibility within 2821bis. I
guess I'm falling into the (ii) camp here.
This actually brings up the question in my mind: how do different
servers today actually behave when faced with multiline responses that
have different values?
</former opes chair hat on>
Tony Hansen
tony(_at_)att(_dot_)com