Subject: [regext] I-D Action: draft-ietf-regext-rdap-sorting-and-paging-01.txt

From: [email-masked]
Date: Thu, 11 Apr 2019 01:08:39 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the IETF.

        Title           : Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging
        Authors         : Mario Loffredo
                          Maurizio Martinelli
                          Scott Hollenbeck
	Filename        : draft-ietf-regext-rdap-sorting-and-paging-01.txt
	Pages           : 26
	Date            : 2019-04-11

Abstract:
   The Registration Data Access Protocol (RDAP) does not include core
   functionality for clients to provide sorting and paging parameters
   for control of large result sets.  This omission can lead to
   unpredictable server processing of queries and client processing of
   responses.  This unpredictability can be greatly reduced if clients
   can provide servers with their preferences for managing response
   values.  This document describes RDAP query extensions that allow
   clients to specify their preferences for sorting and paging result
   sets.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-rdap-sorting-and-paging-01
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-sorting-and-paging-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-sorting-and-paging-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 11 Apr 2019 11:19:34 +0200

Hi all,

this version harmonizes the "paging_metadata" element for the two 
pagination methods.

In my opinion, both methods have strengths and weaknesses. Therefore, 
since the "paging_metadata" element keeps the same structure and 
basically clients make use of the paging links as they are provided by 
the server, this specification envisages that operators may implement a 
method according to their needs, the user access levels, the submitted 
queries.

More detailed descriptions of both "sorting_metadata" and 
"paging_metadata" elements are provided.

With regard to the possibility for clients to indentify which 
capabilities a server supports, this is still an open issue as it was 
pointed out by Andy at the last meeting. Currently, the rdapConformance 
array can only be used to identify the additional elements in the 
response. On this point, I have submitted a presentation to the ROW 
committee about a possible solution enabling servers to provide clients 
with their own specification.

Many thanks, James and Andy, for your interest.

I look forward to further reviews.

Cheers,

mario

-------- Messaggio Inoltrato --------
Oggetto: 	[regext] I-D Action: 
draft-ietf-regext-rdap-sorting-and-paging-01.txt
Data: 	Thu, 11 Apr 2019 01:08:39 -0700
Mittente: 	[email-masked]
Rispondi-a: 	[email-masked]
A: 	[email-masked]
CC: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Registration Protocols Extensions WG of 
the IETF.

Title : Registration Data Access Protocol (RDAP) Query Parameters for 
Result Sorting and Paging
Authors : Mario Loffredo
Maurizio Martinelli
Scott Hollenbeck
Filename : draft-ietf-regext-rdap-sorting-and-paging-01.txt
Pages : 26
Date : 2019-04-11

Abstract:

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: George Michaelson <[email-masked]>
Date: Fri, 12 Apr 2019 08:54:13 +1000

Personally, I felt the conversation at the microphone about client/server
capability was a huge misunderstanding. You did not seem to "get" part of
what was being said, about the need for a client to be able to know what a
server can do (in the future) beyond what a server has done (now, or in the
past).

If we admit two forms of pagination/presentation/truncation, and we do not
require all clients to implement both, then we can wind up in a world where
a client cannot handle what a server can do. A capabilities query is a
mechanism to inform server and client mutually what they can do. Telnet
"options" negotiation for example, or the SMTP HELO exchange is not
one-sided. How a client and server "dance" around this, informs what they
both know about each other. There is a proffer and a response. Yes, the
actual underlying protocol here is atomic and there is no implied state
because we didn't implement session. But that doesn't mean both client and
server cannot "know" about each other, because implicit state they hold or
construct forms the session information, or the client holds all
information, and varies its future behaviour to the atomic server,
irrespective. (one sided, is simpler for servers, but puts more work on the
client)

If we admit two forms of pagination a client should be entitled to discover
in advance which model to expect: this determines future actions. You
appeared to say you wanted all clients to be ready to handle EITHER case.

If I misunderstood or mis-characterise what you said, I welcome
clarification.

-George

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 12 Apr 2019 15:32:56 +0200

Hi George,

many thanks for your comments.

Please find my comment at the end of your mail.

Il 12/04/2019 00:54, George Michaelson ha scritto:
> Personally, I felt the conversation at the microphone about 
> client/server capability was a huge misunderstanding. You did not seem 
> to "get" part of what was being said, about the need for a client to 
> be able to know what a server can do (in the future) beyond what a 
> server has done (now, or in the past).
>
> If we admit two forms of pagination/presentation/truncation, and we do 
> not require all clients to implement both, then we can wind up in a 
> world where a client cannot handle what a server can do. A 
> capabilities query is a mechanism to inform server and client mutually 
> what they can do. Telnet "options" negotiation for example, or the 
> SMTP HELO exchange is not one-sided. How a client and server "dance" 
> around this, informs what they both know about each other. There is a 
> proffer and a response. Yes, the actual underlying protocol here is 
> atomic and there is no implied state because we didn't implement 
> session. But that doesn't mean both client and server cannot "know" 
> about each other, because implicit state they hold or construct forms 
> the session information, or the client holds all information, and 
> varies its future behaviour to the atomic server, irrespective. (one 
> sided, is simpler for servers, but puts more work on the client)
>
> If we admit two forms of pagination a client should be entitled to 
> discover in advance which model to expect: this determines future 
> actions. You appeared to say you wanted all clients to be ready to 
> handle EITHER case.
>

I'm aware that we need a mechanism for clients to indentify which 
capabilities an RDAP server provides. I'm working about that and, at 
next ROW, I'll present a possible solution based on the use of most 
popular REST specification languages. Since RDAP responses are provided 
by a REST service I think we don't have to invent anything already 
existing.  It doesn't simply consist in providing a flat array of tags 
each one identifying a specific capability beacuse server policies can 
change according to the user profile in both requests and resonses.

That being said, pagination method is basically something that a client 
can't choose. It's true that, if a server provides offset and limit 
operators, they can be used individually in the initial query but, in 
most of use cases, they are used by the server to provide a ready-made 
link to the next page.  So a client will use that link  without 
considering how pagination is implemented. This concept is evident when 
a server implements the cursor pagination: no client will be able to 
submit the initial query to a server by setting a value for the cursor 
parameter, it will simply use the link returned in the paging_metadata 
element to scroll the result set. This is the reason why I told in my 
presentation that servers would be allowed to implement their own 
pagination method, even from query to query.

Anyway, I think there is a solution enabling servers to implement their 
own pagination method by providing a single parameter. Since the cursor 
value is opaque, this means that the pagination strategy implemented by 
a server is completely unknown to clients. Right?! I mean, it could 
correspond either to a physical link to a storage area maintained across 
the queries or to a specific value of the key property supporting  the 
seek method.

The cursor value could also be (this is the idea) a codification of 
offset and limit information (maybe the sort criteria too, if any) . For 
example, in the following query, the cursor value is the Base64 encoding 
of "offset=100,limit=50":

*https://example.com/rdap/domains?name=*nr.com&cursor=b2Zmc2V0PTEwMCxsaW1pdD01MAo=**
*

Obviously, this is an example, servers are hopefully expected to 
implement an encoding/decoding method less breakable than Base64, maybe 
based on symmetric encryption.

This solution could also allow servers to change the pagination method 
without announcing anything to the clients.

Therefore, clients would only know the cursor parameter. Offset and 
limit parameters could be no longer used individually but, I guess, 
nobody would complaint about that.

What do you (and WG) think about?

Regards,

mario

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail:[email-masked]
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo