Hi Tom,
thanks a lot for your feedback. Please find my comments below.
Il 05/08/2019 02:41, Tom Harrison ha scritto:
Hi Mario,
On Wed, Jul 24, 2019 at 08:08:08PM +0200, Mario Loffredo wrote:
Il 24/07/2019 16:29, Tom Harrison ha scritto:
- 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
I think that document's content is about links that refer to the
current object, but that appear with a link relation type other than
'self'. If the link has a link relation type of 'self', then the
client should skip it during link processing.
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.
This part of my response is a bit awkward, because it spans multiple
documents. I forgot to include in my reverse-search mail that it
would be good to expand the supported object types to include IP
networks and ASNs, since those are the main searches that we (APNIC)
are looking to support. Assuming that's OK, then including 'self'
links in partial responses is more useful than for
domain/nameserver/entity alone, because for IP networks it will save
the client from having to calculate the CIDR range based on the
startAddress and endAddress values (querying by the exact CIDR range
is necessary because of hierarchical delegations).
This concept is also stated in the "Introduction" section of the
reverse-serach draft:
"Since entities can be in relation with all RDAP objects ([RFC7483]),
the availability of a reverse search can be common to all RDAP query paths."
Therefore, I have no problem at all to make this capability available on
the remaining objects. The only problem is that RDAP should be
consequently extended so as to include both "autnums" and "ips" among
the search path segments. When the reverse search draft was submitted
for the very first time, the authors' main goal was to explore the
reverse search capability only for the most known purpose. In addition,
a reverse search capability available only on domains would have been
compliant to RFC7482.
Defìnitively, I think that the additional search path segments couldn't
be defined in the reverse-search draft but in a new version of RFC7482
published as a Proposed Standard document (just to refer to the last
Scott's mail). Do you agree about this point?
Given that including 'self' links will increase response sizes
substantially, and that the need for 'self' links will not be
consistent across clients or object types, I think that your
suggestion from the other mail about having an 'extendedId' fieldset
that includes 'self' links sounds like a good way of dealing with this
issue.
Let's ask the working group for an opinion about the two issues above.
We can either discuss them in an Interim Meeting or postpone the
discussion at the next IETF.
Briefly, the points to be discussed might be:
1) Should both "ips" and "autnums" be included among the search path
segments?
2) Should the self-link be included in the definition of the "id" field
set or should we define an ad-hoc field set containing the self-link?
Best,
mario
-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
