Re: [abnf-discuss] defining "compatible" extensions

> The main issue I have whenever this sort of thing come up is that ABNF
> is there to specify syntax, not semantics.  The ABNF in 4566 correctly
> says that the syntax of an att-name is that it's a token.  The
> specification itself -- the rest of it, beyond the ABNF -- is there to
> tell us what values to expect there, what to do with them, and how to
> define extensions.

I could not agree more. As things edge away from syntax and closer to
semantics, ABNF stops being the right tool for the job.

For heaven's sake, ABNF can't even handle things like complex ordering or "at
most two of" that really can be viewed as part of the syntax. And people expect
it to handle even higher level constructs that overlap existing syntax in
complex ways? Please.

Which is not to say these sort of things can't be handled cleanly. A good
example is RFC 5322 section 3.6.

But complex overlapped syntaxes? My response to that is, "Just say no!"

There was a bunch of this junk in RFC 1341 and RFC 1521, the early versions of
MIME. When I did the RFC 2045/2046 revision, I summarily deleted all of it. And
AFAIK it has not been missed. Indeed, if the number and type of questions I
received was any indication it has resulted in less confusion overall.

This doesn't mean you can't specify higher level constraints on top of existing
sytnax. You can, you just don't use ABNF to do it. A good example where this
was done are the various extensions to Sieve. Sieve has a simple stable
syntax specified in RFC 5228. Many extensions have been defined, most recently
draft-ietf-appsawg-sieve-duplicate-09, but a different format is used to
specify the syntactic constraints on extensions. The one in the most recent
draft is:

Usage: "duplicate" [":handle" <handle: string>]
                      [":header" <header-name: string> /
                          ":uniqueid" <value: string>]
                      [":seconds" <timeout: number>] [":last"]

There are also limited - very limited IMO - cases where overlapped syntaxes are
OK. Although it's fairly rare, this sometimes happens with media type
parameters. I don't have a problem with media type parameter syntax being
specifed in ABNF. But we're talking about adding constraints to a single token,
not a complex overlay.

And finally, there are cases where fully extensible syntaxes make sense, at
least in the context of previous design decisions. The obvious example of this
is IMAP, where extensions add commands and specify their syntax when they do.
This seems to be worked out OK. (Personally, I'm not entirely happy with the
approach taken in the base specification to syntax specification, but it's very
small beer compared to other issues in the IMAP space.)

> That many specs enumerate all the tokens that are valid at the time of
> their writing isn't really relevant to this, as I see it.  Personally,
> I think we should stop doing that *unless* we want to define something
> that intentionally has no extensibility.  To me, this makes sense:

>    florb-value = "true" / "false"

> ...while this does not:

>    florb-value = "true" / "false" / florb-ext
>    florb-ext = token

I agree; this gets close to the line if edging over it.

> The first is clearly saying that *syntactically*, there are only two
> things that can appear in a florb-value.  You can safely write a
> parser that looks for those and throws a syntax error if it sees
> anything else.

> What on Earth is the second saying, syntactically?  I'd better write
> my parser to parse it as a token.  I presume there's something else in
> the text that tells me what to do with "true" and "false"
> semantically, and that explains the extensibility.  What's the point
> of having that in the *syntax*?

> This sort of thing is also fine, as I see it:

>    florb-value = token ; must be a registered item, as
>                        ; defined in Section 3.2.1

> Here we're using a comment in the syntax to point the reader to the
> section that gives the semantics and explains the valid value.
> References are good.

> Twisting syntax specification around to try to make it go beyond
> syntax is not good.

> Clearly, opinions differ on this... but there's mine.

The "code" I've "run" in this space says pretty clearly that complex
overlapped syntaxes cause more problems than they solve. And I really
don't think adding intersection capabilities to ABNF is a solution.

				Ned

_______________________________________________
abnf-discuss mailing list
abnf-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/abnf-discuss