Andy, I agree that that's an incorrect interpretation. Content is part of the response, too, and as such it has to be included when the response is constructed/formed/assembled/whatever.
Scott > -----Original Message----- > From: Andrew Newton (andy) <a...@hxr.us> > Sent: Tuesday, February 20, 2024 12:23 PM > To: Hollenbeck, Scott <shollenb...@verisign.com> > Cc: ietf=40antoin...@dmarc.ietf.org <i...@antoin.nl>; > mario.loffredo=40iit.cnr...@dmarc.ietf.org <mario.loffr...@iit.cnr.it>; > 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. > > "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://secure- > web.cisco.com/1aRHex_IkhlvhcngHtfTqhMihpaDNXSofjCvrnjGt > > QMqBFCRwGiZ4QCyMvPbtu7UnrfiOhZpDo6N3T1GhT1saLnyEcQTnS5Mb- > iJJh-a67AdziM > > IfBhYnpPfnVTkoB3Ro_-K- > NR4iDDwMtpumc5MtAHaD4yMabD339m6crnCcgZUL9bmk2FBr > > > DEiEAI9FE5Fkco9VxNIBLpPxatQoMX8ULYqUBrDJSs3MJEaDDuJp_8NcAe5FiYoI > n6jKcm > > V0kXWpYV0onfL2OMPoPo_-r28KHVMTb57M8nDUEkEQUW5gc- > yK_vKKQ2AeN6H4vMiyKgLl > > /https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-rir > > -search%2F05%2F > > > > > > > > > > > > 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://secure-web.cisco.com/1XXENLm7ayVnYl_0DoXxrulXmswCsE7Tiy- > eBRNPZ > > 6g67J7Jgj043VzUTsL49iOYB-d- > gk7_xlrAnVfYvWQTE5jHkqdPQkxZoFSOuQVErAT5b5r > > > OilhXtJMXQItgOR_nPRe1y9Ya2cumBjJe51jO0ywyc1ElcY0eSkkcnITMH_6eIvEp > v5con > > adzqV5Rnh8PMP3vGfBmxCO8yKeQz765C4N3L-L-Fw6dpZNvqkBRf8oH- > J9ujRRtwmBUFkK > > hAfurq5dkigzHEzqfTFYVmP5BZg9- > I5GMvXq1aJKVt6kWdTpRr_7hOlMW6lqkACBgWI4vV > > /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > > > _______________________________________________ > > > > regext mailing list > > > > regext@ietf.org > > > > https://secure-web.cisco.com/1XXENLm7ayVnYl_0DoXxrulXmswCsE7Tiy- > eBRNPZ > > 6g67J7Jgj043VzUTsL49iOYB-d- > gk7_xlrAnVfYvWQTE5jHkqdPQkxZoFSOuQVErAT5b5r > > > OilhXtJMXQItgOR_nPRe1y9Ya2cumBjJe51jO0ywyc1ElcY0eSkkcnITMH_6eIvEp > v5con > > adzqV5Rnh8PMP3vGfBmxCO8yKeQz765C4N3L-L-Fw6dpZNvqkBRf8oH- > J9ujRRtwmBUFkK > > hAfurq5dkigzHEzqfTFYVmP5BZg9- > I5GMvXq1aJKVt6kWdTpRr_7hOlMW6lqkACBgWI4vV > > /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > > > -- > > > > 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://secure-web.cisco.com/1vVb829HGCwPxZxHtbhAYqvDJ- > krBWHW5hpLiS0Y9F > > 4lEaRfebXO4jocI3n3- > 9EdNt2D9tBcLsnRPWSO88NgGxGFpUEtfUp4GPHGyGAE0S2IMSpY > > > _CmHmFI6McAIteydKlpqa5nTXdGT3T4m7NRfatY4kRc7mUYTGT1D1tlAshmX > hrYMOP0efV > > - > aE4SE31j_ITd7SIHvxpgXP_pumeHia2Bxg9sxgJSghjHzfwSkkLXiZehYoFMFwkMI > wn7v > > cEONAIVortYg9GXEciG-MT3NRZFqRvPwj4p-2CBBJ- > eDXj0DnmnHvqN0JHj17NGeapyUr/ > > http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo > > > > > > > > _______________________________________________ > > regext mailing list > > regext@ietf.org > > https://secure-web.cisco.com/1XXENLm7ayVnYl_0DoXxrulXmswCsE7Tiy- > eBRNPZ > > 6g67J7Jgj043VzUTsL49iOYB-d- > gk7_xlrAnVfYvWQTE5jHkqdPQkxZoFSOuQVErAT5b5r > > > OilhXtJMXQItgOR_nPRe1y9Ya2cumBjJe51jO0ywyc1ElcY0eSkkcnITMH_6eIvEp > v5con > > adzqV5Rnh8PMP3vGfBmxCO8yKeQz765C4N3L-L-Fw6dpZNvqkBRf8oH- > J9ujRRtwmBUFkK > > hAfurq5dkigzHEzqfTFYVmP5BZg9- > I5GMvXq1aJKVt6kWdTpRr_7hOlMW6lqkACBgWI4vV > > /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
