I agree with Scott. Both ideas are worth discussion. -andy
On Tue, Sep 19, 2017 at 8:51 AM, Hollenbeck, Scott <[email protected]> wrote: > Mario, I think these are ideas worth exploring. I’d like to see those I-Ds > published. > > > > Scott > > > > From: regext [mailto:[email protected]] On Behalf Of Mario Loffredo > Sent: Tuesday, September 19, 2017 8:30 AM > To: [email protected] > Subject: [EXTERNAL] [regext] Partial response and reverse search in RDAP > > > > Hi all, > > I have implemented two new extensions in .it RDAP prototype server > (https://rdap.pubtest.nic.it): partial response and reverse search. > I send this mail to know your opinion about them. Personally, I think they > could be very useful. If you are interested in these proposals, I would like > to submit two Internet-Draft documents. > In the following, I briefly report the rationale for their implementation. > > The idea of using partial response in RESTful API design is quite simple: > instead of returning full objects in API responses with all the data fields, > only a subset of data fields are returned. The benefit is obvious: less data > transfered over the network means less bandwidth usage, faster server > response, less CPU time spent on the server and client, as well as less > memory usage on the client. Several leading APIs providers (e.g. LinkedIn, > Facebook, Google) give developers just what they need in responses by > providing an optional query parameter called fields after which you put the > fields you want to be returned. In other contexts, for example in digital > libraries, servers provide responses according to different tag sets. > Basicly, they allow users to specify “brief” to have back a short response > and “full” to have back the complete response. Currently, in RDAP, there is > no way for a client to request a partial response. According to the user > access level, the server can only provide the client with the complete > response. Some examples of simple responses are reported in RFC7483 (Fig.19 > and Fig.20) but they cannot be requested, where it is possible, as an > alternative to full responses. Futhermore, servers cannot define their > result set limits according to partial responses. This results in an > efficiency mostly when users submit search queries. > Partial response in the .it RDAP server can be requested by adding the > fieldSet parameter to the query string. Even if field set option is less > flexible than fields option, it is easier to implement, more interoperable > and more compliant to access levels. For this proof of concepts, I have > defined three field sets: > > - id: it contains only the identifier of each object (handle for entity, > ldhName for domain and nameserver) > - brief: it contains some fields to provide a “simple” response > - full: it contains all the information the server can provide > > Full is the default field set in this proof. Obviously, every RDAP > implementation can define its available field sets but, to improve > client-server interoperability, I think that at least servers should provide > some common field sets. > I have implemented partial response only for search query where it makes > more sense. Result set limits are different according to the requested > field set. > > All of us know reverse search, its pros and its cons. ICANN itself, in the > “Final Report from the Expert Working Group on gTLD Directory Services: A > Next-Generation Registration Directory Service (RDS)”, states that reverse > Whois is one of the key benefits of the Next-Gen RDS if implemented > enforcing requestor accreditation, authentication, authorization, and terms > and conditions of RDS data use. Usually, registries (.it included) receiving > requests for reverse searches use out-of-band mechanisms to provide a > response. The main reasons behind such requests are: the loss of > synchronization between the registrar and the registry databases and the > need of such collections to perform massive EPP updates (for example, the > change of the technical contact for a lot of domains). So when I talk about > reverse search, I think of a controlled access for registrars which are > allowed to search only for their own domains. > Currently, in RDAP, the only reverse operation allowed is to find the > collection of domains related to a nameserver (ldhName or ip). > In this proof of concepts, reverse search has been implemented only for > domains-entities relationship (the classic reverse Whois scenario) . Allowed > paths are entityHandle and entityFn (not both). Partial matching is allowed > too. Reverse search must be restricted with respect to a single entity role > (in .it allowed values are: registrar, registrant, technical, > administrative). I think that it makes no sense to search for more than a > role or for no role but, anyway, it is not a strict constraint. > There are no relevant performance issues if you use indexed fields in the > search and if you don't use partial match with a prefixed wildcard as in the > case of the standard search paths. > The response is really fast when you specify the "id" field set because the > payload for the DBMS is minimum. > > Here in the following two examples using both the extensions: > > https://rdap.pubtest.nic.it/domains?entityHandle=NC01-ITNIC&entityRole=registrant&count=true&fieldSet=id > > https://rdap.pubtest.nic.it/domains?entityHandle=NC02-ITNIC&entityRole=technical&count=true&fieldSet=brief > > The examples make use of the count parameter that has been already presented > in a draft about sorting and paging operators. > All the operators above are briefly described in the help response. > Unfortunately, our public test environment cannot be compared to the live > one in terms of data amount and performance but, I hope, you will get an > idea of the two extensions, anyway. > Sorry for the long mail. > I look forward for your feedback. > > > Regards, > Mario > > -- > > Dr. Mario Loffredo > > Servizi Internet e Sviluppo Tecnologico > > CNR - Istituto di Informatica e Telematica > > via G. Moruzzi 1, I-56124 PISA, Italy > > E-Mail: [email protected] > > Phone: +39 050 3153497 > > Web: http://www.iit.cnr.it/mario.loffredo > > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext > _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
