Tony Hansen wrote:
Tony Hansen wrote:
A MUST will support and codify current behavior. A SHOULD will not and
can not. Therefore a MUST is necessary to move 2821bis to draft standard.
<process hat on>
I'm going to declare consensus on this issue. There has been much
discussion, and not everyone is totally happy with the final
conclusions, but enough evidence has been brought forward that I am
convinced that this is the only viable way to move forward to draft
standard.
</process hat off>
When I brought up the issue, I gambled that this would be the ultimate
conclusion. I wasn't going to bring it up knowing perfectly well there
will be perfectly logically reasoning to lock this down. However, my
1st mistake was mis-reading you as I thought you were be the #1 person
who would understand the entire picture because of OPES. If this
synergy was not present, I would be 100% on board with the consensus. My
2nd mistake was underestimated how broken the few but very popular code
are which is unfortunately enough to make endorsing decisions which is
not otherwise done. Its unfair, but thats reality.
In any case, I will be happy with this if the TEXT makes it very clear
for clients to be more correct on reading its response codes.
In other words, they should FIX their code and simply stating servers
MUST send persistent reply codes regardless if they are continuation
lines or not should be coupled with clients focusing on the last
reply-code[sp text] ABNF. Otherwise, there is no point in any text
regarding multi-line parsing.
The first 3 digit in the receive buffer is
the primary response code.
Period.
This reminds me of the similar issue with the white space after the MAIL
FROM: command. An undocumented acceptable practice.
Thanks Tony (and John) for your patience.
--
HLS