Hi Jasdip, Tom,

On 03.01.25 22:41, Jasdip Singh wrote:

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).

```


[PK] Thanks. The proposed text covers my concern.

Kind Regards,

Pawel


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

Reply via email to