John C Klensin wrote:
[blank line in ABNF]
fixing this sort of thing can also be left for the RFC Editor
I think syntax errors in the ABNF have to be fixed before the
IESG review, otherwise it would get a [DISCUSS]. At least that
was how it was handled for RFC 4646. And for RFC 4647 even an
"ABNF-like" comment in the prose got a [DISCUSS], because it
wasn't consistent with two similar ABNF literals in this memo
(bad %2A vs. good %x2A).
Could you publish the xml source for the drafts ? It's simple
to catch ABNF typos if you use <figure><artwork type="abnf">
and a global <?rfc strict="yes" ?> directive.
There's a subtle LWSP issue in the core ABNF: If the apparently
empty line in your <address-literal> is really empty, then it's
an error, Bill's parser says:
| 2:0: error: state 68, token CRLF: parse error, unexpected CRLF
If the apparently empty line contains trailing white space it
is okay, and Bill's parser says "No errors during parsing."
Some folks thought that promoting 2821 to DS is a short trip,
and "somebody else" thought that promoting 4234 to STD is a mere
formality. What really happened is that another person had to
write a new 4234 interop report (admittedly the old 2234 report
was a bit odd :-), the assumption that there are no 4234 errata
was wrong (the huge "pending errata mbox" contained something),
and now some months later there's a fresh 4234bis-00.
At least it's an opportunity to add a warning about LSWP to the
ABNF security considerations, this already hurt DKIM and 2831bis:
<http://permalink.gmane.org/gmane.ietf.general/24801>
Frank