"construction of the response" can be interpreted strictly to mean only the JSON structure of the response. IMHO, that is an incorrect interpretation nor does it track with RDAP as it is used because profile extensions such as the ICANN and NRO extensions also dictate content not just structure.
-andy On Tue, Feb 20, 2024 at 10:20 AM Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org> wrote: > > I don’t understand the confusion regarding the text in 9083. It might not > include BCP 14 key words, but I believe the intention is clear. Looking at > the two sentences: > > > > “A response to a "help" request will include identifiers for all of the > specifications supported by the server.” > > > > *will include* isn’t a BCP 14 MUST, but I don’t think it’s ambiguous. > > > > “A response to any other request will include only identifiers for the > specifications used in the construction of the response.” > > > > Similarly, *will include only identifiers for the specifications used in the > construction of the response* describes the identifiers that are to be > included in any other response. If a client needs to implement something > other than 9083 to correctly interpret and process a response, any identifier > that describes a specification that’s needed to “understand” the response > will be included. If that’s not clear, what am I missing? > > > > Scott > > > > From: regext <regext-boun...@ietf.org> On Behalf Of Antoin Verschuren > Sent: Monday, February 19, 2024 10:42 AM > To: Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org> > Cc: regext <regext@ietf.org> > Subject: [EXTERNAL] Re: [regext] WG LAST CALL > draft-ietf-regext-rdap-rir-search > > > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > So, if I understand this correctly, the chairs asked the document shepherd to > declare that there were no substantial changes made during WGLC between > versions 05 and 07 and all raised issues were addressed. > > > > The answer below I interpret as: We would like the permission from the WG to > not only substantially change draft-ietf-regext-rdap-rir-search in a next > version that we want to send to the IESG, but on top of that also clarify or > even change the interpretation of RFC 9083. > > > > If this is the question, then we need to have a discussion what this will > mean to other documents and it’s interpretation of RFC 9083 first, and > perhaps even write this clarification down in a separate document if that is > needed. > > When that is done and consensus is reached, we must issue a new WGLC for > the next version of draft-ietf-regext-rdap-rir-search if that will contain > these substantial changes suggested by the WG. > > > > In order to reach consensus, all comments and support during a complete WGLC > must be for a stable document. Otherwise we don’t know if people agree with > what version of the document and which interpretation of RFC 9083. > > > > Regards, > > > > Antoin > > > > > > Op 19 feb. 2024, om 13:07 heeft Mario Loffredo > <mario.loffredo=40iit.cnr...@dmarc.ietf.org> het volgende geschreven: > > > > Hi Antoin, > > after a private discussion between James, Tom, Jasdip and me, we agreed on > the following: > > 1) Some minor edits that don't substantially change the draft but clarify the > meaning of some sentences will be done in next version > > 2) We would like the WG members express their own opinions on the substantial > matter below. > > RFC 9083 states the following for rdapConformance included in non-“help” RDAP > responses: > > · The data structure named "rdapConformance" is an array of strings, > each providing a hint as to the specifications used in the construction of > the response. > > · A response to any other request will include only identifiers for > the specifications used in the construction of the response. > > There is no normative language that specifies exactly what identifiers are > included in the response, where there is the language of “hints” and “used in > construction of the response”. Below are options for what identifiers are > included in the “rdapConformance” array that could be captured in the RDAP > Extensions draft: > > Option 1) only the extension identifiers used to build the response with > regard to the fields > > Option 2) all of the extension identifiers that impact the build of the > response, hence with regard to fields, values, and query members / query > parameters used for the response (i.e. Option 1 + extension query identifiers > and extension identifiers impacting response values) > > Option 3) all of the extension identifiers defined by specs used to build > the response (i.e. Option 2 + any extension identifier defined by referenced > specs) > > > > Option 1 corresponds to a literal interpretation of normative language in RFC > 9083, while Option 2 extends its meaning. > > Option 3 is further extensive and corresponds to the interpretation used in > rir-search. To better explain their position, the authors asked me to add the > following note (please Tom and Jasdip elaborate, if you think I missed > something or didn't present correctly your point of view): > > "documents may mandate specific behaviour around identifiers for the purposes > of signalling, and it's fine for this sort of thing to override the > requirement above. (nro_rdap_profile_asn_flat_0 and > nro_rdap_profile_asn_hierarchical_0 are examples of this, where the document > itself requires implementations to pick one or the other, and that's fine.)" > > > > > > Best, > > Mario > > > > Il 05/02/2024 15:35, Antoin Verschuren ha scritto: > > Hi All, > > > > After some prolonged discussion, the chairs will now close this working group > last call that should have ended 11 December 2023. > > We have had comments and approval during WGLC from 4 working group > participants and the document shepherd and no objections. > > That has lead to 2 new versions of the document during WGLC that started with > version 05. > > > > The document shepherd for this document is Mario Loffredo. > > > > In order for the document to progress and sent to the IESG, the document > shepherd will need to do a final review of the following: > > > > 1. Please confirm all suggested changes have been addressed in version 07. > > 2. Please ask James Gould to confirm his changes have been addressed as he > promised to do another review. > > 3. Make sure the Nits are addressed. > > 4. Confirm that all changes between version 05 and version 07 are editorial > and not substantive. > > 5. When all the above concerns are addressed, please write the document > shepherd writeup. > > > > Thanks to everyone that contributed to this review! > > > > Regards, > > > > Jim and Antoin > > REGEXT WG Co-Chairs > > > > > > Op 27 nov. 2023, om 15:51 heeft Antoin Verschuren > <ietf=40antoin...@dmarc.ietf.org> het volgende geschreven: > > > > The document editors have indicated that the following document is ready for > submission to the IESG to be considered for publication as a Proposed > Standard: > > > > > > RDAP RIR Search > > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/ > > > > > > Please indicate your support or no objection for the publication of this > document by replying to this message on list (a simple “+1” is sufficient). > > > > If any working group member has questions regarding the publication of this > document please respond on the list with your concerns by close of business > everywhere, Monday, 11 December 2023. > > > > If there are no objections the document will be submitted to the IESG. > > > > The Document Shepherd for this document is Mario Loffredo. > > > > Thanks, > > > > Jim and Antoin > > REGEXT WG Co-Chairs > > _______________________________________________ > > regext mailing list > > regext@ietf.org > > https://www.ietf.org/mailman/listinfo/regext > > _______________________________________________ > > regext mailing list > > regext@ietf.org > > https://www.ietf.org/mailman/listinfo/regext > > -- > > Dott. Mario Loffredo > > Senior Technologist > > Technological Unit “Digital Innovation” > > Institute of Informatics and Telematics (IIT) > > National Research Council (CNR) > > via G. Moruzzi 1, I-56124 PISA, Italy > > Phone: +39.0503153497 > > Web: http://www.iit.cnr.it/mario.loffredo > > > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
