Andy, I didn't mean to be dismissive of the existence or need of redirection services. I just don't view the redirection services as the primary use case for RDAP servers and the RDAP protocol itself. We can agree to disagree on this.
The reason for the word "claim" is to address a gap that I see in the scope of RDAP-X and the breadth of the issue that you claim there is with query parameters in RDAP. If you're going to create a new media type to pass client-side preferences to an RDAP server, why wouldn't you address the broader case of all query parameters in RDAP instead of focusing on a new feature of extension signaling that overlaps with draft-gould-regext-rdap-versioning? Please clarify the cases in RDAP where query parameters can and can't be used. One redirection use case is associated with TLD transitions, where both lookup and search queries need to be properly supported. Do you have a similar concern with the retention of query parameters for the TLD transition use case? Thanks, -- JG 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/> On 11/16/23, 10:35 AM, "Andrew Newton" <a...@hxr.us <mailto:a...@hxr.us>> wrote: 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. Jim, You are now stating that redirection is a "special case" and using the word "claim" which I perceive as you being dismissive of the validity of their need. As I have repeatedly written on this list and these threads, redirection is very much used when dealing with the transfer of number resources between the INRs. That is why I specifically referenced Appendix C of RFC 7480 because figure 3 describes the use case. As another example, if you were to query https://secure-web.cisco.com/1ByyQSpniIqHtnsxRXDx81unODISe0eQ3YJ9qlLZaEVNJNwOYI8C5f6YzQskn9bOb8V8omhSkbDI-W3hNw5bVZjh1CYPd6sKlNJj9VEbHRxj-63dXAlwxfV3zVPUhzVBy3hkgRcXZ0oNsMNX1uYF8yA27uOHUNmiSe3I7SrNTMjhF-uECKRYJYUrTmtjuiaqCWJYPfhiGLdkjmA0Yf8ZAvng2c8hH6-aHC6nCsQ9UX53hfCLMF5rB5R6kI3kuQ1uv3B9wR2L_iepWcu5wY8lFO_Wby5-7Wwu78RBubCs9heo/https%3A%2F%2Frdap.lacnic.net%2Frdap%2Fip%2F190.211.150.1 <https://secure-web.cisco.com/1ByyQSpniIqHtnsxRXDx81unODISe0eQ3YJ9qlLZaEVNJNwOYI8C5f6YzQskn9bOb8V8omhSkbDI-W3hNw5bVZjh1CYPd6sKlNJj9VEbHRxj-63dXAlwxfV3zVPUhzVBy3hkgRcXZ0oNsMNX1uYF8yA27uOHUNmiSe3I7SrNTMjhF-uECKRYJYUrTmtjuiaqCWJYPfhiGLdkjmA0Yf8ZAvng2c8hH6-aHC6nCsQ9UX53hfCLMF5rB5R6kI3kuQ1uv3B9wR2L_iepWcu5wY8lFO_Wby5-7Wwu78RBubCs9heo/https%3A%2F%2Frdap.lacnic.net%2Frdap%2Fip%2F190.211.150.1> you will get back an HTTP 307 with the location header value of "https://secure-web.cisco.com/1Uy8YoZ4y85z7qF77jUZaqauEzcfKKBNsYtpCjJ6h4y3DTWBiyULTvRJBcCegzJzb8wmBiTvDavfsH7-NEqq5bNp3MuQ1GKky0e7ybl_UZZ5eUz8MZJ0IZpWib7tsa8Rye6w9-bgeAiYiDOtCUgYvx8RN8MPkDauPGv7f_dBxV3HpzCaEUsHxKiHCKIoq85WQzFoobWNj_4ZUxcpE3hGCReMlR_TzsPOYSXu1QPvnAmlB-Krphu9_VWQ1IESBMc0at42i8uHqdo12TV2rTa594KfAoTgc1gcfhuSHDlxiMEg/https%3A%2F%2Frdap.arin.net%2Fregistry%2Fip%2F190.211.150.1" <https://secure-web.cisco.com/1Uy8YoZ4y85z7qF77jUZaqauEzcfKKBNsYtpCjJ6h4y3DTWBiyULTvRJBcCegzJzb8wmBiTvDavfsH7-NEqq5bNp3MuQ1GKky0e7ybl_UZZ5eUz8MZJ0IZpWib7tsa8Rye6w9-bgeAiYiDOtCUgYvx8RN8MPkDauPGv7f_dBxV3HpzCaEUsHxKiHCKIoq85WQzFoobWNj_4ZUxcpE3hGCReMlR_TzsPOYSXu1QPvnAmlB-Krphu9_VWQ1IESBMc0at42i8uHqdo12TV2rTa594KfAoTgc1gcfhuSHDlxiMEg/https%3A%2F%2Frdap.arin.net%2Fregistry%2Fip%2F190.211.150.1">. Yet if you look in the bootstrap files you will see that 190/8 points to https://secure-web.cisco.com/1GI1Tol_m1slbyjjwTH-J2Uby2aPfvNjtyJfAu78hvagrbF9bd-J9wGYrUVDR0cDkpavFaj2v9j42ONQW9pUw32FcaEpDTiDejnH9lT_P9Z9E0Vqx_uoPGVG-rIOTNpxcFu59tcFuZTAmnFENfxd7fcDtpzWfb15gh5C6d9XF_R-Py0aoVO8LAXp340QIlaSpedEkRNEk8x6uP1UvMoDESu1r3q3I9D5_dpwRvszN-Y-89oxEfM8wVmCVIC7Qn-bhvSxJKV7dplGkkYHHArQit5dWVvRk3mp6eAiJK4JXN0I/https%3A%2F%2Frdap.lacnic.net%2Frdap <https://secure-web.cisco.com/1GI1Tol_m1slbyjjwTH-J2Uby2aPfvNjtyJfAu78hvagrbF9bd-J9wGYrUVDR0cDkpavFaj2v9j42ONQW9pUw32FcaEpDTiDejnH9lT_P9Z9E0Vqx_uoPGVG-rIOTNpxcFu59tcFuZTAmnFENfxd7fcDtpzWfb15gh5C6d9XF_R-Py0aoVO8LAXp340QIlaSpedEkRNEk8x6uP1UvMoDESu1r3q3I9D5_dpwRvszN-Y-89oxEfM8wVmCVIC7Qn-bhvSxJKV7dplGkkYHHArQit5dWVvRk3mp6eAiJK4JXN0I/https%3A%2F%2Frdap.lacnic.net%2Frdap> What this means is that the bootstrap files are not granular enough to direct clients to the appropriate server and the RIRs are using redirection to get clients to the correct place. Also, you have been dismissive of the RDAP redirection services which are a valid part of the ecosystem and serve a purpose for the simpler clients and for constrained environments. Consider a network operator writing a shell script using curl and jq to find the most specific covering networking of an IP. Using the bootstrap files requires downloading the appropriate file (there are different ones for v4 and v6), sorting the service hosts by "http" scheme, and using an advanced dsa such as a trie or modified bst. Plus to be a good netizen, they need to deal with the cache-control of the bootstrap file. Or they can point curl at a redirect service and not worry about all that. That is, the bootstrap process is doable but it is certainly non-trivial. For constrained environments a local bootstrap service is beneficial as it cuts down on the bandwidth/latency of every client grabbing the bootstrap files. -andy On Wed, Nov 15, 2023 at 2:04 PM Gould, James <jgo...@verisign.com <mailto:jgo...@verisign.com>> wrote: > > Andy, > > You claim that there is an issue with redirection and query parameters. A > client is not required to use the redirection service or a redirection at all > and can directly query the target servers, so I view this as a special case > that you say is best solved with RDAP-X. What I'm requesting is to ensure > that RDAP fully supports query parameters for the existing and future RDAP > extensions and to address the redirection issue in general with use of RDAP-X > as an alternative to query parameters. An RDAP extension can provide > additional client specified options using query parameters and those query > parameters could be passed using RDAP-X as an alternative? The RDAP-X is > focused on signaling of the extensions that should be returned in the > response, which is already being addressed by > draft-gould-regext-rdap-versioning. Address the broader issue instead of > targeting a problem that is already being worked on and let's get past the > query parameter vs. RDAP-X debate. > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com <mailto:jgo...@verisign.com> > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com > <mailto:jgo...@verisign.com>> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > <http://secure-web.cisco.com/1t-esBUF_D6TgXVVFNPaxOsOTbrV5rRwbL4YsqwM4LRk3RCGChDzS9zGML4pHJiLWTc8vr7AgJl-owtqxtnEOyqoZDIrX7pwDKiQEkA2Aef_tIB5L9Cqlm2LfvNNBrsl_axVWeTYWwvF9qlSTXwffbR7ogwOGrLReamBktAY3UELcoiaxIe1qgyT3yaawPNWLPk-BkPVm_n2hKzZANfrekm6Lwr9Vj5urhFbP5IbErJHW2WxgKt_wvUvHZUW4vRipw7Bmwmd2iwnpqcm8oQKHY4iXbhvC75ll95o8r4alot4/http%3A%2F%2Fverisigninc.com%2F> > > <http://secure-web.cisco.com/1t-esBUF_D6TgXVVFNPaxOsOTbrV5rRwbL4YsqwM4LRk3RCGChDzS9zGML4pHJiLWTc8vr7AgJl-owtqxtnEOyqoZDIrX7pwDKiQEkA2Aef_tIB5L9Cqlm2LfvNNBrsl_axVWeTYWwvF9qlSTXwffbR7ogwOGrLReamBktAY3UELcoiaxIe1qgyT3yaawPNWLPk-BkPVm_n2hKzZANfrekm6Lwr9Vj5urhFbP5IbErJHW2WxgKt_wvUvHZUW4vRipw7Bmwmd2iwnpqcm8oQKHY4iXbhvC75ll95o8r4alot4/http%3A%2F%2Fverisigninc.com%2F>> > > > > > On 11/15/23, 1:44 PM, "Andrew Newton" <a...@hxr.us <mailto:a...@hxr.us> > <mailto:a...@hxr.us <mailto:a...@hxr.us>>> wrote: > > > 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 Wed, Nov 15, 2023 at 11:19 AM Gould, James <jgo...@verisign.com > <mailto:jgo...@verisign.com> <mailto:jgo...@verisign.com > <mailto:jgo...@verisign.com>>> wrote: > > > > How about making the RDAP-X hedgehog broader into a super hedgehog by > > solving the more general query parameter issue with redirection services? > > > > > You have understated the problem. The issue is not with redirection > services but with redirects in general. > > > Are you suggesting we add a query parameter that mirrors the > functionality of the media type's extension parameter? If so, does > this work for you? > > > --- > This document defines a URL query parameter named "rdapx_extensions". This > query > parameter has the same syntax as the extension parameter of the RDAPX > media type. > Use of this query parameter is NOT RECOMMENDED as such usage has known > interoperability problems in popular use cases. There is no guarantee servers > will preserve this query parameter when issuing redirects. Clients > SHOULD NOT use > this query parameter unless they are operating in an environment in > which this query > parameter will be preserved in an HTTP redirect. > --- > > > -andy > > > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext