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