Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

Pawel Kowalik <kowalik@denic.de> Mon, 28 November 2022 21:02 UTC

Return-Path: <kowalik@denic.de>
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 CB995C14F742 for <regext@ietfa.amsl.com>; Mon, 28 Nov 2022 13:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denic.de
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 jcbmVqcgXxJM for <regext@ietfa.amsl.com>; Mon, 28 Nov 2022 13:02:35 -0800 (PST)
Received: from mout-b-203.mailbox.org (mout-b-203.mailbox.org [IPv6:2001:67c:2050:102:465::203]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA0BC14F6EC for <regext@ietf.org>; Mon, 28 Nov 2022 13:02:34 -0800 (PST)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-203.mailbox.org (Postfix) with ESMTPS id 4NLdFt4Bdkz9tMp; Mon, 28 Nov 2022 22:02:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1669669346; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7EzWPOteENQ7BA71/sou+M9Wm51WNtSCgBLouV4AN34=; b=yVairfNsdQ8Te5PnjoKqrhAWJhrXpGNEq4ScmuF5SreaL12M3HAX6c9kOJnlDWJVoNwg86 fYfOgwtskrl2P+k3n2sdqihyvuSOlskXNbSS9CcsIQiZxeMDPpJ/Ega8A6bDBCI5wlUcZz Xi7nsBDDBnwVaJP8mdYU0j+bMK5TvEUEkYRyGb9JsSc1zinrtfDroRvg9VDxE9b9xecPFM S1Gwn18b4I4DWaCEo0prp/x2XZCT2rQWPELs5wi0O31LETyJCl9eSe14Nzpv07GeehV9xt oPn9d+ZcGZn7Q8FYMWq8LXDAJQZv+nWEBnhC3t4/rMMzAFBEuU0v9zhtXPS/tQ==
Content-Type: multipart/alternative; boundary="------------V00Z79wdYdhkuQiphVZ5p0YI"
Message-ID: <06491465-f5ef-8ff9-dfab-4bc2caf941e8@denic.de>
Date: Mon, 28 Nov 2022 22:02:25 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Mario Loffredo <mario.loffredo@iit.cnr.it>, regext@ietf.org
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> <85c931a7-7800-6f57-6eed-5115fc1d448c@iit.cnr.it> <Y4Pbb2exb8B34eXc@TomH-802418> <1e06a59a-776a-421a-c91c-866ca6c5227d@denic.de> <ea670a71-c628-837c-333a-c2fe4e75452f@iit.cnr.it>
From: Pawel Kowalik <kowalik@denic.de>
In-Reply-To: <ea670a71-c628-837c-333a-c2fe4e75452f@iit.cnr.it>
X-MBO-RS-META: s4goubozqzjoaanrr771bijtg6heem9e
X-MBO-RS-ID: 557c37d93d022bc9255
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/xoYMeWheHzs_Dhu6E1KYzOjWt0A>
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: Mon, 28 Nov 2022 21:02:39 -0000

Hi Mario,

My comment inline.

Am 28.11.22 um 21:20 schrieb Mario Loffredo:
>>>> "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."
>> [PK] not sure about the second MUST NOT if it's not too hard. What 
>> kind of harm we are trying to prevent, when 2 reverse search 
>> properties match the same RDAP property?
>> I am thinking of a scenario, where the server defines a custom 
>> property, then it gets registered under a different name - the server 
>> may wish to keep both for back compatibility.
> [ML] Just the opposite harm. A registered property having the same 
> name of a custom property but they refer to different RDAP properties. 
[PK2] OK, this one I agree, but this is the first part "A custom reverse 
search property MUST NOT collide with a registered reverse search 
property", isn't it?

My comment was referring to the second part, where, if I read it right, 
it would be forbidden to match a custom reverse search property to same 
field as any of already registered ones.

Kind regards,

Pawel