Augmented BNF for Syntax Specifications: ABNF
RFC 5234

[Ballot comment]
With this document, the author is unwilling to make any changes without
restarting the approval process (it's a matter of principal for the
author, and thus not something I want to argue about even if I might
disagree about this application of the principle).  However, a last call
comment on the LWSP issue was not addressed and we are concerned about
that issue.  As this is an otherwise mature specification with
significant community benefit from prompt publication, I suggest this
is a perfect case for an IESG Note.  Here's proposed text:

IESG Note

The IESG has observed widespread use of ABNF in many RFCs with
a significant level of implementation, successful operational
experience and a high degree of technical maturity suitable for a
Internet Standard.  However, one inconsistency was noticed late enough
in the standards process that the community is best served by noting
the issue here without delaying this specification.  The LWSP rule in
appendix B.1 is not compatible with the FWS rule in RFC 2822 and there
have been at least two instances where LWSP was mistakenly used when
FWS was intended.  The IESG cautions ABNF authors to avoid use
of LWSP in email headers and carefully consider whether it is
appropriate to permit whitespace-only folded lines in other contexts
prior to use of that rule.

[Ballot comment]
I think this needs an interoperability report to progress - I have provided one below. As grouping is a functor not operator, I dont' see the unresolved but as being meaningful.  To put it another way, I don't see how to construct a grammar that wold be interpreted differently based on the fix in the reported precedence bug.


---------------------------------------------------------
Interoperability report for 4234 

Several independent implementation of SIP have used the ABNF in 3261 and successfully implement the same grammar as evidenced by the ability to generate and parse messages from other implementations. The following interoperability is based on the open source sip stack at resiprocate.org and Cisco IOS GWs running SIP.

The ABNF in 3261 uses

terminal values

strings

ranges

comments

alternates

sequence groups

variable repetition

optional sequences

specific repetitions

concatenation

ABNF is in widespread use in many specification that are used in the internet and seem to produce implementations that interoperate. I believe the degree of technical maturity is evidenced by the number of RFC that use this.

[Ballot discuss]
There are two "unverified" errata listed for RFC 4234 from the same source.  One of the errata
is corrected in 4234bis, the other was not addressed.  I do not know if the second is correct or
not, but want to be sure the authors are aware of it.  It seems bad form to progress without
addressing the errata.

From the Introduction: "This latest version has only minor changes, based on experience with
[RFC4234]."  This forces the reader to hold the two versions to the light to determine what
those changes were!  There should be a list, or the text should note they are only typos, etc.

Finally, there is an unresolved comment from Frank Ellerman on the IETF list (April 24).  He
also proposed text to address the LWSP issue.  While I disagree with his proposal to address
it in the Security Considerations section, it seems that a note describing when and where LWSP
is appropriate is in order.  Otherwise, we are promoting this specification *knowing* that we
don't always want authors to follow it!

[Ballot discuss]
There are two "unverified" errata listed for RFC 4234 from the same source.  One of the errata
is corrected in 4234bis, the other was not addressed.  I do not know if the second is correct or
not, but want to be sure the authors are aware of it.  It seems bad form to progress without addressing the errata.

From the Introduction: "This latest version has only minor changes, based on experience with
[RFC4234]."  This forces the reader to hold the two versions to the light to determine what
those changes were!  There should be a list, or the text should note they are only typos, etc.

Finally, there is an unresolved comment from Frank Ellerman on the IETF list (April 24).  He
also proposed text to address the LWSP issue.  While I disagree with his proposal to address
it in the Security Considerations section, it seems that a note describing when and where LWSP
is appropriate is in order.  Otherwise, we are promoting this specification *knowing* that we
don't always want authors to follow it!

[Ballot discuss]
There are two "unverified" errata listed for RFC 4234 from the same source.  One of this errata is corrected in 4234bis, the other was not addressed.  I do not know if the other is correct or not, but want to be sure the authors are aware of it.  It seems bad form to prgress without addressing the errata.

From the Introduction: "This latest version has only minor changes, based on experience with [RFC4234]."  This forces the reader to hold the two versions to the light to determine what
those changes were!  There should be a list, or the text should note they are only typos, etc.

Finally, there is an unresolved comment from Frank Ellerman on the IETF list (April 24).  He
also proposed text to address the LWSP issue.  While I disagree with his proposal to address
it in the Security Considerations section, it seems that a note describing when and where LWSP
is appropriate is in order.  Otherwise, we are promoting this specification *knowing* that we
don't always want authors to follow it!

[Ballot comment]
I would suggest that Lisa enters in the tracker information that documents the 'significant level of implementation and succesful operational experience' with RFC 4234 as well as the 'high degree of technical maturity' that justifies the advancement from Draft to Full Standard. The quotes are from RFC2026.

Dan

[Ballot comment]
The document would be improved if the LWSP rule was removed from the core rules appendix or replaced with the "FWS" rule from RFC 2822 (minus obsolete syntax).  The version of LWSP in this specification is inconsistent with FWS in RFC 2822 where the explicit IETF concensus to deprecate folded lines containing only whitespace was made to improve interoperability.

[Ballot discuss]
The document would be improved if the LWSP rule was removed from the core rules appendix or replaced with the "FWS" rule from RFC 2822 (minus obsolete syntax).  The version of LWSP in this specification is inconsistent with FWS in RFC 2822 where the explicit IETF concensus to deprecate folded lines containing only whitespace was made to improve interoperability.

I will clear this discuss when I hear back from the author either "good idea" or "I think this is OK because ...", but I want the issue discussed.

This has ALREADY been through AD review and IETF Last call, but went through those steps as RFC4234 -- look up the history in the draft tracker for RFC4234.  See also  for implementation report.