Hi,
here in the following some comments about this extension:
1) Don't know how to formally use this extension with HEAD as this
method doesn't return the body.
Hence, it would represent a case where the server returns an extension
without signaling it in the rdapConformance array.
2) It seems to me that parsing the HTTP Link header field is trickier
than parisng the "links" response field.
I'm not aware of well-known HTTP Link Header implementations. I searched
the web for them and just found out https://github.com/topics/rfc-8288.
I prefer to include all the useful information in the RDAP response
as JSON parsers are largely used.
3) Wonder how many servers don't include the registrar entity in the
response to a domain lookup.
The gTLD RDAP response profile requires servers to do that.
As a result, I'm afraid that this extension would be useless.
4) However, it makes sense to me to discuss what could be the most
likely links returned in the RDAP response and if we really need to
register some specific rel values detailing the generic "related"
relation to make RDAP clients to easily identify them or if that is
profile-specific.
Then, we could discuss if it would be advisable to have RDAP responses
returning only the link information in addition to the object identifier.
In that case, I agree with Jasdip that registering an ad-hoc field set
could be a viable option.
Best,
Mario
Il 24/05/2024 18:58, Jasdip Singh ha scritto:
Hi Gavin,
Can RFC 8982 (RDAP Partial Response) [1] not be leveraged to solve this?
Jasdip
[1] https://www.rfc-editor.org/rfc/rfc8982.html
*From: *Maarten Wullink <maarten.wullink=40sidn...@dmarc.ietf.org>
*Date: *Friday, May 24, 2024 at 10:28 AM
*To: *Marc Blanchet <marc.blanc...@viagenie.ca>
*Cc: *Gavin Brown <gavin.br...@icann.org>, Registration Protocols
Extensions <regext@ietf.org>
*Subject: *[regext] Re: [Ext] New Version Notification for
draft-brown-rdap-referrals-00.txt
Hi Gavin,
Like Marc, i’m not a big fan of duplicating the link information from
the json response into the response headers.
However, for the HEAD method request i do see a use case, because in
this case there exists no data duplication and the client can
efficiently navigate the Link headers in the response.
anyway, just my 2 cent.
Best,
Maarten
> Op 24 mei 2024, om 15:17 heeft Marc Blanchet
<marc.blanc...@viagenie.ca> het volgende geschreven:
>
> [You don't often get email from marc.blanc...@viagenie.ca. Learn why
this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
>> Le 24 mai 2024 à 08:10, Gavin Brown <gavin.br...@icann.org> a écrit :
>>
>> Hi all,
>>
>> With my RDAP client implementer hat on, I've been ruminating about
how the users of my client(s)[1] use them, and some anecdata suggests
that in general, consumers of registration data - in the domain space
at least - are often equally if not more interested in the RDAP record
of the sponsoring registrar than of the registry.
>>
>> Currently, the only way for me to satisfy this user need is to get
the RDAP record from the registry, parse it to find the "related"
link, and then requery for that.
>>
>> This draft outlines a possible approach to improving the
performance of this use case, by putting relevant links into the
header of the response. The client can then use the HEAD method,
saving bandwidth and compute resources on both sides, and offering a
better experience for the user.
>
> I’m also an RDAP client implementer. ;-). and I’ll be playing
devil’s advocate. The extra query to me is not an issue. Servers of
RDAP data should already have various caching mechanisms (if not, they
are in big trouble…) so the hit to a server is insignificant. For the
client, an extra http query is also insignificant (by comparison, a
single web page is often 10-20… queries). For the two step process
(parsing + query), it is something that a good design would do
asynchronously so it has no material impact on the user experience or
UI or else. On the bandwidth usage, for GET request, it will be
duplication of all links within the RDAP JSON into HTTP headers,
therefore consuming more bandwidth (and resources). And if we have a
lot of related links (there are many already), then we are just
putting a lot of duplicated stuff in the HTTP headers for no necessary
use. As a client implementor, I’m not sure I should trust the HTTP
headers, as they may be missing links or maybe wrong: the source of
truth is the JSON, so I’ll be parsing the JSON anyway. On the server
side implementation, my guess is that for generality, a server
implementor may not want to duplicate data, but instead itself parse
the JSON/database and then extract the links and create HTTP headers,
in this case, this will be way more work for the server to implement
this. While I see the idea behind your proposal, I think it may not be
needed. At least, I don’t see value for me to implement it. :(
>
> Regards, Marc.
>
>>
>> Feedback is welcome!
>>
>> G.
>>
>>> Begin forwarded message:
>>>
>>> From: <internet-dra...@ietf.org>
>>> Subject: [Ext] New Version Notification for
draft-brown-rdap-referrals-00.txt
>>> Date: 23 May 2024 at 20:42:19 BST
>>> To: Andy Newton <andy.new...@icann.org>, Gavin Brown
<gavin.br...@icann.org>
>>>
>>> A new version of Internet-Draft draft-brown-rdap-referrals-00.txt
has been
>>> successfully submitted by Gavin Brown and posted to the
>>> IETF repository.
>>>
>>> Name: draft-brown-rdap-referrals
>>> Revision: 00
>>> Title: Efficient RDAP Referrals
>>> Date: 2024-05-23
>>> Group: Individual Submission
>>> Pages: 6
>>> URL: https://www.ietf.org/archive/id/draft-brown-rdap-referrals-00.txt
>>> Status: https://datatracker.ietf.org/doc/draft-brown-rdap-referrals/
>>> HTML:
https://www.ietf.org/archive/id/draft-brown-rdap-referrals-00.html
>>> HTMLized:
https://datatracker.ietf.org/doc/html/draft-brown-rdap-referrals
>>>
>>>
>>> Abstract:
>>>
>>> This document describes how RDAP servers can provide HTTP "Link"
>>> header fields in RDAP responses to allow RDAP clients to efficiently
>>> determine the URL of related RDAP records for a resource.
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>>
>>> --
>>> Gavin Brown
>>> Principal Engineer, Global Domains & Strategy
>>> Internet Corporation for Assigned Names and Numbers (ICANN)
>>>
>>> https://www.icann.org
>>
>> _______________________________________________
>> regext mailing list -- regext@ietf.org
>> To unsubscribe send an email to regext-le...@ietf.org
>
> _______________________________________________
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
_______________________________________________
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
