Dave,
On Tue, 15 Feb 2005 10:22:41 -0800, Dave Crocker wrote:
Folks,
It's too late to submit the ABNF revision as an I-D, until after
Minneapolis, but here is a pointer to the revision:
[...]
; <http://bbiw.net/specifications/draft-crocker-abnf-rfc2234bis-02dc.txt>
[...]
I believe ABNF is done, which is to say that it is ready for Draft.
1. The revised spec is at the above location, obviously needing formal i-d
submission after this week.
Don't forget to update the filename in the title area (it refers to
-00<mumble> rather than 02<mumble>) and the dates (more than a year
ago).
2. All of the outstanding items, concerning the document, pertain to
enhancements, rather than to 'fixing bugs in the spec'. Although most or
all of the enhancements are reasonable, they would require re-cycling at
Proposed. In response to my queries about whether to recycle vs. go to
draft, the overwhelming preference, is for moving to Draft. Hence, no
enhancements to abnf have been done.
There are at least two genuine bugs:
1. ABNF lines need not use CRLF line endings (in fact the canonical
versions of I-Ds and RFCs at ISI.EDU do not). I.e., *none* of
the approved ABNF in use meets the ABNF ABNF CR requirement.
2. There is an unresolved ambiguity regarding comments beginning
with whitespace, but unassociated with any rule; consider:
a = b ; comment
; comment continues
c = d
vs.
a = b ; comment
; supposedly unrelated comment matching rulelist production
c = d
vs.
a = b ; comment
; comment unrelated to any specific rule
c = d
The ambiguity can be resolved by requiring comments unassociated
with any rule to have no whitespace preceding the semicolon.
I strongly suspect that the reason that at least two implementations
have failed to recognize %B, %D, and %X is that the prose in section
2.3 implies only lower-case letters after the percent sign, whereas
the ABNF ABNF (tucked away in a late section) denotes otherwise (but
only upon referring back to a separate paragraph of 2.3 discussing
case-insensitivity of quoted strings). While that's not a bug per se,
it's an editorial issue that - in light of implementation experience -
probably ought to be addressed.
Whether the bugs and editorial issue are addressed before submission
as an I-D, after I-D announcement but prior to first Last Call, or
after Last Call (and probably requiring a New Last Call) is, of
course, your choice.
Best regards,
Bruce Lilly