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 <jasd...@arin.net> 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 -- regext@ietf.org > To unsubscribe send an email to regext-le...@ietf.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
