Mario, is your implementation of regex search exposed so others can use it? If so, would you be able to share some information about your implementation so we can add it to the "implementation status" section of the draft?
Scott From: Mario Loffredo [mailto:[email protected]] Sent: Thursday, November 10, 2016 9:25 AM To: Hollenbeck, Scott; [email protected] Subject: Re: [regext] Questions about RFC 7482 Dear Scott, thanks a lot for your answers. I have read the extension about POSIX regular extension and I have already implemented it by using MySql REGEXP operator. I have read the extension about OpenID too but at the moment my prototype of RDAP server does not implement any authentication policy. It should be my next development step, but, I must confess, I have never used OpenID before so I have to read up. I'll try to write down a draft about the response to the help path as soon as possible. The basic idea is to describe in a formal notation all the RDAP features to let a client configure itself and interact with a server without knowing in detail the profile the server implements. Thanks again, Mario Il 09/11/2016 18:13, Hollenbeck, Scott ha scritto: From: regext [mailto:[email protected]] On Behalf Of Mario Loffredo Sent: Wednesday, November 09, 2016 11:28 AM To: [email protected]<mailto:[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 -- Dr. Mario Loffredo Servizi Internet e Sviluppo Tecnologico Unità Sistemi e Servizi Registro .it CNR - Istituto di Informatica e Telematica via G. Moruzzi 1, I-56124 PISA, Italy E-Mail: [email protected]<mailto:[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
