Pawel, inline... On 6/2/25 11:45, Pawel Kowalik wrote:
We haven't named them, but they exist. Versioning or "An RDAP With Extensions Media Type" (a.k.a rdap-x) just to name few.
Except neither of those need to be bare. They are just used in conjunction with other extensions, as are many other extensions for RDAP.
An alternative would be to always have to update std95 if we would want to add a new "top level" not prefixed element.
That would probably be much more appropriate, along with considering I-JSON and UTF-8 assigned sets.
Why just JSON as they could also apply to paths, query parameters and object class names? And why is JSON the exception when the negative implementation feedback is specific to JSON?I mentioned it as it was referred to in -04 4.5. But you are right, paths, query parameters and object class names have the same properties. If there is a single item added by the extension, and it's equal to extension identifier - it's all same. For class names and query parameters if an extension would want to add several there is no other choice than prefix, as the same name cannot be duplicated. For JSON names and paths one may do a container with one name and include all needed values in there, or have a flat list with prefixes. It would be "foo_val1": "..." vs. "foo":{ "val1": "..." } for JSON, or foo_subpath1 vs foo/subpath1 for paths.
This and the various combinations of an extension using the bare id in a path but not JSON, etc... adds unneeded complexity. That's why bare ids are not a good idea. -andy _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
