Thanks for this. Very good points. Also, did we inadvertently rule out "example0_1foo"? I don't think that was intentional.
-andy, no hats On 8/16/26 9:13 PM, Jasdip Singh wrote: > Hi, > > Based on further review of the latest draft, wanted to share few observations: > > ABNF > ——— > > In section 2.2 (Syntax), we altered the ABNF for “name” from section 6 > (Extensibility) of RFC 7480 [1]. > > From: > > name = ALPHA *( ALPHA / DIGIT / "_" ) > > To: > > /name = ALPHA *( ALPHA / DIGIT )/ > > IMO, the new ABNF is not right since the original ABNF is intended for > production of JSON names and is still correct. > > That said, I like the idea of having a formal ABNF for extension identifiers > that excludes the problematic underscore (“_”) character. So, instead of > touching the “name” ABNF from RFC 7480, would propose introducing the > following new ABNF in section 2.2: > > extension-identifier = ALPHA *( ALPHA / DIGIT ) > > Furthermore, we have now added: > > /The syntax for extension elements (JSON member, query parameters, object > class name, HTTP headers, path segments, media type parameter, etc.) is > defined by the "extension-element" ABNF rule:/ > / > / > / extension-element = name "_" ALPHA *( ALPHA / DIGIT / "_” )/ > > I evaluated the "extension-element" ABNF and came to conclusion that it is > quite problematic. Please allow me to explain: > > extension-element, especially the suffix ALPHA *( ALPHA / DIGIT / "_” ), if > used for a path segment would severely limit path segment charset from > section 3.3 of RFC 3986 [2]. > > extension-element, especially the suffix ALPHA *( ALPHA / DIGIT / "_” ), if > used for an object class name would violate the JSON String character set > from section 7 of RFC 8259 [3]. > > extension-element, especially the suffix ALPHA *( ALPHA / DIGIT / "_” ), if > used for a query parameter would violate the query parameter charset from > section 3.4 of RFC 3986 [4]. > > extension-element if used for an HTTP header would violate the HTTP header > charset (token) from section 5.1 of RFC 9110 [5]. Also, looks like using the > underscore character as a delimiter between extension id and actual header > name could be problematic for NGINX (such headers are dropped by default). > Typically, an HTTP header is of the form “label1-label2-labelN”, as in > “example-header". That’s something we'd need to consider from operational > considerations angle. > > extension-element, especially the suffix ALPHA *( ALPHA / DIGIT / "_” ), if > used for a media type parameter would violate the parameter name (token) > character set from section 5.6.6 of RFC 9110 [6]. > > Given these violations/limitations, recommend dropping “extension-element”. > IMHO, the current definitions in sections 2.3 and 2.4 are clear enough > without limiting allowed character sets for various extension points. > > Bare extension identifiers > ———————————— > > Since the WG spent considerable time debating this subject, having a separate > section with well-explained rationale, as was in -14, will be useful for the > extension authors and implementors. In other words, bring back that section > from -14 as-is into -16, perhaps with a better section title like > “Disallowing Bare Extension Identifiers”. > > Also, as a consumer of this draft, found the latest Syntax section too long, > mixed with bare extensions verbiage. Having a dedicated section for bare > extensions, as was in -14, organizes content better, as well as reads better, > IMO. > > Minor > ——— > > Section 2.1.2 … "The servers MUST list" -> "The server MUST list” ? > > Section 2.4.1 … For clarity, add back after the example: "In this example, > the extension identified by "lunarNIC" is prepended to the member names of > both a JSON string and a JSON array." > > Section 5.4 … Fix "[!@RFC7480], [!@RFC9082], and [!@RFC9083]”. > > Thanks, > Jasdip > > [1] https://datatracker.ietf.org/doc/html/rfc7480#autoid-15 > <https://datatracker.ietf.org/doc/html/rfc7480#autoid-15> > [2] https://datatracker.ietf.org/doc/html/rfc3986#autoid-23 > <https://datatracker.ietf.org/doc/html/rfc3986#autoid-23> > [3] https://datatracker.ietf.org/doc/html/rfc8259#autoid-10 > <https://datatracker.ietf.org/doc/html/rfc8259#autoid-10> > [4] https://datatracker.ietf.org/doc/html/rfc3986#autoid-24 > <https://datatracker.ietf.org/doc/html/rfc3986#autoid-24> > [5] https://www.rfc-editor.org/rfc/rfc9110.html#name-field-names > <https://www.rfc-editor.org/rfc/rfc9110.html#name-field-names> > [6] https://www.rfc-editor.org/rfc/rfc9110.html#name-parameters > <https://www.rfc-editor.org/rfc/rfc9110.html#name-parameters> > > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
