Hi Tom,
thank you for the feedbacks. My comments are below.
Best,
mario
Il 24/07/2019 16:29, Tom Harrison ha scritto:
Hi Mario,
On Mon, May 27, 2019 at 01:02:15PM +0200, Mario Loffredo wrote:
in this new version the "IANA Considerations" section has been updated to
include the request for the registration of the "subsetting" value in the
RDAP Extensions Registry.
Thanks for putting this together. Some comments/feedback:
- Section 5 of RFC 7483 suggests that objects should always include a
'self' link, regardless of whether they are top-level objects,
embedded objects, or search result objects. I think that including
'self' links for all objects, even those returned in response to an
'id' fieldset search, would be useful, because it saves the client
from having to re-search when they want further details for only
a small number of objects in a set of search results.
Your opinion disagrees with what is written in
draft-blanchet-regext-rdap-deployfindings-05. I, too, agree with Marc
that self links can cause inifinite loops when the user is a software
agent but, at the same time, I recognize that, when the id field set is
applied, a self link for each result would be helpful to a human.
Definitively, I think that such a feature could be provided by an RDAP
client smarter than a simple web browser.
- The draft defines the basic field sets (in section 5) at a high
level, and is not prescriptive about the fields that must (or must
not) be included. I can see from the change log that this was a
deliberate decision, but I'm curious as to why you went with this
approach. Defining a minimum set of fields that will be included
(if they exist) for the non-'full' field sets seems like something
that would save clients some trouble (with the current text,
clients would need logic like "query for 'brief', and then query
for 'full' if response does not include field F").
Basically there are two extremes: on one side the id field set, on the
other side the full response. In the middle, there is a variety of
solutions. For the sake of improving the client-server interoperability
and based on the result of RFC7485, I had submitted a version proposing
a set of fields to be included in the brief field set. But the WG
feedback about that was clear: each RDAP provider must be free to define
its own version of the brief field set.
Anyway, I'm quite sure that finally all the brief versions will have a
common core and such a core will correspond to the real brief field set.
- Do you think it's worth extending this to standard object lookup,
in addition to searches?
It seems to me that this extension makes less sense for a lookup query.
The only scenario coming to my mind where a client could take vantage
from the use of such capability is the submission of a massive set of
lookup queries. On the other hand, every response to a lookup query
should report the "subsetting_metadata" property which would increase
the response size.
-Tom
--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
