Jim,

I offered two very concrete examples of the problem and you have once
again called it a "claim". And you don't see how that can be perceived
as dismissive?

Anway, Jasdip already answered your broader question, and now you are
asking for discussion on hypotheticals that are likely to meander. For
the sanity of the list, perhaps we should take a time-out.

-andy

On Thu, Nov 16, 2023 at 12:17 PM Gould, James <jgo...@verisign.com> wrote:
>
> 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&quot;>.
>  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&gt;>
> >
> >
> >
> >
> > 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

Reply via email to