Hi Jasdip,
again my comments below
Il 09/03/2023 16:40, Jasdip Singh ha scritto:
Hi Mario,
On 3/9/23, 5:41 AM, "Mario Loffredo" <mario.loffr...@iit.cnr.it
<mailto:mario.loffr...@iit.cnr.it>> wrote:
- Section 3: "Servers MUST NOT provide or implement unregistered reverse searches or
unregistered reverse search mappings." ... Does "unregistering" entries from these
IANA registries mean removing them, or simply marking them as deprecated? If the latter, do we need
a status field in these registries to differentiate the active entries from the deprecated ones?
Not clear about it.
[ML] Unregistered means merely not included in the registries and the
sentence looks clear to me. Don't think the registries' entries should
be removed or deprecated as well.
Registries can decide on their own to deprecate either properties or
mappings and how long should be the deprecation period. Obviously,
deprecations can be finally achieved de facto but we cannot be
completely sure that some entries are no more active.
[JS] Perhaps, we are here conflating the proposed RDAP Reverse Search and RDAP Reverse Search
Mapping IANA registries with the DNRs (Domain Name Registries) and RIRs (Regional Internet
Registries)? :) My question is about the lifecycle of an entry in the RDAP Reverse Search and RDAP
Reverse Search Mapping IANA registries and how an entry there is "unregistered".
(Assuming the word "unregistered" is being used above for such entries.)
[ML] Personally, the entries of both the registries can never be
updated. As I said in my previous reply, unregistered doesn't mean
removed/deprecated once registered but just not yet included in the
registry.
Neither I see a particular need for specifying in the registry that an
entry gets obsolete. In that case, the property or the mapping will not
be included in the reverse_search_properties or
reverse_search_properties_mapping, respectively.
Hope I clarified my previous comment.
- Section 12.1: "Intended usage: This extension identifier is used for reverse search URI path
segments." ... Should we elaborate here that this extension identifier is also used as a prefix in the
"reverse_search_properties" and "reverse_search_properties_mapping" data members' names?
[ML] Are you OK with the following?
Intended usage: This extension identifier is used for both URI path segments
and response extensions related to the reverse search in RDAP.
[JS] Yes, that's comprehensive now.
[ML2] Good.
- Appendix A: Just curious if the reason why the "Federated Authentication for the
Registration Data Access Protocol (RDAP) using OpenID Connect" draft is not
mentioned in this draft is because we think that the latter would be on the standards
track before the former?
[ML] Not just because of it.
As said in the previous point, RDAP providers are free to implement
their security measures as they see fit. Using OpenID is an option.
Registries could implement additional OpenID measures that are not
described in rdap-openid such as those presented in Appendix A,
specifically time-based and attribute-based access control features.
That being said, I can't find a valid reason to keep a dependency on an
ongoing document included in the informative references.
[JS] Agreed.
[ML2] :-)
Best,
Mario
Thanks,
Jasdip
--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
