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

[Julian Reschke <[e-mail]>]

On 2016-11-14 05:55, Sean Leonard wrote:
> ...
>> See how RFC 7230 distinguishes between parsing the HTTP message info fields and field values, and then has completely *separate* ABNFs for each field value.
>
> Yes, I saw that. It is a difference approach to the “mail standards” approach, which uses a lot of / and =/ and extension-header syntaxes.

And RFC 2616 did that as well - it's just that we (that is the HTTPbis 
WG) decided that this use of ABNF isn't helpful -- IMHO the structure of 
the ABNF should be aligned with how messages are parsed; so this change 
in RFC 723x reflects that reality.

> A disadvantage of the RFC 7230 approach is that the relationship between the generic header production and specific headers is not formalized. For example, 7230 says:
>
>    HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
>     ]
>
>    header-field = field-name ":" OWS field-value OWS
>
>    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
>     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
>     comment ] ) ] )

Can you clarify why that is a problem?

> All that is very interesting, but if you want to verify that the ABNF is correct (or if you want to verify that sample HTTP messages conform to the ABNF), you have to do extra steps to extract each header-field and match them to the particular field values.

There are two questions here.

- if you want the validity of the message itself, you check the message ABNF

- if you want to check the validity of a given field value, you check 
the field value against the field's ABNF


> It is desirable to express the relationship between the <Via> production, and the <field-name> “Via”. Specifically, when <field-name> is “Via”, then <field-value> is <Via>.

Yes, I wouldn't be opposed to a mechanism that just deals with that.

> A recent place where this leads to a protocol problem is the PKCS #11 URI scheme. RFC 7512 says that “|” can appear in <pk11-query-res-avail>, as a delimiter to some command-path. But “|” is not a part of URIs under [RFC3986]. Therefore, any [RFC3986] conforming URI parser is going to reject what RFC 7512 says are valid pkcs11: URIs. If the relationship between URI@[RFC3986] and pk11-URI@[RFC7512] could have been expressed formally (namely that pk11-URI is a subset of URI), then a validator could have easily flagged that problem during the editorial process.

I believe that's a much better example to use.

Best regards, Julian