> -----Original Message----- > From: Gavin Brown <gavin.br...@icann.org> > Sent: Friday, June 14, 2024 8:32 AM > To: Hollenbeck, Scott <shollenb...@verisign.com> > Cc: rfc-edi...@rfc-editor.org; a...@hxr.us; superu...@gmail.com; > orie@transmute.industries; gal...@elistx.com; i...@antoin.nl; regext@ietf.org > Subject: [EXTERNAL] Re: [Ext] [Technical Errata Reported] RFC9083 (7985) > > 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. > > Hi Scott, > > > On 12 Jun 2024, at 17:42, Hollenbeck, Scott <shollenb...@verisign.com> > wrote: > > > > I'm inclined to reject this report. The example cited in Figure 28 is > > described > in the text as a "common response body", not a complete RDAP response. The > error response body is described in the context of a complete RDAP response > in Figure 29, which includes an rdapConformance data structure. As such, the > examples in the two figures are fine as-is. > > I'm puzzled by this. What is actually meant by "common response body", and > in what way does the stipulation in Section 4.1 not apply to it?
[SAH] It was intended to describe a set of elements, not a complete response, that would be commonly returned to identify an error condition. A complete response that includes those elements, and an rdapConformance element, is described in the very next figure. Scott _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
