> -----Original Message----- > From: Mario Loffredo <[email protected]> > Sent: Monday, July 18, 2022 10:51 AM > To: Hollenbeck, Scott <[email protected]>; Gould, James > <[email protected]>; '[email protected]' <[email protected]> > Cc: '[email protected]' <[email protected]> > 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. > > Hi Scott, > > please find my comments inline. > > Il 18/07/2022 15:11, Hollenbeck, Scott ha scritto: > >> -----Original Message----- > >> From: Mario Loffredo <[email protected]> > >> Sent: Monday, July 18, 2022 4:40 AM > >> To: Gould, James <[email protected]>; [email protected] > >> Cc: Hollenbeck, Scott <[email protected]>; [email protected] > >> 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". > > Speaking technically, renaming a field name is considered a breaking change. > Even admitting that the server can provide both the field versions for a > period of time, the old version will be finally deleted and deleting a field > is a > breaking change too. > > It's true that a transition process can geatly reduce the risk of breaking > the > clients but, in my opinion, it doesn't make sense to adopt such a time- > consuming approach also for additive changes.
[SAH] OK, I get the issue with long term backward compatibility when support for features is removed. That will exist no matter how clients and servers address extension identification. So instead, let's assume that the server doesn't deprecate support for "foov1". Field names remain distinct, and clients can use whichever version they wish. > Why should a response field be renamed when the new version differs from > the old one only for the presence of an optional member? [SAH] Because it is, in fact, different. A client would need to know that an optional member might be present. > Think that the scenario is even worse when the new version of an extension > consists in adding a new endpoint to a set of previously defined endpoints. > > Why should the existing endpoints be affected by the introduction of a new > endpoint? [SAH] Existing endpoints don't need to change when a new extension endpoint is added. Note that the federated authentication draft (identified by the prefix "roidc1"), for example, includes new session management endpoints that don't change the endpoints described in 9082, even though 9082 is being extended. If I ever write a draft for an extension identified by "roidc2" that includes a new endpoint, the endpoints identified by "roidc1" don't necessarily have to change. The "roidc2" extension could address only the new features, leaving the "roidc1" definitions alone. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
