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?
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. :))
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.
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?
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 -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
