John,
Our field experience has shown is there are 3 types of clients in how it
deals with multi-line mixed response codes:
1) Uses the first line code and ASSUMES it will be the same for
subsequent lines and the final line.
2) Use the first and the last and compares the two as a quick
"Integrity Checker" - again, with the assumption that all
are the same
3) Use the final line only.
By far, the majority have a logic #3. However as Tony Hansen pointed
out, it could be that they are ignorant of 150- hence why it works to
keep clients alive.
My vote is (ii).
This is my rough suggestion text to only allow 150- to be the alternate
reply-code in continuation lines.
Under most scenarios, servers SHOULD use the same reply
code for each multiline response line when it is going to
be displayed at the same time. However there are scenarios
(Keep Alive Client Timeout issues) where servers MAY use
"150-" as an alternative reply code in a continuation line
when the server needs to issue a heartbeat to keep the client
alive during unsual delayed backend processing:
Example:
352 Start your data ...
[data uploaded]
150-Processing data... please wait..
150-Processing data... please wait..
250 Message accepted
--
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.
john