IETF Logo Mail Archive

[regext] Re: RDAP versioning - on client-server interactions and 2-RTT flow

"kowalik@denic.de" <kowalik@denic.de> Thu, 09 January 2025 12:19 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 48E15C14F71D for <regext@ietfa.amsl.com>; Thu, 9 Jan 2025 04:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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=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 zT59tpnwmoDf for <regext@ietfa.amsl.com>; Thu, 9 Jan 2025 04:19:10 -0800 (PST)
Received: from mout-b-206.mailbox.org (mout-b-206.mailbox.org [195.10.208.51]) (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 EF3C8C14F711 for <regext@ietf.org>; Thu, 9 Jan 2025 04:19:07 -0800 (PST)
Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-206.mailbox.org (Postfix) with ESMTPS id 4YTP3B45Gxz9wQ6; Thu, 9 Jan 2025 13:19:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1736425142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H6sJe9HWkgzInNX6mU8ZvTNFRiQJYsJl0TLMMEob9ik=; b=H9QMnnk1Hzn/00Dvn74oJoj1v4FB2JL1040w9PGghax10WqZlq2ctWZMWlZAYHxqWtVcrr 8X8MER/Ch8u/fk97hgYU5nj+lJAZ/iI+GUZPAmLQjNVE7bJzIrnTNcYWPff8QezehKG8dx H/2UVvGIQCfPWXgWSNbgFmf7Z6V6CcftbM2WTP0ANSmgrop+Djr4XJac1rXUBu14Qc4SKc cQOrhV5LJ+10dDylDQc5qkg4ZOuYQhoJ/eOO5shCkS7ygG+LIMFH+p7COYF1LdkX28qnTR RU3IrsKnEVwwWgIKnRkhDqr3xxpB1M8fmiCc4i+4ky1hPbn2EoGkWW2suVHHIg==
Message-ID: <56619f9c-e6fb-45e8-a137-4be2993ae895@denic.de>
Date: Thu, 09 Jan 2025 13:19:00 +0100
MIME-Version: 1.0
From: "kowalik@denic.de" <kowalik@denic.de>
To: Mario Loffredo <mario.loffredo@iit.cnr.it>, "Andrew Newton (andy)" <andy@hxr.us>
References: <10ba3faa-8bf7-4202-81bf-e2c99473c3db@denic.de> <10BE3B85-4538-49C5-AB98-4EDDCDCF2B5F@verisign.com> <a872a3d3-ca80-4fbc-b747-b3738e857dae@denic.de> <F6BD2F41-C0E6-4892-B9DA-920A62A46CC5@verisign.com> <7fc24d8e-f845-4e62-b164-cf6dcaa39915@denic.de> <02044771-6C63-466D-88F4-FD08B270F4F3@verisign.com> <beb2763a-97ea-4e71-b144-45c5a3501042@denic.de> <EFD94C63-7AA1-400A-9A38-F7696409686A@verisign.com> <ba62eea0-6861-4b7b-9d5b-75ae4fae571c@iit.cnr.it> <CAAQiQRf+erCuYquLN25nAEcExe1CqEyhhF8pTX-SvVM-5TnYsw@mail.gmail.com> <38d4f728-44f3-49bb-b52f-037a806c2d68@iit.cnr.it> <a8e01119-2f44-4eef-a7cb-0016a2e91467@denic.de> <7216918c-22d6-4817-987a-870c97d926db@iit.cnr.it>
Content-Language: en-GB, de-DE
In-Reply-To: <7216918c-22d6-4817-987a-870c97d926db@iit.cnr.it>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms070504080005090708070200"
X-MBO-RS-ID: e10e5d7f45e4b47bbdb
X-MBO-RS-META: s79ukh6jbq18rtz7rg7gtwxzq1mww3dm
Message-ID-Hash: KI4SVL2YFRUO5C772Z4RE7565JSGTFQL
X-Message-ID-Hash: KI4SVL2YFRUO5C772Z4RE7565JSGTFQL
X-MailFrom: kowalik@denic.de
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
CC: "Gould, James" <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [regext] Re: RDAP versioning - on client-server interactions and 2-RTT flow
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/M9Rc85NoV8fJZAUM74GItGI20w4>
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 Mario,

On 09.01.25 12:17, Mario Loffredo wrote:
> In conclusion, I do believe that the RTT-flow is needed to efficiently 
> implement a possible transition process and the rdap-versioning spec 
> is helpful in this respect.

This was exactly my point, that with the current draft 2-RTT would be 
eventually a must making the version negotiation client driven.

This poses a serious issue with redirects, where you would have to 
interrupt automatic redirect of your client and do 2-RTT with the 
redirect target to replace query parameters fitting the redirect target.

My alternative proposal was heading into direction of fully server 
driven content negotiation leveraging properties of semantic versioning. 
So client telling what versions it supports without prior knowledge of 
versions supported by the server and the server responding with a best 
fitting answer instead of falling back to the default version as the 
draft proposes now.

Kind Regards,

Pawel

v2.31.3 | Report a Bug | By Email | System Status