--On Monday, 23 April, 2007 17:59 -0400 Tony Hansen
<tony(_at_)att(_dot_)com> wrote:
<process hat on>
Can we please stop this? You are both right. The spec is
inconsistent, and depending on how you interpret it, you get
different answers. No, the code is not broken. Yes, the code
is broken.
Our job here is make the spec better. Let's stop blaming
people, their code or how they interpreted the spec. Casting
aspersions helps no one. Instead, let's put the blame where it
truly lies: on shortcomings in the spec. And then let's work
on fixing that spec to eliminate the inconsistencies.
</process hat off>
<spec writer hat on>
Section 4.2 clearly says that a server response may be single
line or multiline, and all commands are expected to be able to
receive either one. It then goes on to define (in the text and
ABNF) the format of the single line response, and punts to
section 4.2.1 for the definition of the multiline format.
Unfortunately, section 4.2.1 only uses a textual description
for the multiline response and does NOT give the corresponding
ABNF to match.
There are several ways of remedying this. The suggestion below
to augment the ABNF in section 4.2 is a perfectly reasonable
way to do it.
</spec writer hat off>
<befuddled editor hat on>
Assuming that, by "the suggestion below", you meant
Reply-line = *( Reply-code "-" [ text ] CRLF ) /
Reply-code [ SP text ] CRLF
Reply-code = %x31-35 %x30-35 %x30-39
that change is consistent with what is already in rfc2821bis-02.
I have a note in my file that says that Frank, and possibly
others, have noted that "text" is not completely defined in
2821, but I assume that will be straightened out in the ABNF
cleanup pass.
If that is not what you intend, please say so.
</befuddled editor hat off>
john