Kind regards,
Pawel On 14.06.24 15:15, Gavin Brown wrote:
Hi Scott,On 14 Jun 2024, at 13:38, Hollenbeck, Scott<shollenb...@verisign.com> wrote:-----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 describedin 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.Thanks, this is helpful to understand the intent of the text. My impression now is that Figure 28 isn't intended to be an example of a complete error response, rather it is intended to illustrate the additional properties that could be overlaid on top of a standard RDAP response (which would include rdapConformance, notices, etc). Is that correct? -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list --regext@ietf.org To unsubscribe send an email toregext-le...@ietf.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org