Dear Scott,
Il 13/11/2016 22:45, Hollenbeck, Scott ha scritto:
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?
At the moment, the implementation is not exposed, It's a prototype
available only for internal use.
As I wrote in the previous mail, we have not implemented an
authentication policy yet.
We would like to release a RDAP server implementing different access
levels and I really hope we 'll do it in a few time.
Anyway, a first step could be the release of a .it RDAP server version
publishing the same information of our public WHOIS service.
I'll inform you about it as soon as possible.
Regards,
Mario
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
--
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
