--On Tuesday, 15 May, 2007 16:00 -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:
The use under RFC2530 is a bit vague ("with LWSP
wrapping"); likewise
under RFC3501 ("otherwise treat SP as being equivalent to
LWSP"). The use under RFC4646 has caused known problems.
This would seem to justify deprecation, IMHO.
Agreed.
From a standards standpoint, half a dozen definitions for an
ABNF mnemonic is absurd.
Perhaps something like:
The LWSP mnemonic has been deprecated and should not be used
in future drafts. Explicit definitions based upon different
mnemonics should be used instead. If possible, syntax should
guard against possible security concerns related to visual
deceptions.
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.
(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.
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.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf