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

[Sean Leonard <[e-mail]>]

> On Nov 14, 2016, at 2:12 PM, Julian Reschke <[e-mail]> wrote:
> 
> 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.

Okay.

>> 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.


Sounds like we have a plan for progress then.


Regarding the other stuff:

> 
>> 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?

In some scenarios (namely if the author wants), it is nice to determine that all rules in a specification are reachable from some starting rule. This can help to identify and eliminate orphan rules that are no longer used by the spec. Of course, that is just if the author wants.

> 
>> 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
> 

Yes. In this example, I would say that the “message ABNF” can have a header-line that conforms with the generic syntax, but does not conform with the particular field-name -> field-value production. This should not be a fatal error, in the sense that the (HTTP) message is unusable; but merely that particular field cannot be used. (The actual behavior is up to whatever spec.) I think we are on the same page here...

Overall, for document authors, it helps for a tool to check that the subordinate rule (constrained rule) is purely a subset of the generic rule. For development/debugging/testing/analysis of data on-the-wire, it helps for a single ABNF spec to be used to check the generic data (generic rule) as well as the specific data (constrained rule) in one swoop, without much additional coding to glue the two together.

Regards,

Sean