Hi,
Il 02/07/2026 15:56, Pawel Kowalik ha scritto:
Hi,
On 02.07.26 14:41, Andy Newton wrote:
Additional suggested change:
Section 5.4.1
OLD
Removing a required protocol element from a response;
NEW
Removing a required protocol element from a response that has not yet
been fully deprecated;
Is this really necessary? Why would a protocol element be in an
extension if it was fully deprecated?
[ML2] This is inherent in managing the transition period from the
old to
the new one.
At some point, the old version will be removed from the response.
Therefore, stating that removing a required protocol element from a
response is a breaking change seems to me equivalent to stating that
required protocol elements can never be removed, even if they have been
completely deprecated and all clients have switched from the old
version
to the new one.
I see your point. I'll add this.
I just wanted to point out, that fulfilment of this condition can
never be stated with certainty by the server "clients have switched
from the old version to the new one.".
{ML] Unless you are saying that old versions must be kept forever, at a
certain time a server decides that it's time to remove the old version
because it evaluates low to zero the probability of breaking a client.
Basically client has no way to tell the server if it switched or not,
because it happens only after the response has been received from the
server.
Also in most cases not every client is even known to the server, when
out-of-band approaches would come into consideration. Only in case of
restricted access RDAP with authentication of clients this may be
considered at all.
In terms of interoperability it is something different if the client
would notice the extension it used to process is not there any longer
as opposed to receiving a response with a known extension identifier
but with the content which cannot be processed.
[ML] Unless a client implements some sort of defensive parsing, the
result seems identical to me.
From the perspective of the effort required for both clients and
servers to align their implementation to the new version, the two
strategies are not at all comparable.
Forcibly maximizing the scope of any breaking change seems messy to me
and the opposite of what REST API developers are used to.
I could be wrong, but I believe the direct consequence will be that
extension providers will write specifications that define as many
sub-extensions as there are core components of the extension (e.g., JSON
names, URLs, etc.).
Conversely, if we want to allow extension providers to choose the scope
of a change in their extension (including the option to turn a breaking
change into a non-breaking change + a deprecation process of specific
extension components), we should ensure that the `exts_list` parameter
includes the extension versions as defined in the versioning draft.
This would provide servers with more information about when it's
appropriate to remove the old version.
Best,
Mario
Kind Regards,
Pawel
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
