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,
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
