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
[2] https://datatracker.ietf.org/doc/html/rfc3986#autoid-23
[3] https://datatracker.ietf.org/doc/html/rfc8259#autoid-10
[4] https://datatracker.ietf.org/doc/html/rfc3986#autoid-24
[5] https://www.rfc-editor.org/rfc/rfc9110.html#name-field-names
[6] https://www.rfc-editor.org/rfc/rfc9110.html#name-parameters
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
