Hi Karl Heinz,
thanks a lot for your review.
My comments are inline.
Il 21/01/2020 08:40, Karl Heinz Wolf ha scritto:
Mario,
Here is my feedback regarding this draft:
I think it is useful for clients to request a partial response as
described in this draft.
Chapter 2:
The discussions of the different approaches to partial response, which
I guess led to the decision of the WG to go for field sets, should be
probably moved to some kind of appendix to not confuse the reader.
ML: This section aimed to explain the reasons supporting the "field set"
approach. Anyway, I have no problem to move it elsewhere in the document.
However, it is interesting to read about the reasons and two comments
on this chapter: it says "the request of some fields might not match
the user access levels." You might also run into this when the request
contains a field set that is not allowed for this user (this is also
admitted in chapter 5) – so that is probably no advantage.
ML: The "subsetting_metadata" element enables the server to provide the
user with the allowable field sets. A similar element could contain the
allowable response fields which could be explicitly selected in a
request but its implementation results in a more verbose content and is
unpractical due to the fact that the RDAP response is not flat.
In addition, the user can request for either an allowed or an unallowed
field set so the management of error responses is easier than dealing
with a mix of allowed-unallowed fields.
Furthermore, you state that interoperability is facilitated with
pre-defined filed sets while there is no exact definition of all field
sets.
ML: See the comment to the feedback below.
Chapter 5:
I noticed that older version of this draft had a more detailed
description of the "brief" dataset, which is now removed. Do you think
interoperability, as written in chapter 2, is still achievable?
ML: Based on the outcomes of the analysis described in RFC 7485, I have
defined a possible list of elements for a "brief" response but the WG
clearly recommended to keep it out of the scope of the document in order
to separate the technology, to be described in a RFC, from its
operational aspects, to be described in an RDAP profile. The goal of
Section 5 is only to propose some potential examples of field sets.
I don't think that, in this way, interoperability could be limited. If,
for example, the gTLD RDAP profile included some field sets, almost 50%
of potential RDAP servers would be involved.
And since server operators can add their own field sets: do they need
to be registered somewhere or just be announced in the metadata with
its human readable description of which fields are going to be returned?
ML: I believe that, according to HATEOAS principles, a REST API should
be as self-descriptive as possible. Obviously, an RDAP operator can add
a "describedby" link in the "subsetting_metadata" element to furtherly
describe the implemented field sets in a more exhaustive document.
Is the "full" field set really required (and what is the difference of
a response with the "full" field set and an response without this
extension?
ML: It depends on the field set the server provides as the default one.
The default field set is applied when no field set is requested but it
could be different from the "full" response. In theory, the default
field set should contain the information which is considered relevant in
the majority (70-80%) of the requests which, in my experience, doesn't
correspond to a full RDAP response regardless of the user access level.
Anyway, this information as well as both the list of allowed field sets
and the elements included in each field set should be defined in a profile.
Cheers,
Mario
Best,
Karl
On Mon, Sep 2, 2019 at 11:31 AM Mario Loffredo
<[email protected] <mailto:[email protected]>> wrote:
Hi all,
this new version extends a review by Tom Harrison about including
a "self" link in the "id" field set. Now the draft recommends the
RDAP providers to include a "self" link in any field set other
than the full response.
Thanks a lot Tom for your review.
Best,
mario
-------- Messaggio Inoltrato --------
Oggetto: New Version Notification for
draft-ietf-regext-rdap-partial-response-04.txt
Data: Mon, 02 Sep 2019 02:24:21 -0700
Mittente: [email protected] <mailto:[email protected]>
A: Maurizio Martinelli <[email protected]>
<mailto:[email protected]>, Mario Loffredo
<[email protected]> <mailto:[email protected]>
A new version of I-D, draft-ietf-regext-rdap-partial-response-04.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.
Name: draft-ietf-regext-rdap-partial-response
Revision: 04
Title: Registration Data Access Protocol (RDAP) Partial Response
Document date: 2019-09-02
Group: regext
Pages: 13
URL:
https://www.ietf.org/internet-drafts/draft-ietf-regext-rdap-partial-response-04.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
Htmlized:
https://tools.ietf.org/html/draft-ietf-regext-rdap-partial-response-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-partial-response
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-partial-response-04
Abstract:
The Registration Data Access Protocol (RDAP) does not include
capabilities to request partial responses. In fact, according to the
user authorization, the server can only return full responses. A
partial response capability, especially in the case of search
queries, could bring benefits to both clients and servers. This
document describes an RDAP query extension that allows clients to
specify their preference for obtaining a partial response.
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 <http://tools.ietf.org>.
The IETF Secretariat
_______________________________________________
regext mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/regext
--
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
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
