Hi Andy,
my comments below.
Il 23/01/2019 21:31, Andy Newton ha scritto:
Mario,
My response is in-line
On Wed, Jan 23, 2019 at 07:15:02PM +0100, Mario Loffredo wrote:
Hi Andy,
thanks for your feedback. My comments are below.
Il 23/01/2019 16:30, Andy Newton ha scritto:
On Fri, Jan 18, 2019 at 05:04:20PM +0100, Antoin Verschuren wrote:
Hi all,
As discussed on the mailinglist, we have selected 5 documents that people most
want to be added to our milestone list.
To be able to to that the documents should first be adopted as working group
documents.
This is a formal adoption request for draft-loffredo-regext-rdap-reverse-search
The draft is available here:
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/
Please review this draft to see if you think it is suitable for adoption by
REGEXT, and comment to the list, clearly stating your view.
Please also indicate if you are willing to contribute text, review, be a
document shepherd, etc.
First, I wish to thank Mario and his co-authors for opening this line of work.
I have a few comments on this draft (and I'll let the chairs determine if I'm
agreeing with adoption or not).
1. From an operational point of few, I think there maybe a need differentiate
the support of the different searches. In my (limited opinion), the requirement
to support reverse searches by handle and email address are different than the
requirement to support reverse search of name and physical address. Therefore,
I think operators and policy people need a way to differentiate the various
searches in their documentation. Perhaps this can be done by breaking the
searches into multiple drafts and therefore registry A can say the support RFC
XXXX while registry B can say they support RFC YYYY. Just a thought.
Honestly, I don't see any difference but, anyway, we can discuss about that.
Another point of discussion could be if we need other reverse search
capabilities not limited to the classic domains-entities relationship and
currently uncovered by RDAP.
I'm not really raising a technical issue. It's really about operators feeling
the need to support all the queries in the draft vs just some and how they
would communicate that to their consituencies.
Let me think about it some more.
ok
2. I don't know if we want to tackle the issue of distributing reverse
searches. But that is an issue here.
What do you mean exactly for "distributing search"? Do you mean "across
different RDAP servers" ?
Yes.
I think that distributed search can be implemented by RDAP clients
without changing anything on server side.
Clients could load information from bootstrap IANA registries to provide
users with a list of TLDs among which users could select those involved
in the search.
Then clients could distribute the query to the corresponding RDAP
servers, collect the responses and present the results as a single response.
The implementation by servers of capabilities like partial response and
advancing querying/filtering could reduce the risks to obtain truncated
results.
3. The complexity of the query parameters makes me wonder if we should consider
another mechanism for these more complex extensions... One such mechanism would
be a general extension of using POST with GraphQL, and then doing profiles of
reverse search (and other things) on top of that.
I have thought to the use of a POST method as well as to GraphQL but I
didn't want to propose something outside the constraints of RFC7482 :-)
I think this proposal is related to the other two drafts (partial response,
sorting-and-paging) and to the implementation of more complex queries.
Ok. If you considered it but found the approach less-than-desirable, that's
good enough for me.
Beyond the compliance with RFC7482, there are some other reasons to opt
for the standard approach (GET method) rathen than a POST/GraphQL approach.
POST/GraphQL is a more comprehensive solution addressing all the issues
connected with both query and result set management but it is harder to
implement by RDAP providers and more difficult for RDAP users.
From server-side perspective, the use of the GET method enables a more
modular solution. Each RDAP provider can decide which addtional query
capabilty to implement (e.g. sorting, paging, partial response, and so
on) with a relatively small effort. In addition, GET is more consistent
with the use of links and, in my opinion, links are fundamental to make
servers be as self-descriptive as possible.
From user perspective, GET is more suitable: GET requests can be
cached, remain in the browser history, can be bookmarked.
Probably, those features have inspired you and Scott when writing RFC 7482.
Basically, RDAP users need neither an ad-hoc client nor a REST plugin in
their web browsers in order to interact with an RDAP server. RDAP
clients should provide more advanced capabilities like
self-configuration and distributed search.
However, GET is a bit less elegant than POST when dealing with complex
queries but it seems to me an acceptable compromise.
The query defined in reverse search draft is based on a JSON expression
as well as the current implementation of complex queries by .it RDAP
public test server as described in the white paper available here
<https://www.iit.cnr.it/sites/default/files/TR%2007-2018.pdf>
I would like to know if this vision of RDAP is shared by other members :-)
mario
-andy
--
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
