On Tue March 15 2005 10:01, Internet-Drafts@xxxxxxxx wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Augmented BNF for Syntax Specifications: ABNF
> Author(s) : D. Crocker, P. Overell
> Filename : draft-crocker-abnf-rfc2234bis-00.txt
> Pages : 15
> Date : 2005-3-10
Comments:
Section 1, first paragraph, first sentences refers to "format syntax".
Should that be "formal syntax"?
Same section and paragraph refers to RFCs 733 and 822 as "email
specifications". Technically, both are message format specifications
(email also includes transport protocol specifications).
The first paragraph after "Changes in the latest version" includes two
non-ASCII octets. In the same paragraph, "correct" should be
"corrected".
Section 2.2 (and section 4 definitions of c-nl and comment) refer to
crlf line endings. However, Internet-Drafts and RFCs which specify ABNF
in fact have newline line endings (no CR), as can be verified by
retrieval from the IETF ftp site using IMAGE (a.k.a. binary) transfer
mode. Technically, to correspond to that actual use, crlf
(case-insensitive) should be replaced with LF in those places (while
retaining the definition of CRLF in the core rules). To accommodate
local end-of-line conventions including CR by ABNF parsers, it might be
desirable to instead change crlf to ([CR]LF).
Also in section 2.2, "end-of- line" should be "end-of-line".
In the section 2.3 phrase "ABNF permits specifying literal text string
directly", "string" should be "strings".
There is an extraneous extra period after the last sentence of the note
in section 3.2.
An extraneous space appears before the word "independent" in section
3.3.
In section 3.4, to avoid confusion, "end of line" should be "CRLF".
One rule in the section 4 definition of ABNF causes serious ambiguities:
rulelist = 1*( rule / (*c-wsp c-nl) )
That permits comment-only lines which are part of the rulelist, but not
affiliated with a specific rule. That itself is not a concern.
However, it permits a rulelist such as:
; stand-alone comment
; another stand-alone comment
first-rule = foo
; comment intended to be associated with first-rule
; comment intended to be stand-alone
second-rule = bar
One problem is that the provision for leading whitespace in a
stand-alone comment in conjunction with the section 2.2 (last paragraph)
indentation rules ("left alignment and indentation are relative to the
first lines") introduces an ambiguity regarding the amount of
indentation.
A second issue is the ambiguity regarding both comments which appear
between the two rules in the example above. One cannot determine
whether the first comment matches the second alternative in the rulelist
production (and is therefore a stand-alone comment), or if it is
comprised of *c-wsp from the end of the "elements" production in the
first rule, followed by the c-nl production which is an integral part of
the "rule" production (and therefore is part of the first rule). If the
first of those comments is stand-alone, then the second must also be
stand-alone. However, if the first is part of the frst rule, the second
might or might not be stand-alone -- the ambiguity continues.
Both problems can be avoided by requiring stand-alone comments to have
no (extra) leading whitespace:
rulelist = 1*( rule / c-nl )
In that case, the example above would have to be revised as:
; stand-alone comment
; another stand-alone comment
first-rule = foo
; comment intended to be associated with first-rule
; comment intended to be stand-alone
second-rule = bar
And the ambiguities are thus removed.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf