Re: [abnf-discuss] constrained-01 - advantage?

[Paul Kyzivat <[e-mail]>]

On 11/13/16 4:38 PM, Doug Royer wrote:
>
> It has been over 30 years since I have taken any math classes.

I have you beat - 50 years for me.

> The
> introduction sections were a bit difficult to follow. I would suggest
> simplification.
>
>   ---------------------------------------------------------
>
> How is:
>
>  resent-field    = "Resent-" field-name ":" unstructured CRLF
>
>  resent-date   ^ resent-field = "Resent-Date:" date-time CRLF
>
>  resent-from   ^ resent-field = "Resent-From:" mailbox-list CRLF
>
>  resent-sender ^ resent-field = "Resent-Sender:" mailbox CRLF
>
>  ...
>
> Simpler or more of an advantage than:
>
>  resent-field  = resent-unstructured / resent-date / resent-from /
> resent-sender / ...
>
>  resent-unstructured = "Resent-" field-name ":" unstructured CRLF
>
>  resent-date         = "Resent-Date:" date-time CRLF
>
>  resent-from         = "Resent-From:" mailbox-list CRLF
>
>  resent-sender       = "Resent-Sender:" mailbox CRLF
>
>  ...

The latter is what is commonly used now for extensible fields. When 
extensions are done in separate drafts it becomes:

    resent-field = <defined in RFCnnn>
    resent-field =/ "Resent-Flag:" flag CRLF

With extensions allowed in separate drafts there is usually a rule that 
anything matching resent-unstructured and not one of the other 
alternatives is to be ignored. (This makes extensibility with backward 
compatibility work.)

But this only works if every extension matches resent-unstructured. But 
when using this form there is no validation that they do. I have 
reviewed extensions of this sort that I discovered did not match in this 
way. And often the ABNF isn't reviewed carefully enough to guarantee 
that such things will be noticed.

What the proposal does is ensure that the compatibility is verified by 
the ABNF parser.

	Thanks,
	Paul