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
