Hi Jasdip, > On 21 Aug 2025, at 18:15, Jasdip Singh <[email protected]> wrote: > > Hi Gavin, > > From: Gavin Brown <[email protected]> > Date: Thursday, August 21, 2025 at 5:52 AM > To: Jasdip Singh <[email protected]> > Cc: Registration Protocols Extensions <[email protected]>, Mario Loffredo > <[email protected]> > Subject: Re: [regext] [Ext] request for adoption: draft-brown-rdap-referrals > > > On 19 Aug 2025, at 21:22, Jasdip Singh <[email protected]> wrote: > > > > Since the web links are grouped together for each RDAP object returned in > > an RDAP query response, not sure if that grouping knowledge would be lost > > when they are “unionized" in one or more Link headers returned. Probably, > > this seems a minor concern. > > It's not stated explicitly in the document, but the Link headers would only > correspond to the link objects in the topmost object of the response. This is > because (as *is* stated), the context URI of the links is the URI that was > requested by the user agent. > > [JS] That should help. However, AFAIU, that same context URI for an RDAP > query should also apply to the web links for the nested objects returned in > the response. At least, that’s how we have it for ARIN's RDAP service. E.g., > see: https://rdap.arin.net/registry/ips?handle=NET-149-112-152-0-* > [rdap.arin.net] .
Yes, that is correct, which is why any link object that embedded in a subordinate object (eg in a nameserver, entity, notice or remark) needs to have a "value" property to override the default context URI. G. -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
