Hi Jasdip,

thanks a lot for your review.

Please find my comments inline.

Il 23/04/2025 00:49, Jasdip Singh ha scritto:

Hi Mario,

I reviewed the latest RDAP JSContact draft. :) Please find below my feedback:

6.3. RDAP Reverse Search Mapping Registry

“Searchable Resource Type: domains, nameservers, entities”

Since the RDAP RIR Search draft also includes reverse search [1], should we include “ips” and “autnums” as searchable resource types as well for these IANA registrations?

[ML] Sure.

4.2. Transition Procedure

This section makes use of the “notices” data structure from RFC 9083. Section 4.3 of that RFC [2] says:

  “The notices structure denotes information about the service providing RDAP information and/or information about the entire response, whereas the remarks structure denotes information about the object class that contains it (see Section 5 regarding object classes).”

Wonder if we should be using the “remarks” data structure instead of “notices” given the jCard-to-JSContact transition information is related with the entity objects within a response, and not the entire response? (Not totally sure about the RFC 9083 guidance; hence thought of asking. :))


[ML] The "remarks" property "denotes information about the object class that contains it" (quoting RFC9083) so its use is inefficient when the client sends a search query instead of a lookup.

The "notices" property is more suitable because it refers to the entire response regardless of the number of objects it contains.

See the following notice related to a search.

      {
            "title": "jCard sunset end",
            "description": [
                "2026-06-30T23:59:59Z"
            ],
            "links": [
                {
                    "value": "https://rdap.pubtest.nic.it/auth/domains?name=nic*.it";,
                    "rel": "alternate",
                    "href": "https://rdap.pubtest.nic.it/auth/domains?name=nic*.it&versioning=versioning-0.3,jscontact-0.1";,
                    "type": "application/rdap+json"
                },
                {
                    "value": "https://rdap.pubtest.nic.it/auth/domains?name=nic*.it";,
                    "rel": "alternate",
                    "href": "https://rdap.pubtest.nic.it/auth/domains?name=nic*.it";,                     "type": "application/rdap+json;extensions=\"rdap_level_0 jscontact-0.1\""
                }
            ]
        }


Figure 3: jCard sunset - JSContact not requested

This example includes the following link object:

     {

"value": "https://example.net/entity/XXXX";,

"rel": "alternate",

"type": "application/rdap+json;extensions=\"rdap_level_0 jscontact\"",

"href": "https://example.net/entity/XXXX";

      }

However, section 4 of the “Extensions Parameter for the RDAP Media Type” draft [3] says:

  “Usage of the "extensions" parameter in the media type of the "type" attribute is NOT RECOMMENDED as clients are under obligation to use the "extensions" parameter as described in Section 3. That is, clients will populate the contents of the "extensions" parameter according to Section 3 regardless of its usage in the link.”

Looks like this link object’s inclusion in that example would be redundant since it’d be no different from the “self” link once the recommendation to not include the “extensions” parameter in the “type” attribute is considered.

[ML] I probably missed something, but could you please tell me which normative language in Section 3 prohibits to return that link in the response?

7. Security Considerations

Couple of redaction methods from RFC 9537 [4] [5] for “uid" are considered. Last we discussed this subject, the JSONPath usage from that RFC seemed problematic. Is there any concern vis-à-vis that?

[ML] Honestly, the JSONPath expression pointing to the uid property seems less complex than others including filters to select and redact a jCard property.

What's the specific problem here ?


Best,

Mario

Overall, the latest RDAP JSContact draft now looks simpler to implement!

Thanks,

Jasdip

[1] https://www.ietf.org/archive/id/draft-ietf-regext-rdap-rir-search-16.html#name-reverse-search

[2] https://www.rfc-editor.org/rfc/rfc9083.html#name-notices-and-remarks

[3] https://www.ietf.org/archive/id/draft-ietf-regext-rdap-x-media-type-03.html#name-usage-in-rdap-links

[4] https://www.rfc-editor.org/rfc/rfc9537.html#name-redaction-by-empty-value-me

[5] https://www.rfc-editor.org/rfc/rfc9537.html#name-redaction-by-replacement-va


_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]

--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to