I wish I had asked this during the WG discussion, but I do have a question.
Section 12.2.1 paragraph 3 states: "The designated expert should prevent collisions and confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability. References are not limited only to RFCs and simple definitions could be described in the registries themselves." Does this mean that no duplicates in the RDAP Reverse Search Mapping (section 12.2.4) are allowed? If this is the case, that means a reverse search of "fn" will only apply to jCard and cannot be applied to JSContact or SimpleContact since the registration for "fn" is jCard specific. Is this intentional? I see this in section 5: "Documents that deprecate or restructure RDAP responses such that a registered reverse search is no longer able to be used MUST either note that the relevant reverse search is no longer available (in the case of deprecation) or describe how to continue supporting the relevant search by adding another mapping for the reverse search property (in the case of restructuring)." It implies that duplicates are allowed, at least to me. -andy On Thu, Aug 10, 2023 at 6:41 PM David Dong via RT <[email protected]> wrote: > > Dear Andy and Scott (cc: regext WG), > > As the designated experts for the RDAP Extensions registry, can you review > the proposed registration in draft-ietf-regext-rdap-reverse-search-23 for us? > Please see: > > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ > > The due date is August 24th. > > If this is OK, when the IESG approves the document for publication, we'll > make the registration at: > > https://www.iana.org/assignments/rdap-extensions/ > > Unless you ask us to wait for the other reviewer, we’ll act on the first > response we receive. > > With thanks, > > David Dong > IANA Services Sr. Specialist _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
