Re: Use of LWSP in ABNF -- consensus call

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf