Hi Pawel, I think we as WG have been discussing 2 separate points lately:
1. To what extent should a bare identifier be allowed? Never, always, under certain well-defined conditions (say, when only one query path, query parameter, JSON name, object class, and/or another extension point (HTTP header, etc) needs naming), or when a technical solution cannot be defined otherwise. The next version of the RDAP Extensions draft would present these options so that we can settle this matter. 2. Should a media type parameter, as part of an RDAP extension, also be prefixed? For prefixing consistency, the answer seems to be yes, per earlier discussion with James. So far, from naming conflict prevention angle, we have identified query paths, query parameters, JSON member names, object class names, HTTP headers, and media type parameters as prefixing candidates. Andy and I were discussing one more. :) Should a new relation type defined for a web link used in an RDAP extension also be prefixed? Looks like we should since the Media Types reviewers recommend greater specificity for relation types. Though we haven’t yet tried registering “foobar123-xyz” as a new relation type. ;) The closest prefixing example for regext purposes has been “rdap-up”, etc for the RIR search, whereas “geofeed” was allowed for the RDAP Geofeed from specificity angle. Thanks, Jasdip From: Pawel Kowalik <[email protected]> Date: Tuesday, June 24, 2025 at 1:42 AM To: Jasdip Singh <[email protected]>, Gould, James <[email protected]>, [email protected] <[email protected]>, Hollenbeck, Scott <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [regext] Re: On bare identifiers in Extensions draft Hi Jasdip, On 18.06.25 19:43, Jasdip Singh wrote: Hi Pawel, Totally agree with being consistent prefixing-wise for query requests and responses in RDAP extensions! But afraid, we might be overlaying this prefixing concept on to the media type space unnecessarily. If another RDAP extension ends up adding another parameter to “application/rdap+json” or another media type, the IANA registration process shall identify any conflict with existing parameters when updating that media type’s specification. Correct. Being consistent is also my point but not necessarily in a twist that everything shall be always prefixed. I argument, that "IANA registration process shall identify any conflict" also applies to all other RDAP cases, thus rendering bare identifiers no issue for the interoperability or conflict potential between extensions. Thanks, Jasdip [...]
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
