How about this: ---- All RDAP endpoints referenced by the URLs in the array MUST return identical responses for the same RDAP query, except that the “notices” data structure MAY contain an object informing the client of the identity of the endpoint. If such an object is provided it SHOULD use the registered notices and remarks type value of “service node identification” and it SHOULD be returned by all endpoints.
The “notices” structure is only permitted at the top level of a response and contains information about the service or response rather than about the object involved. ---- Which requires in IANA considerations: ---- IANA is requested to add that value to the https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml registry. ---- My colleague, who suggested these words, added "The places to bike shed is over whether an endpoint MAY or SHOULD return that object, and whether it SHOULD or MUST have a fixed value, and whether all endpoints SHOULD or MUST return the object if any do." I think on the whole, thats a might fine list of bike sheds. I don't know the answer to any of them. I tend to MAY return, but SHOULD be a consistent (if not fixed) value, and all endpoints MUST return the object if any do. My reasoning is. that the debug utility is only present if they all do it, so it is all or none. But, since it is not always needed, it can be turned off and on which goes to MAY. Consistency is key; the variance should be to identify a node, amongst all nodes. Or software version. But, definitionally that cannot be "identical" because.. well you might have upgraded only one node. So consistent, is not SHOULD or MUST be a fixed value. -G On Sat, Aug 22, 2020 at 2:27 AM Marc Blanchet <marc.blanc...@viagenie.ca> wrote: > > On 16 Aug 2020, at 19:27, George Michaelson wrote: > > > I would like to see some allowance of limited metadata about which > > node responded, or other information variance. If thats confined to > > comments in the outer protocol, it means the response inline cannot be > > used to debug specific problems with the node which responded. > > > > We see this all the time in DNS: The lack of information about the > > service methods used to supply a response makes debug significantly > > harder. > > > > in-band introspection is useful. It isn't about the response, its > > about how the response came to be. > > I get your point. Can you provide some text or some proposal on that > matter? > > Marc. > > > > > -G > > > > On Thu, Aug 13, 2020 at 9:40 PM Gavin Brown > > <gavin.br...@centralnic.com> wrote: > >> > >>> On 12 Aug 2020, at 17:18, Marc Blanchet <marc.blanc...@viagenie.ca> > >>> wrote: > >>> > >>> well, already added text in the published draft yesterday. > >>> > >>> https://www.ietf.org/internet-drafts/draft-blanchet-regext-rfc7484bis-00.txt > >>> > >>> extract of my added text: > >>> « All RDAP endpoints referenced by the URLs in the array MUST > >>> return > >>> identical responses for the same RDAP query. » > >>> > >>> would that work? > >> > >> Looks good to me. > >> > >> G. > >> > >> -- > >> Gavin Brown > >> Head of Registry Services and Chief Innovation Officer > >> CentralNic Group plc (LSE:CNIC) > >> https://www.centralnic.com > >> > >> Tel: +44.7548243029 > >> > >> CentralNic Group plc is a company registered in England and Wales > >> with company number 8576358. Registered Offices: Saddlers House, > >> Gutter Lane, London EC2V 6AE. > >> > >> _______________________________________________ > >> 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
