Subject: [regext] Questions about RFC 7482

From: Mario Loffredo <[email-masked]>
Date: Wed, 9 Nov 2016 17:28:19 +0100

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?

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
Furthermore if a brief response format was standardized, it could 
improve interoperability between client and servers.
What do you think about it?

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.

Thanks for your answers,
Mario

-- 
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-masked]
Phone: +39 050 3153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Nov 2016 17:13:01 +0000

From: regext [mailto:[email-masked]] On Behalf Of Mario Loffredo
Sent: Wednesday, November 09, 2016 11:28 AM
To: [email-masked]
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.

"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

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 10 Nov 2016 15:25:06 +0100

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-masked]] *On Behalf Of *Mario 
> Loffredo
> *Sent:* Wednesday, November 09, 2016 11:28 AM
> *To:* [email-masked]
> *Subject:* [regext] Questions about RFC 7482
>
> Hi all,
>
> 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.
> 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:
>
> "Note that there might not be a single, static information return 
> policy that applies to all clients equally. Client identity and
> available. Maybe it could correspond to the response of 
> unauthenticated client.
> example, 
> https://example.com/rdap/entities?fn=Bobby%20Joe*&response=brief 
> <https://example.com/rdap/entities?fn=Bobby%20Joe*&role=registrant>
> [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:
>
> information about the implemented profile (standard paths, custom 
> paths, additional search operators, access levels, and so on) ?
> [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-masked]
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sun, 13 Nov 2016 21:45:31 +0000

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-masked]]
Sent: Thursday, November 10, 2016 9:25 AM
To: Hollenbeck, Scott; [email-masked]
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

To: [email-masked]<mailto:[email-masked]>

Hi all,

Question 1.

Question 2.

Question 3.

Scott

--

Dr. Mario Loffredo

E-Mail: [email-masked]<mailto:[email-masked]>

Phone: +39 050 3153497

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 14 Nov 2016 09:53:42 +0100

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-masked]]
> *Sent:* Thursday, November 10, 2016 9:25 AM
> *To:* Hollenbeck, Scott; [email-masked]
> *Subject:* Re: [regext] Questions about RFC 7482
>
> Dear Scott,
>
> It should be my next development step, but, I must confess, I have 
> never used OpenID before so I have to  read up.
> 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
>
>
>
>     *From:* regext [mailto:[email-masked]] *On Behalf Of
>     *Mario Loffredo
>     *To:* [email-masked] <mailto:[email-masked]>
>     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.
>     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:
>
>     associated authorizations can be a relevant factor in determining
>     how broad the response set will be for any particular query."
>
>     recommended to have different return policies, the response format
>     is fixed according to the client authorization.
>     A "brief" response could be used to collect search query results
>     while the "full" response could be used in targeted lookup queries.
>     [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:
>
>     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.
>     [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
> E-Mail:[email-masked] <mailto:[email-masked]>
> Phone: +39 050 3153497
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext