[regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search

Mario Loffredo <mario.loffredo@iit.cnr.it> Fri, 11 October 2024 06:50 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 DC5F9C14F614 for <regext@ietfa.amsl.com>; Thu, 10 Oct 2024 23:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iit.cnr.it
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 KaaSMIdllxg7 for <regext@ietfa.amsl.com>; Thu, 10 Oct 2024 23:49:59 -0700 (PDT)
Received: from mx5.iit.cnr.it (mx5.iit.cnr.it [146.48.58.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52170C14F5EE for <regext@ietf.org>; Thu, 10 Oct 2024 23:49:58 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mx5.iit.cnr.it DB66AC05F3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iit.cnr.it; s=mx520231221; t=1728629395; bh=zxr/vqkpz82fbcYrFg4yV4La0fkiO3Hl6ZhIOFkM9LE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=L1509AUBmvcmlW/tzd3SSif4Zam+ruRjBl0VOCUqJXrrdb1tF5orCA1CO6mJKc2eM CJxd1QFV2X6jQzfifB/+gyXsZzzdI0BUCti2Qctui2S8NhUKymEPBM56CYVBRRDqdD pTOD/k23DzxK7vNtssuFR+MaLIawJ6hdBEzpF7IlgM+vLM5t3yWC3M+fXimADpUL4v T/IJa6DSg7ZVMp8aRIZAwG9GtBhNMCTyqGxOQu5nrtBqRI0FdqR1y8R9UPufHLi+Lc W5MOUm7z0RkbWvGeBPZvP7DJsmcaL6HGY7JzxTGarhoAX4CPyPKdX03tesyURU1Ws7 /kmumc/W64tvg==
Received: from localhost (localhost [127.0.0.1]) by mx5.iit.cnr.it (Postfix) with ESMTP id DB66AC05F3; Fri, 11 Oct 2024 08:49:55 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx5.iit.cnr.it
Received: from mx5.iit.cnr.it ([127.0.0.1]) by localhost (mx5.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10028) with ESMTP id 0d2tTAuseKzR; Fri, 11 Oct 2024 08:49:55 +0200 (CEST)
X-Relay-Autenticated: yes
Content-Type: multipart/alternative; boundary="------------DHc0ElUZmvMG116sOTs0q0d6"
Message-ID: <5ca098d3-9b91-41e1-8c70-777475d0c01c@iit.cnr.it>
Date: Fri, 11 Oct 2024 08:44:23 +0200
Mime-Version: 1.0
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "jasdips@arin.net" <jasdips@arin.net>, "andy@hxr.us" <andy@hxr.us>, "regext@ietf.org" <regext@ietf.org>
References: <85a84477f52642af954774eaeeaf2953@verisign.com> <b6719fc5-1653-4220-98a9-b2b627526e0a@hxr.us> <0c1a0521a95d4e01b3c96fa4b6650c6b@verisign.com> <PH7PR15MB6084469A0E136456F329EBC2C97F2@PH7PR15MB6084.namprd15.prod.outlook.com> <5d0e9374f477484ca99c889518efec49@verisign.com> <PH7PR15MB6084A9AEFDB8389B89D37759C97F2@PH7PR15MB6084.namprd15.prod.outlook.com> <08de7f8a94c5450886b753b6756760de@verisign.com>
Content-Language: it
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
In-Reply-To: <08de7f8a94c5450886b753b6756760de@verisign.com>
Message-ID-Hash: FJDEYOZ3M5FQ2HV4TL4EPR4M67Q5D2IG
X-Message-ID-Hash: FJDEYOZ3M5FQ2HV4TL4EPR4M67Q5D2IG
X-MailFrom: mario.loffredo@iit.cnr.it
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/fKLq0tzB7AR1WfCsUdai4F9yDxw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Owner: <mailto:regext-owner@ietf.org>
List-Post: <mailto:regext@ietf.org>
List-Subscribe: <mailto:regext-join@ietf.org>
List-Unsubscribe: <mailto:regext-leave@ietf.org>

Hi Scott,

sorry  but didn't undenstand your example about collisions.

 From a conceptual perspective, any path "/domains/...." is a subpath 
(we can consider it as an extension) of "/domains" but, 
programmatically, they are different as AFAIK a full path is parsed and 
processed altogheter.

For example, in .it RDAP server, I have leveraged the feauture provided 
by a Java framework to specify paths and their subpaths in order to 
easily map an incoming request onto but, at the end of the parsing 
phase, only one full path is selected.

Therefore, IMHO, there is no risk of collisions.


Best,

Mario

Il 09/10/2024 21:30, Hollenbeck, Scott ha scritto:
>
> Yes, we do, but I would still like to request that the shepherd 
> writeup include a description of the situation with respect to the 
> extension identifiers and non-conformance with Standard 95 as noted 
> below. It would be perfectly acceptable to note that only one person 
> raised the concern. My comments might have come in after the last 
> call, but they were sent prior to AD review. They’re not invalid.
>
> Scott
>
> *From:*Jasdip Singh <jasdips@arin.net>
> *Sent:* Wednesday, October 9, 2024 12:47 PM
> *To:* Hollenbeck, Scott <shollenbeck@verisign.com>; andy@hxr.us; 
> regext@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Re: Extension Identifiers in 
> draft-ietf-regext-rdap-rir-search
>
> *Caution:*This email originated from outside the organization. Do not 
> click links or open attachments unless you recognize the sender and 
> know the content is safe.
>
> We agree. :)
>
> Jasdip
>
> *From: *Hollenbeck, Scott <shollenbeck@verisign.com>
> *Date: *Wednesday, October 9, 2024 at 12:30 PM
> *To: *Jasdip Singh <jasdips@arin.net>, andy@hxr.us <andy@hxr.us>, 
> regext@ietf.org <regext@ietf.org>
> *Subject: *RE: [regext] Re: Extension Identifiers in 
> draft-ietf-regext-rdap-rir-search
>
> *From:*Jasdip Singh <jasdips@arin.net>
> *Sent:* Wednesday, October 9, 2024 11:54 AM
> *To:* Hollenbeck, Scott <shollenbeck@verisign.com>; andy@hxr.us; 
> regext@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Re: Extension Identifiers in 
> draft-ietf-regext-rdap-rir-search
>
> *Caution:*This email originated from outside the organization. Do not 
> click links or open attachments unless you recognize the sender and 
> know the content is safe.
>
> Scott,
>
> Glad to know that you are not against the 
> use-extension-id-as-segment-for-child-segments approach, beside the 
> prepend-extension-id-and-underscore approach from STD 95.
>
> Re: “The “domains” collision is an issue. We can deal with it now, or 
> during IETF last call.”
>
> AFAICT, it is not an issue. One can define new child segments under it.
>
> */[SAH] I’ve actually written RDAP server code. Let’s walk through how 
> this might work./*
>
> *//*
>
> */My server receives a “domains” query. I don’t support this 
> extension, but I do support DNR domain searches. I expect the query to 
> be formatted as described in RFC 9082. Anything else is an error. No 
> problem there./*
>
> *//*
>
> */My server receives a “domains” query. I support this extension, but 
> I do not support DNR domain searches. I expect the query to be 
> formatted as described in the draft. Anything else is an error. No 
> problem there./*
>
> *//*
>
> */My server receives a “domains” query. I’m a general purpose RDAP 
> server, and I include code to process both DNR and RIR domain 
> searches. I need to figure out which “domains” query I’ve received. I 
> need to parse the query further to figure out what to do next. If 
> there are query parameters, but no child path segments, I may have a 
> valid DNR search. If there are no query parameters, but I have a child 
> path segment that begins with “rirSearch1”, I may have a valid RIR 
> search. Anything else is an error. If this is all correct, OK, I agree 
> that there’s no issue here./*
>
> *//*
>
> */Scott/*
>
>
> _______________________________________________
> regext mailing list --regext@ietf.org
> To unsubscribe send an email toregext-leave@ietf.org

-- 
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo