Scott, > You can't give drafts, and the content they contain, implementation status > that they don't have. I get the value of implementation experience, but > that > doesn't mean that we can add something to IETF processes that doesn't > exist.
I'm not stating that a draft has the implementation status, but by supporting pointed versioning and minimal client / server impact to draft updates, it will encourage implementations and contribute to the implementation status section. We found the pointed versioning to be very useful with the EPP extensions, which should be reused for RDAP extensions. > [SAH] As I mentioned in my response to Mario, part of the answer may lie in > the server NOT removing support for older versions of an extension if it > wishes to provide backward compatibility. Eventually the support for the old version can and will go away on the server-side, where embedding the version into all the extension elements can create interoperability issues without the prior knowledge of the server. There is no version negotiation in RDAP, so once the old version support is removed, a client implementation can be broken. Using just the RDAP conformance for hinting / signaling the support of the versioned extension(s), can be adjusted by the server with little to no impact to the clients. What is the advantage with embedding the version into the prefix used by all the extension elements? If a common and unique prefix (e.g., "foo") is used for the extension elements (e.g., "foo", "foo_member1", "foo_member2") and the RDAP conformance values (e.g., "foo_level_1", "foo_level_2"), you get the advantage of the extension consistency without the negative side effect of causing interoperability issues when removing support for older versions. -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/18/22, 11:51 AM, "Hollenbeck, Scott" <shollenbeck=40verisign....@dmarc.ietf.org> wrote: > -----Original Message----- > From: Gould, James <jgould=40verisign....@dmarc.ietf.org> > Sent: Monday, July 18, 2022 10:58 AM > To: Hollenbeck, Scott <shollenb...@verisign.com>; mario.loffr...@iit.cnr.it; > a...@hxr.us > Cc: regext@ietf.org > Subject: [EXTERNAL] Re: RE: 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. > > Scott, > > I include feedback embedded below. > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE- > B4BA42740803/jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://secure- > web.cisco.com/1l09ohVR1jHRe9ssf8R6XsOKixnyEIYRwaGWA6p- > _lCHj70APFeZ6ZgDRlKuWVFXsEnCaTDvtDcrLdJbpHVIjnBN3SCYtLDwpglgNIDT > di47- > OZrMRXg4ny6jr9zJIydegMyefFxtlQRFoaU4Ibih8yhUqmt0TSGL43AlkL4gzEIT68 > KarDHGCq7uaJO8vRdk3kqYY99THVX9nX2f6jqQYjqI7GnftfsVSN2ltZ0exH9FuG > e9KmSee2HzYmtCRGRY/http%3A%2F%2Fverisigninc.com%2F> > > On 7/18/22, 9:11 AM, "Hollenbeck, Scott" > <shollenbeck=40verisign....@dmarc.ietf.org> wrote: > > > -----Original Message----- > > From: Mario Loffredo <mario.loffr...@iit.cnr.it> > > Sent: Monday, July 18, 2022 4:40 AM > > To: Gould, James <jgould=40verisign....@dmarc.ietf.org>; > a...@hxr.us > > Cc: Hollenbeck, Scott <shollenb...@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. > > JG - There is an additional case of pointed versioning with an Internet > Draft > ("0.1", "0.2", "0.N" in EPP or "O_1", "0_2", "0_N" in RDAP), where the > pointed versioning will change more frequently than what is reflected in the > IANA registry for RFCs. If changing the hinted version in the RDAP > Conformance also requires changing all the extension elements (path > segments, query parameters, response members, and objectClassName > values), even with backward compatible updates (e.g., inclusion of new > optional feature), it will impact all client implementations, or it will > discourage > the use of pointed versioning to reduce the impact. Implementation to draft > versions does come with risk, but it's important for drafts to get > implementation experience, and we want to reduce the impact of making > version updates. Using pointed versioning has become a best practice in the > creation of the EPP extensions and should be used as well for RDAP > extensions. [SAH] There's a problem with that case, though, Jim: https://secure-web.cisco.com/1-qfhjxpOvFi-jovaCwbvXmpUfuuhuRW3z0CWypNoZS0yNLFBStDEx_pPdLN5KtBql32uSGrM0ms8Djg2TTUeoAdMCmpo1NgxLLbhHN7727Djt0wa1_pV_c6fFy0sSatqDOLyaz04lntrC03IUDzuAkKssFIZ0A3CEKLweiR4acL7g_iwZeM1sykhC-prKfLeUv7EYWU3WGppk3rSA8zymDa02jWUjIeE6udL4WyucV_rr6Cu6fIv60DYxQYoBTaM3HCxxuNmjbUWOkrL_Egedw/https%3A%2F%2Fwww.ietf.org%2Fhow%2Fids%2F "Internet-Drafts (often referred to simply as "drafts") have no formal status, and are subject to change or removal at any time; therefore they should not be cited or quoted in any formal document." You can't give drafts, and the content they contain, implementation status that they don't have. I get the value of implementation experience, but that doesn't mean that we can add something to IETF processes that doesn't exist. > 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". > > JG - There is no true version negotiation of extensions in RDAP like there > is > for EPP, where some extensions only include response members and do not > include extensions of the path segments or query parameters. A server > would need to remove inclusion of the "foov1" response members and only > use the "foov2" response members after some time of overlap. What is the > advantage with potentially breaking the clients that have not been updated > to look for "foov2"? The updated extension could be completely backward > compatible. Support for version 1 and version 2 can be included in the RDAP > conformance with the values ("foo_level_1" and "foo_level_2") for clients > that are interested, but the response members with "foo" can stay as is. > The > same prefix "foo" can be used for the RDAP conformance values and the > extension elements for consistency and guaranteed uniqueness. Non- > backward compatible changes should be discouraged, but if needed the > signaling in the RDAP conformance should provide the client with versioning > information. The RDAP conformance member is meant for signaling > extension support and is well suited to support versioning. Cascading > versioning down to the extension elements can cause interoperability issues > with little to no benefit to the clients, such as returning only "foov2" > instead > of "foov1" or "foov1" with "foov2". [SAH] As I mentioned in my response to Mario, part of the answer may lie in the server NOT removing support for older versions of an extension if it wishes to provide backward compatibility. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
