--On Tuesday, 24 April, 2007 15:15 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
John C Klensin wrote:
This is another example of why I'm getting cold feet about
doing a significant ABNF overhaul. The advantage of
"Reply-line" over "reply" is that the former is easily found
by searching the text, while "reply" is used all over the
...
either of which I think is more clear because they are less
subtle. But, probably fortunately, we are not.
Ha! True, true. :-)
But poor developers, who have to look at all this and say:
"HUH? What does that all mean? All I want is the
server response code!"
The bottom line translation from ALL of this and related
issues is:
- The server command response code is the first 3 digits of
the
receiver buffer. These 3 digits MUST be numeric, 0 thru
9.
- The response is terminated when the there is no
continuation
character "-" at byte #4
I'd say there is a different lesson in this, which is that, for
specifications of the lineage that includes 821 and 2821, the
formal syntax is a supplement to, not a substitute for, the
restrictions, discussion, and semantics in the text. I would
suggest that is generally true for IETF specifications and for
specifications that use ABNF in particular: one can push the
line of what is specified/ restricted in syntax a bit in either
direction but, ultimately, ABNF (and most metalanguages like it)
cannot express semantics or conditional relationships in the
syntax... pretending otherwise doesn't get us very far although
it may lead to making the syntax sufficiently obscure in the
hope of being very precise that people's eyes glaze over.
This is how the broken codes out there are reading it and some
even consider this a high-quality, low overhead, optimized
streaming parser!
I think that is a mistake. And I think that putting ABNF
through an automated parser generator for any purpose other than
consistency-checking is a mistake too. Just my opinion, of
course.
So how is this written in ABNF style?
Reply-line = Terminating-Reply-Line | 1*
Non-Terminating-Reply-Line
Terminating-Reply-Line = Reply-Code [SP text] CRLF
Non-Terminating-Reply-Line = Reply-Code "-" [text] CRLF
Reply-code = %x31-35 %x30-35 %x30-39
Unfortunately, this proves my point. Note that
(i) Your discussion above says "numeric, 0 through 9". The
system you correctly copied from 2821 or 2821bis through -02
says "numeric, first digit must be 1 through 5, second digit 0
through 5, third digit 0 through 9". And 2821bis-03 is just
like that except it says "first digit 2 though 5" ( %x32-35).
Worse, I think that is wrong because the flexibility that is now
in 2821bis --more restrictive than the flexibility that appears
in 2821, but close-- may be too much: while 821 -> 2821 don't
supply meanings for x6z, x7z, etc., the "go to the first digit
if you don't understand the whole code" rule is more than
sufficient to permit interoperability if an application needs,
e.g., 561. Inventing 561 today would violate a "SHOULD" about
using extended codes rather than making up more codes in the
three-digit series but, unless someone can somehow demonstrate
that the are no uses of such codes out there (I actually know
some, but they are/were in SMTP-clones on non-TCP transports,
not in SMTP), I think that quietly restricting the range of the
second digit in syntax with no comments in the text is a bad
idea.
(ii) The syntax you have given might permit
250 terminating line
250-non-terminating line 1
250-non-terminating line 2
which is exactly backwards. And it would definitely permit
250-non-terminating line
250-non-terminating line 1
250-non-terminating line 2
with no terminating line at all.
No problem, except as an illustration that this is not as easy
to get right as we often assume.
Quickly followed with a very strong normative text that says:
The reply-code in each reply-line MUST be persistent (the
same).
I hope that is clear now; please check -03 when it is posted and
suggest either text or reorganizations if you think they are
necessary after doing so.
john