https://github.com/anewton1998/draft-regext-rdap-extensions/issues/41
>> Section 2.4.4, paragraph 1
>> As described in [RFC9082] and Section 2.3, an extension may define new paths
>> in URLs. If the extension describes the behavior of an RDAP query using the
>> path to return a new RDAP search result, the JSON name of the search result
>> MUST be prepended with the extension identifier (to avoid collision with
>> search results defined in other extensions). If the search result contains
>> object class instances
> I think this requirement is harmful for the protocol. Let's say I want to
> create extension "fuz" that would offer a new way of searching through
> objects. Let's call it fuzzySearch. I would define a new query parameter
> "fuzzy" and append it to a path segment according to the object class I would
> like to search through. So if I query /domains?fuzzy=foo I expect as a client
> to still be able to process the response as per rfc7483 from
> domainSearchResults JSON element rather than special handling for
> fuz_domainSearchResults.
[JS] Agreed. This prepending is only for newly defined RDAP search result
members and when a bare extension identifier is not used to name such a new
member. As a contrary example, the reverse domain search in the RIR Search
draft leverages the existing “domainSearchResults” member.
[TH] I think this is right, but that it may be worth spelling it out in more
detail. Something like:
```
As described in [RFC9082] and Section 2.3, an extension may define
new paths in URLs. If the extension describes the behavior of an
RDAP query using the path to return an RDAP search result for a
new object class, the JSON name of the search result MUST be
prepended with the extension identifier (to avoid collision with
search results defined in other extensions).
```
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
