Hi Mario,
> -----Original Message----- > From: Mario Loffredo <mario.loffr...@iit.cnr.it> > Sent: 08 September 2020 15:10 > To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org> > Cc: draft-ietf-regext-rdap-partial-respo...@ietf.org; regext- > cha...@ietf.org; regext@ietf.org; Jasdip Singh <jasd...@arin.net> > Subject: Re: Robert Wilton's No Objection on draft-ietf-regext-rdap- > partial-response-13: (with COMMENT) > > Hi Robert, > > please find my comments below. > > Il 08/09/2020 12:05, Rob Wilton (rwilton) ha scritto: > > Hi Mario, > > > > Please see inline ... > > > >> -----Original Message----- > >> From: iesg <iesg-boun...@ietf.org> On Behalf Of Mario Loffredo > >> Sent: 07 September 2020 18:04 > >> To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org> > >> Cc: draft-ietf-regext-rdap-partial-respo...@ietf.org; regext- > >> cha...@ietf.org; regext@ietf.org; Jasdip Singh <jasd...@arin.net> > >> Subject: Re: Robert Wilton's No Objection on draft-ietf-regext-rdap- > >> partial-response-13: (with COMMENT) > >> > >> Hi Robert, > >> > >> thanks a lot for your review. Please find my comments inline. > >> > >> Il 07/09/2020 16:28, Robert Wilton via Datatracker ha scritto: > >>> Robert Wilton has entered the following ballot position for > >>> draft-ietf-regext-rdap-partial-response-13: No Objection > >>> > >>> When responding, please keep the subject line intact and reply to all > >>> email addresses included in the To and CC lines. (Feel free to cut > this > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to https://www.ietf.org/iesg/statement/discuss- > >> criteria.html > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found here: > >>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial- > >> response/ > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> Hi, > >>> > >>> Thank you for this document. I have two minor comments: > >>> > >>> 2.1.2. Representing Subsetting Links > >>> > >>> "value": "https://example.com/rdap/domains?name=*nr.com > >>> &fieldSet=afieldset", > >>> > >>> Should "afieldset" be "anotherfieldset"? > >> [ML] In web linking (RFC8288), the "value" field contains the context > >> URI and the "target" field contains the target URI in a given relation > >> with the context URI. > >> > >> In Figure 2, the context URI is the current view of the results > provided > >> according to the current field set (i.e. "afieldset") while the target > >> URI is an alternative view provided according another field set (i.e. > >> "anotherieldset") > > [RW] > > > > Ah, yes. Thanks for the clarification/explanation. > > > > > >>> 5. Negative Answers > >>> > >>> Each request including an empty or unsupported "fieldSet" value > MUST > >>> produce an HTTP 400 (Bad Request) response code. Optionally, the > >>> response MAY include additional information regarding the > negative > >>> answer in the HTTP entity body. > >>> > >>> Given the solution suggests that subsetting metadata may be included > in > >>> positive responses, it might be helpful to also include similar > metadata > >> in > >>> negative responses. I.e. rather than just stating that a fieldSet is > >> invalid, > >>> perhaps there should be a recommendation that the response include the > >> list of > >>> possible valid values that fieldSet may take? > >> [ML] I think this pertains to the server policy. RDAP (RFC7483) allows > >> producers to provide consumers with additional information in error > >> responses through "notices" and "notices" can include "links". > > [RW] > > > > Yes, I agree that server policy may want to restrict what information is > returned on the error case. > > > > > >> Definitively, I would keep the fully compliance with the error response > >> structure defined in RFC7483. > > [RW] > > > > Okay. I agree that having the structure conform to RFC7843 makes sense. > > > > I was sort of thinking of something more like section 6 from RFC 7483. > E.g., the text could provide an example error response something like: > > > > { > > "errorCode": 400, > > "title": "FieldSet 'unknown-fieldset' is not a valid FieldSet" > > "description": > > [ > > "Supported FieldSet values are 'a-valid-fieldset' and 'another- > valid-fieldset'." > > ] > > } > > > > Probably this should only be returned if the request was otherwise > valid. > > > > And, I agree that the server could also choose to return valid links as > part of notices. > > > > Do you think that it would be helpful for the document to elaborate > beyond "Optionally, the response MAY include additional information > regarding the negative answer in the HTTP entity body."? > > OK. I would write: > > "Optionally, the response MAY include additional information regarding the > supported fieldSet values in the HTTP entity body." > > Besides, I can include something similar to your example as an example > error response. > > Does it works for you? [RW] Works for me. Thanks for your responsiveness. Regards, Rob > > Cheers, > > Mario > > > > > Regards, > > Rob > > > > > >> > >> Looking forward to your reply to my comments. > >> > >> Best, > >> > >> Mario > >> > >>> Regards, > >>> Rob > >>> > >>> > >>> > >> -- > >> Dr. Mario Loffredo > >> Systems and Technological Development Unit > >> Institute of Informatics and Telematics (IIT) > >> National Research Council (CNR) > >> via G. Moruzzi 1, I-56124 PISA, Italy > >> Phone: +39.0503153497 > >> Mobile: +39.3462122240 > >> Web: http://www.iit.cnr.it/mario.loffredo > > -- > Dr. Mario Loffredo > Systems and Technological Development Unit > Institute of Informatics and Telematics (IIT) > National Research Council (CNR) > via G. Moruzzi 1, I-56124 PISA, Italy > Phone: +39.0503153497 > Mobile: +39.3462122240 > Web: http://www.iit.cnr.it/mario.loffredo _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
