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
