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