Thanks for explaining various options, Mario. That’s a reasonable justification
for a role to be in the path segment, especially for access control and search
efficiency.
Jasdip
From: Mario Loffredo <mario.loffr...@iit.cnr.it>
Date: Monday, August 3, 2020 at 5:51 AM
To: Jasdip Singh <jasd...@arin.net>, "regext@ietf.org" <regext@ietf.org>
Subject: Re: [regext] RDAP reverse search draft feedback
1. Why introduce the keyword “reverse” in the search path? Is it to
distinguish from the related reverse search scenarios (e.g. domains by nsIp)
defined in 7843bis? In light of introducing a new extension for this draft, the
“reverse” keyword may be redundant.
[ML] The main reason is to clearly identify the paths dedicated to reverse
search so RDAP providers can more easily control the access to reverse search
services on a per-path basis. Moreover, maybe in the next future, RDAP servers
might implement additional services and having different paths make the mapping
between the services and the users more manageable at the implementation level.
In the REST context, resources can be easily protected according to their path.
1. Instead of defining the generic reverse search path
{resource-type}/reverse/{role}?{property}=<search pattern>, would it be better
to take a specific search path, say domains versus nameservers versus entities,
and define the new query parameters (that fill the current search gaps) for
each of them section-by-section? Please ignore this comment if the intent here
is to pivot around the roles defined in the IANA RDAP JSON Values registry.
[ML] I'm deeply convinced that specifying the entity role is fundamental for an
effective implementation of a reverse search feature. For two reasons:
1. to furtherly map the reverse search services against the user profiles:
searching domains for a technical contact might be allowed to more users than
searching domains for a registrant
2. to restrict the scope of a reverse search query: a reverse search without
specifying a role usually takes longer and involves much more objects than
doing the same for a specific role and I think that rarely a reverse search
would be requested without considering a role.
Anyway, the draft takes all the scenarios.
I report as a response to the following comment the reasons why I have opted
for defining the role in the path rather than as a query parameter.
1. Knowing that it gets more complex but is it possible that folks may need
to pass multiple query parameters for conjunctive criteria? If so,
{resource-type}/reverse/{role}?{property}=<search pattern> may need to evolve
to account for multiple query parameters.
[ML] Provided that we agree that specifying the role in a reverse search query
would be useful, I reported here in the following some possible solutions with
the related pros and cons:
1. replicating the properties used for reverse searching for the possible roles
in the query parameters (e.g. registrantFn, technicalHandle)
Pros: very compact in itself and in a conjunctive criteria (e.g.
registrantFn=XXXXX&technicalHandle=YYYYY)
Cons: not very effective because there would be a proliferation of query
parameters, and, as I wrote above, the role specification in the path might
help the implementers' burden in controlling the access to the reverse search
services. In my opinion, not very neat from the conceptual point of view as
well.
2. letting role be a query parameter (e.g. fn=XXXXX&role=registrant).
Pros: simple solution (it was the first solution I proposed)
Cons: unusable in building conjuntive criteria and, like the soluion
aforementioned, unpractical for controlling the accesses.
3. specifying the role in the query path:
Pros: the most effective solution for controlling the accesses and very
flexible and conceptually neat.
Cons: unusable in conjunctive criteria, at least in those mentioning two
reverse search properties.
Anyway, this is true if we think that GET must be the only HTTP method
available in RDAP. It is well known that GET allows to specify a query where
parameters are joined solely in AND. It would be desireable that all boolean
operators should be allowed and, in my opinion, this could be done only if the
query is submitted via POST . I have already implemented a draft version of
this feature. I don't wanna go into much detail on this service here but the
key aspects are:
a. a POST can be submitted on the specific path "/query" (e.g. domains/query)
b. the request body is a JSON map including the parameters normally used in a
GET query like count, sort, fieldSet plus a parameter named "query" to deliver
a complex search predicate as a JSON object. All the boolean operators are
allowed, likewise predicates at different nesting level. Search properties
related to RDAP contents are reported as strings: "nsLdhName",
"reverse/registrant/fn"
4. any other solution not listed before.
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
