Hi all, Sorry for not responding to this earlier, but after an extended vacation it took me quite some time to digest the discussion and form an opinion.
We would like you to know that I have published the agenda for IETF114, and we have reserved a 30 minutes discussion on this topic. We would like to thank Jasdip for his excellent summary, although the chairs feel that apart from registration hassle, running code sort of validates tradeoff discussions between all options in server or client reprogramming, but we miss one important aspect that we are actually here to judge about, and that is protocol simplicity. I have my personal opinion about that as everyone, that I will share in a separate post, but for now, please prepare for a discussion during the meeting so the current documents waiting for a resolution can progress after the meeting. Regards, Jim and Antoin > Op 18 jul. 2022, om 15:11 heeft Hollenbeck, Scott > <shollenbeck=40verisign....@dmarc.ietf.org> het volgende geschreven: > >> -----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. > > 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 > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
