Andy, Andy,
I don’t believe the bumping of “rdap_level_0” to “rdap_level_1” would be based on whether “rdap_level_1” is backward compatible with “rdap_level_0”, but whether “rdap_level_1” is functionally different. If “draft-ietf-regext-rdap-extensions” updates the base RFCs by adding new functionality, that warrants bumping “rdap_level_0” to “rdap_level_1”. You bring up an excellent point in section 2.3.2 of draft-ietf-regext-rdap-extensions on whether extension by query parameter is supported by the base RFCs, which I believe needs to be discussed more fully by the working group. Is the language in RFC 7480 that only mentions JSON extension by path segment and JSON members considered normative and disallows the other forms of extensions, such as query parameters (RFC 8982, RFC 8977, RFC 9560, draft-ietf-regext-rdap-versioning), HTTP headers (draft-ietf-regext-rdap-x-media-type), “objectClassName” member value (yet to be defined but required for new RDAP objects), and other forms yet to be defined? If RDAP extension by query parameter is disallowed by RFC 9082, then extension by HTTP header and “objectClassName” member value is also disallowed. I believe that draft-ietf-regext-rdap-extensions needs to address all forms of RDAP extensibility that currently exists (e.g., path segment, query parameters, HTTP header) as well as those that could happen in the future (e.g., “objectClassName” member value). EPP defined multiple forms of extensibility with the Object-level extension and the Command-Response extension being the only forms that were used in RFCs. The EPP forms match well to the RDAP forms that I listed below, where the Object-level extension maps to the Path Segment, JSON Names, and “objectClassName” Member Value RDAP extension forms and the Command-Response extension maps to the JSON Names, Query Parameters, and HTTP Headers RDAP extension forms. We also need to determine whether formally defining all these forms of RDAP extensions in draft-ietf-regext-rdap-extensions triggers the need to update RFC 7082, RFC 9082, and RFC 9083, which then triggers the need to bump “rdap_level_0” to “rdap_level_1”. An example, if “rdap_level_0” did not support RDAP extension by query parameter, then a client will know that the server supports all extensions that do include RDAP extension by query parameter by returning “rdap_level_1” in the rdapConformance member of the help response and the query responses. The same goes for the other forms of RDAP extensions. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineerm 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/> From: "Andrew Newton (andy)" <a...@hxr.us> Date: Monday, October 7, 2024 at 7:04 AM To: James Gould <jgo...@verisign.com>, "shollenbeck=40verisign....@dmarc.ietf.org" <shollenbeck=40verisign....@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04 Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 10/3/24 08:26, Gould, James wrote: Andy, I view updating the base RFCs as being a material change that would trigger the need for signaling for interoperability via use of “rdap_level_1”. If what is defined maintains backward compatibility with what is defined in the base RFCs, then can a case be made for not having to update them? I don’t believe we can have it both ways. See my note to Scott, but these are all backwards-compatible changes. If there are any incompatibilities, specific examples would be helpful. Also note that changing "rdap_level_0" to "rdap_level_1" introduces its own compatibility issue. This document updates the core RDAP specs for two reasons: 1) they define the rules around extension registrations, many of which this working group has broken but have caused no harm, and 2) there are areas of those documents concerning extensions that are very ambiguous. But this document changes nothing with regard to current interoperability between a client and server. I’m in the middle of re-reviewing draft-ietf-regext-rdap-extensions and a good point is made related to the forms of RDAP extensions supported by the base RFCs, based on section 2.3.2 “Usage of Query Parameters”. RFC 7480 with “used in JSON [RFC7159<https://secure-web.cisco.com/16n6UMc3QOMV5xQcbhp3fNUTgqfFYv99RLBb5f239kiZRHrfyuElr7LQwZoa4MgEd4BScDS6tMbmTyO1RNoK_gIhDeu8tMtVs3IhEiypwf73PZSs2AlgLoy7wyFPtb2rgvpuDzfKYMMLza_uXps1Kx0F1H-ElOSfwTud9PBdUdbZm2U7_3uMfXWaDz2RDG4-ZESm_lB4mrIK6g_HIdpwB6yWkznCYK2oO5YulpSCpM_dH4odcnpaGULNzoFtxrU9xlJqgcBPy7Dmix1F7V5DtLXZ_vCC0C-uqTzi1HohnJU8/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7159>] data serialization and URI path segments”, RFC 9082 with “Custom path segments can be created for objects not specified here using the process described in Section 6<https://secure-web.cisco.com/1PYPcxYXIrwX_8n1DqYQuKA7wAo4XgdHjsadiD2AlwHx1wPyrPqdiYPXvp-9fTm63Y729YozCkE6CZNPQQFxWW_UJEWJkwFO9Vycfu6BC6wNTNPbmBOhp8n1BHnjQardN75CwK5_I--KqSE42nVFKcokttIjdb0nxPVjDhD8y_5hq84m635jJAj_FbJNGjqHBRngRulnHfYQojhqDHwy7GAb3bTiqf0BXAVuQoW3KztHFgyvZqB9ZZMt6RBEeUFI8gEEUzvCxodNv_NDicuvVNei-0MykOrf4CVdeaykgK-c/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7480%23section-6>of "HTTP Usage in the Registration Data Access Protocol (RDAP)<https://secure-web.cisco.com/1dNCy4_6E4eD8SwcNWG7ZxHO7ufbBkHbY2nFbOYcZhxOeLWfyB92jGfT1G_kjo4GJSVzn4iba5tTv1FqU5WIIPcLUKBiSa32_iGHvh-jX_6FaIV_DrypP9rvmvAsYjK7QdWYDK54Pu663hlu_2HBEAXHrjWEZKLCIUA0itcIip5vJGuE3unlj1SyiS7vslOSjqG-8Wvq-cuRPgXXOBWesHzlcjvl9oeYS74Y6xIStYseq1wBJ4Q7rM_oPihUfM10gw09xrwOHvjXXHK5k0YDrKBAarKqApW8cbT2oOsSyL38/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7480>" [RFC7480<https://secure-web.cisco.com/1dNCy4_6E4eD8SwcNWG7ZxHO7ufbBkHbY2nFbOYcZhxOeLWfyB92jGfT1G_kjo4GJSVzn4iba5tTv1FqU5WIIPcLUKBiSa32_iGHvh-jX_6FaIV_DrypP9rvmvAsYjK7QdWYDK54Pu663hlu_2HBEAXHrjWEZKLCIUA0itcIip5vJGuE3unlj1SyiS7vslOSjqG-8Wvq-cuRPgXXOBWesHzlcjvl9oeYS74Y6xIStYseq1wBJ4Q7rM_oPihUfM10gw09xrwOHvjXXHK5k0YDrKBAarKqApW8cbT2oOsSyL38/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7480>]”, and RFC 9083 with “The full JSON name (the prefix plus the underscore plus the meaningful name) SHOULD adhere to the character and name limitations of the prefix registry described in [RFC7480<https://secure-web.cisco.com/1dNCy4_6E4eD8SwcNWG7ZxHO7ufbBkHbY2nFbOYcZhxOeLWfyB92jGfT1G_kjo4GJSVzn4iba5tTv1FqU5WIIPcLUKBiSa32_iGHvh-jX_6FaIV_DrypP9rvmvAsYjK7QdWYDK54Pu663hlu_2HBEAXHrjWEZKLCIUA0itcIip5vJGuE3unlj1SyiS7vslOSjqG-8Wvq-cuRPgXXOBWesHzlcjvl9oeYS74Y6xIStYseq1wBJ4Q7rM_oPihUfM10gw09xrwOHvjXXHK5k0YDrKBAarKqApW8cbT2oOsSyL38/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7480>]”, but does the lack of definition implicitly prohibit other forms of RDAP extensibility that we know of and that could be defined in the future? Could draft-ietf-regext-rdap-extensions be used to define all forms of RDAP extensibility formally without requiring an update to RFC 9083 and trigger the definition of “rdap_level_1”? I see 5 forms of extensibility that RFC 9083 only references two of the forms: 1. Path Segment * Path segment for defining a new object in the request, which is covered by RFC 7480 and RFC 9082. 1. JSON Names * JSON names for defining new members in the response, which is covered by RFC 7480 and RFC 9083. 1. Query Parameters * Query parameters for defining new request preferences and features, which is NOT covered RFC 7480 and RFC 9082. Many RDAP extensions have leveraged extensibility of query parameters, including RFC 8982, RFC 8977, RFC 9560, draft-ietf-regext-rdap-versioning, 1. HTTP Headers * HTTP headers for defining new request preferences and features, which is NOT covered RFC 7480 and RFC 9082. The draft-ietf-regext-rdap-x-media-type draft leverages extensibility of HTTP headers. 1. “objectClassName” Member Value * Value of the “objectClassName” member for defining a new object in the response, which is NOT covered RFC 7480 and RFC 9083. I haven’t see this form of extensibility in a published extension, but it certainly would be needed if the path segment was extended to support a new object. Are there other forms of RDAP extensibility that should be considered and formally defined? Potentially draft-ietf-regext-rdap-extensions could define a framework for extending the forms of extensions, since it will hard for us to look in the crystal ball to enumerate all possible forms of extensibility now. That's a very good list. Maybe our summary section of the draft should do something similar. I do not understand your suggestion but that maybe lack of imagination on my part. Doesn't such a framework exist in the form of the REGEXT working group? -andy
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
