From: regext [mailto:[email protected]] On Behalf Of Mario Loffredo Sent: Wednesday, November 09, 2016 11:28 AM To: [email protected] Subject: [regext] Questions about RFC 7482
Hi all, I have some questions about RFC 7482. I'm quite a newbie in RDAP (I have implemented a prototype of a RDAP server) so I don't know if they can be considered as matters of an RDAP profile or matters of the RDAP standard or simply trivial matters. I have a background on digital libraries and, it seems to me that some solutions found in that field could be applied to registration data search and retrieval. Question 1. Looking at search path segments, I think that, in some cases, there should be a way to restrict the possible results, particularly when partial string matching is used. A typical example coming in my mind is searching for entities with a certain role. Maybe one can be interested in searching only for registrants or registrars but, at the moment, it is not possible. Do you agree about it? If so, what is the best way to restrict the search? To create custom paths? To extend the search operators and allow conditions on the other fields? [SAH] Thanks for the questions, Mario. RDAP search was something that we know we didn't address completely in 7482. It was a contentious topic for which there seemed to be little agreement, so what's in the protocol now was an attempt to provide basic functionality while deferring specification of other features. Additional search capabilities and parameters can indeed be specified by extending RDAP. This can be done with a combination of new paths and new parameters. An example of just such an extension can be found here: https://datatracker.ietf.org/doc/draft-fregly-regext-rdap-search-regex/ Question 2. The paragraph "4.2. Associated Records" states: "Note that there might not be a single, static information return policy that applies to all clients equally. Client identity and associated authorizations can be a relevant factor in determining how broad the response set will be for any particular query." Therefore a client cannot set the response format; even if it is recommended to have different return policies, the response format is fixed according to the client authorization. I think that, at least, an optional "brief" response should be available. Maybe it could correspond to the response of unauthenticated client. A "brief" response could be used to collect search query results while the "full" response could be used in targeted lookup queries. Clients could request the brief response as a query operator. For example, https://example.com/rdap/entities?fn=Bobby%20Joe*&response=brief<https://example.com/rdap/entities?fn=Bobby%20Joe*&role=registrant> Furthermore if a brief response format was standardized, it could improve interoperability between client and servers. What do you think about it? [SAH] I can imagine there being some differences of opinion when it comes to defining exactly what a "brief" response contains (note your remark about interoperability), but the idea of a client letting a server know that it wants to receive only some small subset of a larger response doesn't seem unreasonable. I've touched on this topic from a server-side perspective in an Internet-Draft I wrote that describes a federated authentication protocol for RDAP: https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/ I have running code to demonstrate that the concept works, but much work remains from a policy perspective. Question 3. What do you think about using the help response to return structured information about the implemented profile (standard paths, custom paths, additional search operators, access levels, and so on) ? It could enable RDAP clients to configure themselves thus speeding up interaction between clients and servers. In the standard ANSI/NISO Z39.50 about search and retrieval, there was a similar facility called Explain. [SAH] That sounds perfectly reasonable. Server operators are free to return all kinds of information in a help response. If you have an idea about one form of a structured response (or any of the ideas described above), you might want to consider writing the idea down in Internet-Draft format and sharing it with this group. Scott
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
