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

[Mario Loffredo <[e-mail]>]

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.
>
> If I misunderstood or mis-characterise what you said, I welcome 
> clarification.

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

>
> -George

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