Re: Use of LWSP in ABNF -- consensus call

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On May 16, 2007, at 5:19 AM, John C Klensin wrote:


Doug, John,

It seems to me that we have two separate issues here (I'm not even going to go so far as "problems"):

(1) Some documents have used the term LWSP in a way that is not strictly conformant with the definition in the ABNF document. Unless the definition is unclear, that is a problem for those documents -- and the review and approval process that permitted them to slip through with non-conforming definitions -- and not for the ABNF spec. It seems to me we fix that by changing those documents to use different production names with local definitions, not by deprecating features of ABNF.

This is not deprecating a "feature" of ABNF other than deprecating a specific, confusing, and ill-advised mnemonic found in a pre-defined macro library. As this construct is often ill-advised, there is little justification for it to be included in the ABNF pre-defined macro library. This change does not preclude any construct, it only affects ease of use. This should invoke greater care and forethought.

(2) What I learned back when I was doing definitional work for programming languages was that one wants one's basic syntax and syntactic metalanguages to be as simple as possible, with a minimum of macro constructions and with a minimum of defined terminals.

From that point of view, it is easy to argue that ABNF has just gotten too complex, both as the result of trying to formalize some characteristics of 822 while maintaining a single-pass syntax evaluator and possibly as a second-system effect.

While it is a poor craftsman who blames his tools, it is also difficult to justify standardizing a macro construct proven often to be problematic. When an author is looking for a macro, this construct and mnemonic should not be within a pre-defined macro library. Exclusion of LWSP does not represent any hardship.

That, however, is an argument that ABNF itself is broken and should not be on the standards track. It is not an argument for trying to fine-tune it by deprecating a production or two. The "broken" argument itself was made by a few of us back when RFC 2234 was being evaluated. We lost and, at this point, it would take a lot more than one sometimes-misused construction to justify tampering with it, even to the extent of selectively deprecating features.

Although ABNF limitations might lead to sub-optimal syntax, how does it prevent optimal syntax from being defined? This change does not tamper with the ABNF language. It only deprecates a pre-defined macro proven problematic and encumbered with differing definitions. Any future draft will not find the lack of this macro definition to represent any type of hardship. Those reading IETF drafts however will find whatever replaces this macro will be specifically defined where security concerns are more likely to have been given greater consideration. Whatever macro then commonly replaces LWSP could be given a different mnemonic and added to a subsequent version of this draft.

-Doug






_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]