https://github.com/anewton1998/draft-regext-rdap-extensions/issues/51
>> Section 2.3.2, paragraph 4 >> not required. In this situation, the URL path operates as a namespace for >> the query parameters, so there is no risk of collision with parameters >> defined elsewhere. > There is a potential of collision with a scopeless parameter of another > existing or future extension. [JS] Yes, this could be problematic. We have a precedence of scopeless parameters for sorting and paging. [TH] While there are existing 'scopeless' parameters (e.g. 'count' in RFC 8977), hopefully no more will be added. Documenting those existing 'scopeless' parameters here would be a good idea, though, along the same lines as for the non-compliant extensions. > Say an extension would define a local search parameter that some other > extension would define as applicable to all searches. I don't think there is a good way preventing that from happening other than either prefixing all parameters no matter at which level (which would also be bad). Maybe a suggestion to register such identifiers in case very generic terms are used? [JS] That’s an interesting idea. Perhaps we would overload the IANA RDAP JSON Values registry and a new type, say “query parameter”, could be created. This needs further discussion. [TH] I think the existing document text is fine here. Either a parameter is intended for general use, in which case it has to be prefixed, or it's intended for use with an existing URL that operates as a namespace, and it's fine for it to be unprefixed. (Or in other words, it may be that simply documenting the existing 'scopeless' parameters will be sufficient here.)
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
