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]
*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]
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
