Hi Scott,
please find my comments inline.
Il 18/07/2022 15:11, Hollenbeck, Scott ha scritto:
-----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".
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.
Why should a response field be renamed when the new version differs from
the old one only for the presence of an optional member?
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?
Best,
Mario
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
