Based on feedback received on draft-gould-regext-rdap-versioning at the
IETF-116 REGEXT meeting, Scott Hollenbeck, Dan Keathley, Andy Newton, Jasdip
Singh, and I met to discuss it. The feedback and the results of the meeting
include:
1. Ensuring that the versioning extension is an opt-in
* It was agreed that the versioning extension is not mandatory, where a
server can decide whether to support it, and there are no required changes
needed for the existing RDAP extensions.
* The versioning extension is optional for the client, where the client
does not need to use the help query to discover the extension versioning
information, does not need to specify the extension versions desired in the
query response, and does not need to use the extension version information
included in the query response.
* The goal is to provide the ability for the server to support RDAP
versioning and the ability for RDAP extensions to include versioning
information.
2. The format of the Extension Version Identifier
* The Extension Version Identifier leverages the Extension Identifier
and needs to be a single value (e.g., not broken out in JSON) to support the
client specifying the desired extension versions in the query.
There was additional discussion that included:
1. The help response meta-data is useful for troubleshooting, but there was
doubt that client software would use it to dynamically change their calls.
2. There was not opposition to allowing the client to specify the extension
versions, but Andy had a concern that the query parameter would not work
because of it will not pass with a redirect. There are existing redirection
services that have been setup that pre-cache the bootstrap registry. Andy is
considering creating an Internet Draft that uses a Header instead of a query
parameter for passing client preferences. We will keep the query parameter for
now and will look to move to an approach that does pass with a redirect.
3. We need to look at the major and minor version use cases and the specific
use cases that will cause breakage.
The group will continue to meet to work out the details, but if there is any
additional feedback from the working group, please share it publicly on the
mailing list or privately.
Thanks,
--
JG
[cid87442*image001.png@01D960C5.C631DA40]
James Gould
Fellow Engineer
jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
