[regext] Re: Extensions: Styling conventions for object class names and JSON names #40

["Andrew Newton (andy)" <[e-mail]>]

I am good with camelCasing and stating that violation of the
recommendation for URL encoding could lead to interoperability issues
when the object class name is to appear in a URI.

-andy

On Fri, Jan 3, 2025 at 4:39 PM Jasdip Singh <[e-mail]> wrote:
>
> https://github.com/anewton1998/draft-regext-rdap-extensions/issues/40
>
>
>
> > Section 2.4.3, paragraph 3
>
> >> It is RECOMMENDED that object class names comprise lowercase ASCII characters, and that the "_" (underscore) character be used as a word separator.  Though "objectClassName" is a string and [RFC9083] does define one object class name with a space separator (i.e. "ip network"), usage of the space character or any other character that requires URL-encoding is NOT RECOMMENDED.  When object class names are also used in URLs, extensions MUST specify that the names are to be URL-encoded as defined in [RFC3986] if the object class names contain any characters requiring URL-encoding.
>
>
>
> > I don't think we need such recommendation.
>
>
>
> [JS] In our opinion, we need some constriction since the current definition is just a string.
>
>
>
> > First: why only lowercase with underscore? There does not seem to be any explanation.
>
>
>
> [JS] Lowercase has been the de facto convention so far. As for the underscore, the idea was to do better than white spaces and reduce the URL-encoding overhead.
>
>
>
> > URL path segments are case-sensitive. Especially with the notion of underscore being a separator between extension identifier and name, usage of underscore in name itself is even counterproductive. Actually if the extension identifier would contain underscore and the name would contain underscore and the separator will also be underscore it will be impossible to figure out which part is which.
>
>
>
> [JS] Why/when is such figuring out (parsing) useful?
>
>
>
> [TH] Although it's not strictly necessary for a client to parse the name, I think it's useful to be able to see at a glance that a string is for object X from extension P, rather than having to consider the role of each segment in the string.  But this may be a moot point if his separate camel-casing suggestion in this respect is accepted (which I think would be a good idea).
>
>
>
> > Second: mandating extensions to say something already defined by http (URL-encoding of path segments) on one side not needed on the other side even harmful in the current version. Here it does not tell where to URL-encode
>
>
>
> [JS] Doesn’t URL-encoding connote sufficiently?
>
>
>
> > It is not required in JSON values for example (or in other words JSON defines its own encoding for certain characters).
>
>
>
> [JS] Of course.
>
>
>
> [TH] I think the argument here is that the sentence '[w]hen object class names are also used in URLs...' could be read as 'an object class name that is never used in a URL does not need to be URL-encoded anywhere, but an object class name that is used (even once) in a URL needs to be URL-encoded everywhere'.  As with the previous part, this becomes moot if camel-casing is recommended.  (I suppose there is a chance that somebody goes ahead and uses a character that requires URL encoding notwithstanding the recommendation, but in that case it's implicit that URL encoding is required in the URL only.)
>
>
>
> > Section 2.4.7, paragraph 1
>
> >> The styling convention used in [RFC9083] for JSON names is often called "camel casing", in reference to the hump of a camel.  In this style, the first letter of every word, except the first word, composing a name is capitalized.  This convention was adopted to visually separate the namespace from the name, with an underscore between them.  Extension authors SHOULD use camel casing for JSON names defined in extensions.
>
>
>
> > Why is it recommended and what are the negative consequences of not following this recommendation?
>
>
>
> [JS] Because of the precedence/status quo.
>
>
>
> > Also this is somehow inconsistent when 2.4.3. is actually recommending the opposite when it comes to object class name.
>
>
>
> [JS] That’s an interesting observation. Perhaps, object class name could also be camel-cased for consistency with JSON member names?
>
>
>
> [TH] Per earlier comments, I think this is a good idea.
>
> _______________________________________________
> regext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]