Hi, For a start, these breaking changes are being listed for a revision with the same extension id. The deprecation point does not seem relevant here.
"Removing a required protocol element from a response;" seems fine as-is. The "Breaking Changes in Revisions” section is basically saying if you want to revise an extension (same id) instead of replacing it (new id), don't do these breaking changes. Looks like a replacement would be more suited for deprecation, no? Jasdip From: Andy Newton <[email protected]> Date: Thursday, July 2, 2026 at 1:59 PM To: [email protected] <[email protected]> Subject: [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-13.txt On 02-07-2026 9:56 AM, Pawel Kowalik wrote: > 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.". > > 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. Strictly speaking, "fully deprecated" works. Practically, there is not a good way to know when something is fully deprecated. I don't know what the right.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
