Subject: [Xml-sg-cmt] sourcecode type: abnf9110

From: Sandy Ginoza <[email-masked]>
Date: Fri, 11 Mar 2022 13:45:48 -0800

Hi all,

The httpbis documents have two ABNF sourcecode types:

abnf - sourcecode with this type can be parsed and validated by BAP.

abnf9110 (was abnf7230) - includes an extension originally defined in RFC 7230 (called #rule) and now defined in RFC-to-be 9110 <draft-ietf-httpbis-semantics>. This extension cannot be parsed by BAP, which is why the authors labeled the ABNF using this extension with the abnf9110 type.

Jean thinks abnf9110 is a legitimate sourcecode type and is useful for separating parseable and "unparseable" ABNF in HTTP documents.  

Please consider whether abnf9110 is an acceptable sourcecode type that should be added to the list <https://www.rfc-editor.org/materials/sourcecode-types.txt>.  

Thanks,
Sandy

---

From: "John R Levine" <[email-masked]>
Date: 11 Mar 2022 16:47:16 -0500

I think it's reasonable to add, and it sure would be nice if there were a 
place to put some notes explaining why it's different from regular abnf in 
case it comes up again.

> Please consider whether abnf9110 is an acceptable sourcecode type that should be added to the list <https://www.rfc-editor.org/materials/sourcecode-types.txt>.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Robert Sparks <[email-masked]>
Date: Fri, 11 Mar 2022 16:13:56 -0600

Surprised they didn't just update ABNF.

If we're doing this, do we also have abnf7405 already?

RjS

On 3/11/22 3:47 PM, John R Levine wrote:
> I think it's reasonable to add, and it sure would be nice if there 
> were a place to put some notes explaining why it's different from 
> regular abnf in case it comes up again.
>
>> abnf9110 (was abnf7230) - includes an extension originally defined in 
>> RFC 7230 (called #rule) and now defined in RFC-to-be 9110 
>> <draft-ietf-httpbis-semantics>. This extension cannot be parsed by 
>> BAP, which is why the authors labeled the ABNF using this extension 
>> with the abnf9110 type.
>>
>> Jean thinks abnf9110 is a legitimate sourcecode type and is useful 
>> for separating parseable and "unparseable" ABNF in HTTP documents.
>>
>> Please consider whether abnf9110 is an acceptable sourcecode type 
>> that should be added to the list 
>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>.
>>
>> Thanks,
>> Sandy
>
> Regards,

---

From: "John R Levine" <[email-masked]>
Date: 11 Mar 2022 18:07:02 -0500

> If we're doing this, do we also have abnf7405 already?

I think the difference is that regular abnf is supposed to include 7405.

The reason not to add the # hack is that it has a hardcoded refeence 
to an OWS rule for optional white space which is fine in http headers but 
perhaps not so fine in other contexts.

R's,
John

>>> abnf9110 (was abnf7230) - includes an extension originally defined in RFC 
>>> 7230 (called #rule) and now defined in RFC-to-be 9110 
>>> <draft-ietf-httpbis-semantics>. This extension cannot be parsed by BAP, 
>>> which is why the authors labeled the ABNF using this extension with the 
>>> abnf9110 type.
>>> 
>>> Jean thinks abnf9110 is a legitimate sourcecode type and is useful for 
>>> separating parseable and "unparseable" ABNF in HTTP documents.
>>> 
>>> Please consider whether abnf9110 is an acceptable sourcecode type that 
>>> should be added to the list

---

From: Julian Reschke <[email-masked]>
Date: Sat, 12 Mar 2022 07:05:57 +0100

Am 12.03.2022 um 00:07 schrieb John R Levine:
> The reason not to add the # hack is that it has a hardcoded refeence to
> an OWS rule for optional white space which is fine in http headers but
> ...

Exactly.

FTR, the specs use *both*; "abnf9110" inline, and "abnf" in an
auto-generated appendix.

Best regards, Julian