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]