Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt
Mario Loffredo <mario.loffredo@iit.cnr.it> Fri, 25 November 2022 13:21 UTC
Return-Path: <mario.loffredo@iit.cnr.it>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67A7C14CE2D for <regext@ietfa.amsl.com>; Fri, 25 Nov 2022 05:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBPMeYT77Mup for <regext@ietfa.amsl.com>; Fri, 25 Nov 2022 05:21:42 -0800 (PST)
Received: from iit.cnr.it (mx4.iit.cnr.it [146.48.58.11]) by ietfa.amsl.com (Postfix) with ESMTP id 817F0C14CEE9 for <regext@ietf.org>; Fri, 25 Nov 2022 05:21:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.iit.cnr.it (Postfix) with ESMTP id 692F3B8063F; Fri, 25 Nov 2022 14:21:40 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it
Received: from iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur2P02jeEx10; Fri, 25 Nov 2022 14:21:36 +0100 (CET)
Received: from [192.168.16.66] (sa.nic.it [192.12.193.247]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mx4.iit.cnr.it (Postfix) with ESMTPSA id 4F1C5B805A4; Fri, 25 Nov 2022 14:21:36 +0100 (CET)
Content-Type: multipart/alternative; boundary="------------r90HkhQaSTZtt2TkaE2BSjGq"
Message-ID: <85c931a7-7800-6f57-6eed-5115fc1d448c@iit.cnr.it>
Date: Fri, 25 Nov 2022 14:18:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0
To: "regext@ietf.org" <regext@ietf.org>, "pawel.kowalik@ionos.com" <pawel.kowalik@ionos.com>
References: <166904400845.63178.12808486915076028699@ietfa.amsl.com> <3cf24684-e89c-2565-e2ae-be797359ebc4@iit.cnr.it> <Y3zH8UtSf4QMwHU5@TomH-802418> <3d566ca4-999e-4e72-e8f1-2e9dd65d2440@iit.cnr.it> <Y39njQxonjw4vw21@TomH-802418>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
In-Reply-To: <Y39njQxonjw4vw21@TomH-802418>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/GLsBKfdjR9GOYPzJ5BYxUPTEw6k>
Subject: Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Nov 2022 13:21:46 -0000
Hi Tom, please see my comments below prefixed by [ML2] Il 24/11/2022 13:46, Tom Harrison ha scritto: > Hi Mario, > > On Wed, Nov 23, 2022 at 09:42:56AM +0100, Mario Loffredo wrote: >> Il 22/11/2022 14:00, Tom Harrison ha scritto: >>> On Mon, Nov 21, 2022 at 04:40:28PM +0100, Mario Loffredo wrote: >>>> With regard to the registration of the reverse search properties, >>>> I have opted for adding entries in the RDAP JSON Values registry >>>> rather than defining an ad-hoc registry. >>>> >>>> That is because servers must include the reverse search properties >>>> they support in a specific RDAP help response extension. >>>> >>>> Therefore, some JSON values related to the pre-defined properties >>>> must be included in that registry anyway. >>> I don't follow this part. The document as it stands requires that >>> the supported reverse search properties be included in the >>> reverse_search_properties member of the help response, but that of >>> itself doesn't mean those properties need to be registered in the >>> "RDAP JSON Values" registry. More relevantly, relying on the "RDAP >>> JSON Values" registry in this way means that a given field name can >>> be used for only one reverse search, because the only data in the >>> registry entry aside from the type is the field name. I think it >>> would make more sense to define a separate registry for the reverse >>> search properties, including the additional fields from the >>> metadata, and potentially the JSONPath to the field value as well >>> (though omitting the JSONPath may ease the transition from one >>> underlying data format to another, such as with jCard and >>> JSContact). >> [ML] Since a reverse search property could be custom, think that the >> document can't require the registration of any supported reverse >> search property in the RDAP JSON Values registry. >> >> (To know the reasons supporting the need of custom properties please >> see the subsequent comment) >> >> A reverse search property basically depends only on the related >> resource type. I mean, the searchable resource type is needed just >> to identify the RDAP relationship which a reverse search feature is >> based upon. >> >> Substantially, what we need to do is to register a conventional >> label mapping an RDAP response field that is referred to in a >> reverse search query. >> >> Since the label is also used as a JSON value in the >> "reverse_search_properties" member of the help response, IMO it >> could be sufficient to use the JSON Values registry rather than >> defining a new one. > This is the part I (still) don't follow, sorry. The fact that the > label is a JSON value in the "reverse_search_properties" member of the > help response does not mean that the label needs to be registered in > the "RDAP JSON Values" registry, as best I can tell. [ML2] Per my understanding of the introduction of RFC8126, any constant defined in a protocol should be registered. Since the "reverse_search_properties" member includes some pre-defined JSON values, they can be added to the "RDAP JSON Values" registry. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. > >> The content of "reverse_search_properties" member disambiguates the >> meaning of that labels in the context of the reverse search queries >> a server supports, e.g. an RDAP server could provide >> >> "domains/reverse_search/entity?handle" rather than >> "nameservers/reverse_search/entity?handle" or both of them. >> >> That said, I admit that the description of the "handle" entry as >> presented in the document is tailored on the "entity" as related >> resource type so, if there is consensus on this way to go, I'll make >> it more generic. > I don't see how the entry could be made more generic with respect to > the related resource type. Even the current descriptions are arguably > too broad, since they do not limit the searchable object type to one > of domains, nameservers, or entities (being the three searchable > object types mentioned in section 2) but could e.g. be read as > applying to IP networks and ASNs as well. A separate registry would > fix this problem. [ML2] I would simply remove the reference to the "entity" object class as in the following: OLD When the related resource type in a reverse search query is "entity", it signals that the RDAP server supports the reverse search based on the "fn"property of an entity associated with the selected searchable resource type NEW It signals that the RDAP server supports the reverse search based on the "fn"property of the given resource type associated with the given searchable resource type As I wrote in my previous mail, the reverse search property maps a property of the related resource type in a reverse search query. The searchable resource type is just needed to specify which reverse query an RDAP operator is willing to support but this information is included in the "reverse_search_properties" help response extension. This approach would minimize the number entries compared to those required for a registry including all the variables in the reverse search query model. In fact, having defined four reverse search properties and based on the fact that the object class entity is associated to any RFC9083 object class, the pre-defined entries of a possible "Reverse Search Properties" registry should be the following: (domains|nameservers|entities) - entity - handle (domains|nameservers|entities) - entity - fn (domains|nameservers|entities) - entity - email (domains|nameservers|entities) - entity - role domains - nameserver - handle Applying reverse search to ips and autnums searchable resource types without declaring additional properties would add no entry to "RDAP JSON Values" registry instead of eight additional entries in the "Reverse Search Properties" registry. >> Maybe it could be better to have more generic descriptions in the >> other entries as well. >> >> At the same time, I have no particular objection to define an ad-hoc >> registry if there is much consensus on it. >> >> Would like to know other opinions so that we can come to a shared >> solution. >> >>> Separately, given that the bar for registering extensions is so low >>> (turnaround is 1-2 weeks, IME), it doesn't seem as though >>> "custom"-type reverse search properties are worth the additional >>> complexity. Omitting these would also avoid the risk of different >>> servers implementing support for the same search in inconsistent >>> ways, which may be an issue when transitioning to JSContact, for >>> example. >> [ML ] Custom properties can be used in test phase and, anyway, in >> the interval between the beginning of their usage and the time they >> are registered once they are assumed to be stable (or the RDAP >> server is released in the live environment) >> >> Basically, a custom reverse search property is a temporary >> unregistered value for a registered extension. >> >> I would let them be allowed but I wonder If it's worth clarifying >> that a custom reverse search property SHOULD not collide with a >> registered reverse search property. > But there's no way to prevent collisions from happening, if custom > reverse search properties are supported. If server S1 uses a custom > reverse search property named P, and server S2 then registers with > IANA a property with the same name, then there will be a collision > between the two names. It won't necessarily be possible for S2 to > confirm that P hasn't previously been used. [ML2] Even now there is no real way to prevent collisions since extension identifiers and JSON values are normally used for long before they are registered. Currently, only when an extension is considered stable, the related identifier is registered. Think that preventing RDAP operators to provide temporary reverse search properties is incompatible with registries'policy of releasing features on test platforms for a limited period before running them in the live environment. > >> With regard to the meaning of your last sentence, I need a >> clarification. Are you meaning that inconsistencies come up >> because, for example, the "email" reverse search property maps the >> same JSON value but identified through two different JSONPaths in >> the RDAP response ? > I don't think it would be open to a server to do this under the > current document, because the JSONPath to "email" is defined in the > document itself. An example scenario where inconsistency could occur: > > - S1, S2, and S3 implement support for JSContact. > - S1 decides to add a custom reverse search property called "name", > for matching a JSContact "name" (per 2.2.1 of that document), by > looking at the "given" and "surname" name components for the > JSContact "name". > - S2 also adds a custom reverse search property called "name", but > instead matches against the JSContact "fullName". > - S3 also adds a custom reverse search property called "name", in the > same manner as S2, but if a jCard is retrieved, it falls back to > using the same logic as that for an "fn" reverse search per the > current document. I still think that custom properties are useful for the reasons above. On the other hand, their possible misuse should be ruled somehow. Here in the following a possible statement limiting the scope of custom properties: "A custom reverse search property MUST NOT collide with a registered reverse search property and MUST NOT match an RDAP property, or any of its variants, matched by a registered reverse search property." Being JSContact fullName a variant of jCard fn, both S2 and S3 can't define "name" as a custom property. Best, Mario > -Tom -- 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] Fwd: New Version Notification for draft-… Mario Loffredo
- Re: [regext] Fwd: New Version Notification for dr… Tom Harrison
- Re: [regext] Fwd: New Version Notification for dr… Mario Loffredo
- Re: [regext] Fwd: New Version Notification for dr… Tom Harrison
- Re: [regext] Fwd: New Version Notification for dr… Mario Loffredo
- Re: [regext] Fwd: New Version Notification for dr… Tom Harrison
- Re: [regext] Fwd: New Version Notification for dr… Pawel Kowalik
- Re: [regext] Fwd: New Version Notification for dr… Mario Loffredo
- Re: [regext] Fwd: New Version Notification for dr… Mario Loffredo
- Re: [regext] Fwd: New Version Notification for dr… Pawel Kowalik
- Re: [regext] Fwd: New Version Notification for dr… Tom Harrison
- Re: [regext] Fwd: New Version Notification for dr… Jasdip Singh
- Re: [regext] Fwd: New Version Notification for dr… Mario Loffredo
- Re: [regext] Fwd: New Version Notification for dr… Mario Loffredo
- Re: [regext] Fwd: New Version Notification for dr… Mario Loffredo
- Re: [regext] Fwd: New Version Notification for dr… Pawel Kowalik
- Re: [regext] Fwd: New Version Notification for dr… Andrew Newton