Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 18 July 2022 13:11 UTC

Return-Path: <shollenbeck@verisign.com>
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 57027C14F6EC for <regext@ietfa.amsl.com>; Mon, 18 Jul 2022 06:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 22PefY51khjQ for <regext@ietfa.amsl.com>; Mon, 18 Jul 2022 06:11:14 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCBDC14CF08 for <regext@ietf.org>; Mon, 18 Jul 2022 06:11:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4418; q=dns/txt; s=VRSN; t=1658149875; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=FXeOp4kMLjAqublw0mw6kjc9x4YbFbGRim0Pk1GPyng=; b=imoesqlxXHucdzuGrJLIyRjwo7nPqyRoKInFhjPm0S3aONiZ5+FRGN1C OHTDJyqzotHeUggM6dL2ttABfWz4UlIV/k/je02tByv4xJW9NGGmTKbxa yFgtvLAettBEauy8STUP7DhOggY3VV0bK2Rec5dXciGWggSbNdW7ORebQ avJek57ZhHgy86a/9bsnNDSkCTSBR4FxiWR6eQXCY9XbLPQorJ9hMQM7s RCUMq9+sbGwhQ2pby/fgKJCwMnnOQ6POhA695hkkkXv2wjpNdq5C2BM6/ qNlK5ACxwi/Zlf6RBF6tmaqQOdFPFqIKyspL5NtgaVLMVzluTuFIpnDYL g==;
IronPort-Data: A9a23:yd9myK6SOlnFF/l6tXWhUAxRtEPGchMFZxGqfqrLsTDasY5as4F+v jEXWT/XPvbfYWChL9x2Pdyw8h4DuJ/Xy4U1S1M6qXhgEysa+MHIO4+Ufxz6V8+wwm8vb2o8t plDNYOQRCwQZiWBzvt4GuG59RGQ7UwML1bFILas1hpZHGeIcw98z0M58wIFqtQw24LhXFrd4 YqaT/D3YzdJ5RYlagr41Ire8HuDjNyq0N/PlgVjDRzjlAa2e0g9VPrzF4noR5fLatA88tqBe gr25OrRElXxpE5xV4z/wt4XRWVRKlLaFVDmZnN+BfD+0kAazsA4+v5T2PE0MS+7h9gV9jzYJ RokWZGYEG8U0qPwdOs1UwlHCipbHJV/+pDqEyGQ8u+16H3MfC65qxluJBle0Yww0NxRWF5o2 MxAcnYTZReZn6S/zPSlUPJqwM8kKaEHPqtG4jc5kmqfVKt9B8ySK0nJzYYwMDMYncBJGfLTY cAUYjlHchnaYgZONVFRA5U79AutriCiLmYC8AzOzUYxy1SO6Sgq9uHuCcXqRtybTOVctHzGm EuTqgwVBTlfbrRz0wGt93u2h+iJmST1VpgfGLqQ9/92xlaV3CoSFHU+V1S8vP213xLmRd9FK lcV9Sxopq833ECuR8P2GRy1vHDCuQQTM/JZFeErwAGd0OzJ+G6xHGULQy5dQN0rqMFwQiYlv mJlhPvjHzo2r7uYWSrHs6yKt3W3ODNQJ2hEbzUCFE0b+cLl5oo0i3ojU+peLUJ8tfWtcRmY/ txAhHJWa2k75SLT65iGwA==
IronPort-HdrOrdr: A9a23:mN2YkKmMWgl0snQ0pSHHM38EdoTpDfIO3DAbv31ZSRFFG/Fwz/ re+Mjy1XfP5Ar5K0tQ/uxoX5PwO080lKQFmrX5Uo3DYOCLggGVxcRZnO7fKl7balDDH4xmpM RdmsFFYbWaMbE5t7eZ3ODSKbkdKay8kZxA8t2x854Cd2xXgupbnmFE406gYzRLrSd9dOIEKK Y=
X-IronPort-AV: E=Sophos;i="5.92,281,1650945600"; d="scan'208";a="15532063"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.28; Mon, 18 Jul 2022 09:11:02 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) by BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) with mapi id 15.01.2375.028; Mon, 18 Jul 2022 09:11:02 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "'mario.loffredo@iit.cnr.it'" <mario.loffredo@iit.cnr.it>, "'jgould=40verisign.com@dmarc.ietf.org'" <jgould=40verisign.com@dmarc.ietf.org>, "'andy@hxr.us'" <andy@hxr.us>
CC: "'regext@ietf.org'" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
Thread-Index: AQHYmEQ9tunyk/PrlEesJ8OT8blWMK2EFlUA///1Y1A=
Date: Mon, 18 Jul 2022 13:11:02 +0000
Message-ID: <56cde22c2e7349faa86fb2c0deae6e4f@verisign.com>
References: <0C87A351-7EC7-4684-BF7A-FAB0EA12677E@verisign.com> <85387f48-2443-2e27-74f1-025e24ec8224@iit.cnr.it>
In-Reply-To: <85387f48-2443-2e27-74f1-025e24ec8224@iit.cnr.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/gAiDAFRUX1Yz0NngZR4V5aW9nvc>
Subject: Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
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, 18 Jul 2022 13:11:18 -0000

> -----Original Message-----
> From: Mario Loffredo <mario.loffredo@iit.cnr.it>
> Sent: Monday, July 18, 2022 4:40 AM
> To: Gould, James <jgould=40verisign.com@dmarc.ietf.org>; andy@hxr.us
> Cc: Hollenbeck, Scott <shollenbeck@verisign.com>; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] OK, What Next? (was RDAP Extensions
> Approach Analysis v2)
>
> 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.
>
> I agree with James.
>
> The drawback of Approach A is that even an additive change to an existing
> extension would result in a breaking change to the RDAP service. As a
> consequence,  servers should always manage the transition from two
> subsequent versions of an extension.

Please explain how there's a breaking change. Let's assume that we have an 
extension named "foo version 1" identified by the prefix "foov1". "foov1" is 
registered with IANA, returned in the server's rdapConformance data structure, 
and used to prefix extension elements.

Now assume that a second version of the extension (foo version 2) exists, 
identified by the prefix "foov2". "foov2" is also registered with IANA, 
returned in the server's rdapConformance data structure, and used to prefix 
extension elements.

If the server supports only "foov1" or "foov2", it returns only one of those 
values in the rdapConformance data structure, accepts only extension elements 
prefixed with the supported value, and returns only extension elements 
prefixed with the supported value. If a server supports both "foov1" and 
"foov2", it returns both values in the rdapConformance data structure, accepts 
extension elements prefixed with either value, and returns extension elements 
prefixed with the value that matches the requested value. So how does this 
transition scenario not work?

Server supports "foov1" and returns that value in the rdapConformance data 
structure. The server accepts requests and returns responses prefixed with 
"foov1". The client sends requests and receives responses prefixed with 
"foov1".

At some point in the future a new version of "foo", identified by "foov2", 
exists. The server enters a transition period and announces support for both 
extensions by returning both values in the rdapConformance data structure. It 
accepts extension elements prefixed with either value and returns extension 
elements prefixed with the value that matches the requested value. The client 
sends requests and receives responses prefixed with either "foov1" or "foov2" 
depending on which value of the extension they support.

Time passes, and the transition period ends. The server deprecates support for 
"foov1" and announces support for only "foov2" by returning only that value in 
the rdapConformance data structure. The server accepts requests and returns 
responses prefixed with "foov2". The client sends requests and receives 
responses prefixed with "foov2".

Where's the breakage here? In both cases, the client and server can identify 
extension elements by doing a simple pattern match for "foov1" or "foov2".

Scott