[regext] Re: draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query Identifiers

["[e-mail]" <[e-mail]>]

Hi Jim,

draft-ietf-regext-rdap-extensions is aimed to define the framework of 
RDAP extensions. This must include definition of the relations between 
versions of the same extension which will apply also to the extensions 
not aware or implementing draft-ietf-regext-rdap-versioning, like all we 
have in the IANA registry to date. It does belong there.

draft-ietf-regext-rdap-versioning cannot do it being an extension itself 
and without relation to extensions not implementing it (e.g. all 
existing to date).

Finally, not sure where you see a contradiction. A "breaking change" is 
a change of extension interface, the same as "non-breaking change" is a 
change to the interface. The difference is that for the first the 
clients shall be aware and update the code, for the seconds clients will 
continue working intact.
RDAP is using loose convention to allow such expansion without breaking 
things. We should not cause operational burden of running several 
versions in parallel even if they are perfectly back compatible.

Kind Regards,
Pawel

On 11.06.26 18:36, Gould, James wrote:
>
> Pawel,
>
> I still don’t get the focus on breaking changes instead of extension 
> interface changes. Interoperability is not just about breaking changes 
> but support for the interface changes.  RDAP is extensible and we 
> don’t need to bake everything into draft-ietf-regext-rdap-extensions, 
> since it’s updating STD 95.  We’ve extended EPP over 20+ years without 
> having to update STD 69 and I don’t see extension versioning requiring 
> an update to STD 95.  As pointed out previously, any point version 
> extension should include a normative reference to the versioning 
> extension and we can solidify that with language in the versioning 
> extension, so there is no issue with non-supporting clients for point 
> versioning.  The opaque versioning can include a change in the 
> extension identifier when there is a change in the interface whether 
> there is a breaking change or not.  We can work out the approach for 
> transitioning to the new version of the opaque extension independent 
> of having to update STD 95.
>
> Thanks,
>
>  --
>
> JG
>
>
> cid87442*image001.png@01D960C5.C631DA40
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *Pawel Kowalik <[e-mail]>
> *Date: *Thursday, June 11, 2026 at 12:20 PM
> *To: *James Gould <[e-mail]>, "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] Re: 
> draft-ietf-regext-rdap-x-media-type and 
> draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query Identifiers
>
> Hi Jim,
>
> The goal shall remain to make non-breaking changes possible and 
> breaking changes visible - with or without versioning extension.
>
> I strongly believe most of the extensions will remain back-compatible, 
> because it's healthy for the ecosystem. A coordinated version 
> migration on scale of RDAP usage with multiple server instances and 
> countless client instances not having any contract with each other is 
> challenge comparable to DNS flag days. We don't want that happening 
> for RDAP extensions.
>
> Having told that, an extension identifier as a signal of an extension 
> still being back compatible despite new version rolled out is a 
> reasonable choice which will work in all cases. Versioning extension 
> as an additional information what the version actually is with a 
> facility to request a certain version, is a useful addition, but still 
> optional addition from the protocol view.
>
> draft-ietf-regext-rdap-extensions, as updating STD 95, is the only 
> place where we can sharpen understanding of the contract between a 
> client and the server as to what constitutes a breaking change and 
> what not. Versioning extension draft cannot cover for it, unless it 
> would also be an update to STD 95.
>
> Kind Regards,
> Pawel
>
> On 11.06.26 18:05, Gould, James wrote:
>
>     Pawel,
>
>     Thank you for defining what a breaking change is.  The phrase
>     “parse the response or misinterpret the response” is very broad
>     and would assume not to include the addition of members.  One
>     issue is that many of the members are optional, so the lack of a
>     member of an optional member should not be considered a breaking
>     change.  One aspect to consider is the viewpoint of a client that
>     is expecting the new version of the extension, where if there is
>     no signal (e.g., changing of the extension identifier for opaque
>     versioning) of an interface change (e.g., adding new features and
>     members) they may run into an issue with the broad “parse the
>     response or misinterpret the response” language.  I believe it’s
>     best to change the opaque versioning for any interface change and
>     not for just breaking change of the new extension from the old
>     extension version.  Adding new features is an interface change
>     that warrants version signaling to me.
>
>     I believe the approaches outlined in the sub-sections of 5.4
>     draft-ietf-regext-rdap-extensions apply only to opaque versioning
>     and need to be moved into draft-ietf-regext-rdap-versioning, where
>     appropriate.  I don’t agree with the approaches outlined in
>     section 5.4.3 and section 5.4.4.  I believe it’s best for the
>     server to support a default version of an extension and to support
>     another version of the extension upon request, as defined in
>     section 3.2 of draft-ietf-regext-rdap-versioning (query parameter
>     or media type parameter).  This approach has worked in EPP, where
>     when the client supports multiple versions of an extension as
>     defined by the login services, the server defaults to the latest
>     version.  This was done for the DNSSEC extension and the registry
>     fee extension. Since RDAP doesn’t have the concept of login
>     services, the server can default to the latest version of an
>     extension and provide the information and the capability of the
>     client to choose the version desired.  We can add the
>     relationships of the opaque extension versions into
>     draft-ietf-regext-rdap-versioning to help with this for opaque
>     versioning in the /help response.
>
>     Thanks,
>
>      --
>
>     JG
>
>
>     cid87442*image001.png@01D960C5.C631DA40
>
>     *James Gould
>     *Fellow Engineer
>     [e-mail]
>     <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>     703-948-3271
>     12061 Bluemont Way
>     Reston, VA 20190
>
>     Verisign.com
>     <http://secure-web.cisco.com/1rCWVSrQwClgZQrFjfeQJfgwcyPH3PAnBUEOSSUx-JpwtAtcyF3BUH3KxJQiuHKGr_FgyKu8g0K47Z28AkCjRfiSKpo5VzcY93YfB8yvnGGwapWsnOIBvthmVZLu0ZiflXdnM6VRg7sVLyH4-K80Mh66zsz7vNWiWfxlAGsip-Ckpvr-zZnNn7SCt1gFN-i2snJs1lrurJ7lTIiwa1Nt9cALV4advw3Hg8AFzppmCOD6XSF44C7tyaZ3TL0cvHESO1kgCvBrvM70NBtW1rvUPXyzuz3tmBCQozlAutSpj724/http%3A%2F%2Fverisigninc.com%2F>
>
>     *From: *Pawel Kowalik <[e-mail]> <mailto:[e-mail]>
>     *Date: *Thursday, June 11, 2026 at 11:15 AM
>     *To: *James Gould <[e-mail]>
>     <mailto:[e-mail]>, "[e-mail]" <mailto:[e-mail]>
>     <[e-mail]> <mailto:[e-mail]>, "[e-mail]"
>     <mailto:[e-mail]> <[e-mail]>
>     <mailto:[e-mail]>, "[e-mail]"
>     <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>     *Subject: *[EXTERNAL] Re: [regext] Re:
>     draft-ietf-regext-rdap-x-media-type and
>     draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query
>     Identifiers
>
>     Hi Jim,
>
>     a breaking change is the one that makes the client to either not
>     being able to
>     make a valid request,  parse the response or misinterpret the
>     response, which otherwise
>     would work with the previous version of the extension.
>
>     It may be a change to format, syntax or semantics of an existing
>     field,
>     removing or renaming or a field (both mandatory and optional - the
>     latter would let client believe a value is not there which may
>     have a semantic meaning).
>     There are similar considerations related to path segments, request
>     parameters and referrals.
>
>     What I notice now is that draft-ietf-regext-rdap-extensions-12 is
>     in fact referring to a breaking change without really defining it.
>     Only 5.4.2. is specifying what is a non-breaking change, which may
>     imply that anything else is breaking. This may be fine, as long as
>     5.4.1 would tell it explicitly.
>
>     Kind Regards,
>     Pawel
>
>     On 11.06.26 14:39, Gould, James wrote:
>
>         Pawel,
>
>           
>
>         I want to understand what you're defining as a non-backward compatible change in RDAP, since most of the members returned are optional and the protocol requires ignoring unrecognized members, which differs from a provisioning protocol.  Removing of a member should not break the client and renaming a member should similarly not break the client.  Changing of the extension identifier could break the client if they need the extension using the old extension identifier.  There is no way to foresee what will break a particular RDAP client.  The best that the protocol can do is to provide support for the version information and to enable the client to discover and to indicate what extension version is desired.  As pointed out previously, any RDAP extension that choses to use the point versioning type should include a normative reference to the versioning extension.  A client and server adding support for a point versioning extension needs to also add support for the versioning extension.  We can add language to the draft to reflect that requirement.  A similar case would be made if an extension decided to use another versioning type defined by the versioning extension (e.g., extension identifier versioning that Scott brought up; although no official name has been given), with the exception of the opaque versioning that is there for backward compatibility and as an option for those that chose that type going forward.  We may want to add relationships in the versioning extension for opaque version extensions to provide the visibility of changes, such as stating that "example1" is a successor of "example0" and that "example0" is a predecessor of "example1".  Would this he helpful?
>
>           
>
>         In summary, the onboarding support of the versioning extension should be handled by the normative reference from new RDAP extensions that choose to use a type other than opaque versioning, so there should be no non-supporting clients of a point versioning RDAP extension.
>
>           
>
>         Thanks,
>
>           
>
>         -- 
>
>           
>
>         JG
>
>           
>
>           
>
>           
>
>         James Gould
>
>         Fellow Engineer
>
>         [e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]> <mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>           
>
>         703-948-3271
>
>         12061 Bluemont Way
>
>         Reston, VA 20190
>
>           
>
>         Verisign.com<http://verisigninc.com/> <http://secure-web.cisco.com/1Kjr6vhSbc6njskjsjxYUi8KOFBKvIdnK5vQS1s-v9N_MZgjrFSRd7H4cD5hSR3JwXrsUZH3uWbMODqllqDA_qQLPZyKaR_ZVfSQzOBflD8eyfzbXB24RJX_ydzGn2tZ8wgNERl7kArCNiBXSzczkggIK_gbQC_Fp6_VmOMkN4jBVPK5L6xfnuG6pNbUPpU2cRqYmqRKUIPS8mAwKP8IDzKPfxpV-sX-k1MxUrwo-zoqoH4piLBOW3vZ7CrkamXk08Gv58QJNOlJJ0ysyCyWt7v0rHYiaNoDeqkQCtHOBg-Y/http%3A%2F%2Fverisigninc.com%2F> 
>
>           
>
>           
>
>           
>
>           
>
>         On 6/11/26, 8:06 AM, "Pawel Kowalik" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>
>           
>
>           
>
>         Hi Jim,
>
>           
>
>           
>
>         the question is about a scenario:
>
>         - existing extension in version 1 in production, no versioning deployed
>
>         because not yet specified (applied to any of existing extensions to date)
>
>         - the extension upgrades to version 2, which is not back-compatible with
>
>         1, assuming extension identifier does not change as you propose and argument
>
>           
>
>           
>
>         How would this scenario work for
>
>         a) a client which implements versioning draft vs. client which does not
>
>         b) a server which implements versioning draft vs. client which does not
>
>           
>
>           
>
>         It's a simple matrix 2x2.
>
>           
>
>           
>
>         You may add additional example of the same if version 2 has a hard
>
>         requirement for implementers to also implement versioning.
>
>           
>
>           
>
>         Kind Regards,
>
>         Pawel
>
>           
>
>           
>
>         On 11.06.26 13:45, Gould, James wrote:
>
>             Andy,
>
>               
>
>             Inclusion of some query/response examples for supporting and non-supporting clients are reflected in the following draft-ietf-regext-rdap-versioning figures:
>
>               
>
>             1. Non-supporting - Figure 8: RDAP Domain Lookup Response with No Client Specified Versioning
>
>             2. Supporting - Figure 9: RDAP Domain Lookup Response with "point_ext1-0.1" Extension Version
>
>             3. Supporting - Figure 10: RDAP Domain Lookup Response with "point_ext1-0.1" and "opaque_ext2" Extension Versions
>
>               
>
>             The only indication for the server whether the client is non-supporting or supporting is based on the inclusion of the Extension Versioning Request in Section 3.2. From an implementation perspective, a client will receive the "versioning_data" member that can be used by the supporting client to understand the extension versions included in the response and can be used for troubleshooting by a non-supporting client. The "versioning_data" member is in addition to the "rdapComformance" member and can be easily mapped based on indexing by the extension identifier.
>
>               
>
>             Since we have no experience with an extension transition in RDAP, we can look to the experience with an extension transition in EPP, which has been done many times. In EPP, our implementation was to return a default version based on the latest supported version of an extension. If a client does not support the latest supported version, based on the login services, the server returns the earlier supported version of the extension. For RDAP, the server can return the latest supported version of the extension and allow for the client to specify an earlier version of an extension using the Extension Versioning Request (query parameter or media type parameter) in Section 3.2 of draft-ietf-regext-rdap-versioning. The /help can also be used for automatic discovery of the extension versioning or manually for troubleshooting issues. The discovery can be done infrequently (e.g., daily), since the RDAP servers don't change their extension versions very often.
>
>               
>
>             I hope this helps.
>
>               
>
>             Thanks,
>
>               
>
>           
>
>           
>