Hi Mario,
thanks for your clarifications. Having more definitions in RDAP profiles makes sense to me. Best, Karl Heinz On Tue, Jan 21, 2020 at 12:33 PM Mario Loffredo <[email protected]> wrote: > 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]> > 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] >> A: Maurizio Martinelli <[email protected]> >> <[email protected]>, Mario Loffredo >> <[email protected]> <[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. >> >> The IETF Secretariat >> >> _______________________________________________ >> regext mailing list >> [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
