Hi Mario, On 3/9/23, 5:41 AM, "Mario Loffredo" <[email protected] <mailto:[email protected]>> 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.) > - 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. > - 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. Thanks, Jasdip _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
