--On Tuesday, 15 May, 2007 16:00 -0700 Douglas Otis
<dotis@xxxxxxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf