Re: [auth48] AUTH48: RFC-to-be 9457 <draft-ietf-httpapi-rfc7807bis-07> for your review

Karen Moore <kmoore@amsl.com> Thu, 27 July 2023 07:06 UTC

Return-Path: <kmoore@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2E7C14CE4B; Thu, 27 Jul 2023 00:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fldeui1oBIAJ; Thu, 27 Jul 2023 00:06:39 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10680C14CE22; Thu, 27 Jul 2023 00:06:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E9B6A424B432; Thu, 27 Jul 2023 00:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e8NMEW352vh; Thu, 27 Jul 2023 00:06:38 -0700 (PDT)
Received: from [IPv6:2001:67c:1232:144:f821:8a2a:6095:6337] (unknown [IPv6:2001:67c:1232:144:f821:8a2a:6095:6337]) by c8a.amsl.com (Postfix) with ESMTPSA id B21F1424B426; Thu, 27 Jul 2023 00:06:38 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Karen Moore <kmoore@amsl.com>
In-Reply-To: <68556ED1-1C2C-41D6-B51B-AA197BFD5ECE@amsl.com>
Date: Thu, 27 Jul 2023 00:06:37 -0700
Cc: Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>, httpapi-ads@ietf.org, httpapi-chairs@ietf.org, Darrel Miller <darrel@tavis.ca>, "Murray S. Kucherawy" <superuser@gmail.com>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7779666E-555A-44E1-A48C-AAC519678026@amsl.com>
References: <20230720210004.24BE64C1A1@rfcpa.amsl.com> <8B41145B-F527-44D1-ABD7-0A58F6128B9F@mnot.net> <B48A2D61-1E01-481A-827A-C8FFD24803A9@amsl.com> <5E825791-83A0-458B-BBEA-6FA2B826A39B@amsl.com> <D44C0D2B-19F5-4BFC-BBC4-AC5C4329114C@mnot.net> <98CF652D-AA98-4A1A-9BCA-6456D57D346C@amsl.com> <6DA6EE12-3241-4094-BBCB-255BCCDA3F02@amsl.com> <90F9631E-E494-45B2-88CF-FA8469B4E6CC@mnot.net> <8B8AA778-0635-45D6-A271-35C74500B3BC@amsl.com> <CAC5fHGN0CKpPHf=emdEdoj6QGhxNcgA4W9Bv+5UBVnqe=VznWw@mail.gmail.com> <68556ED1-1C2C-41D6-B51B-AA197BFD5ECE@amsl.com>
To: Sanjay Dalal <sanjay.dalal@cal.berkeley.edu>, Erik Wilde <erik.wilde@dret.net>, Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/hgx2UOvX9oJCtqKWRBXlCy-ClfU>
Subject: Re: [auth48] AUTH48: RFC-to-be 9457 <draft-ietf-httpapi-rfc7807bis-07> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jul 2023 07:06:43 -0000

Hello Erik,

We’re sorry to hear that you are on sick leave.  Thank you for providing your approval; we have noted it on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9457).

We now await approval from Mark.

Best regards,
RFC Editor/kc 


> On Jul 26, 2023, at 8:51 PM, Erik Wilde <erik.wilde@dret.net> wrote:
> 
> hello karen
> 
> On Jul 27, 2023, at 02:43, Karen Moore <kmoore@amsl.com> wrote:
>> We now await approval from Mark and Erik before moving forward with publication.
> 
> sorry for the radio silence so far, i am on sick leave. i am fine with all the changes.
> 
> thanks and kind regards,
> 
> dret.
> 
> -- 
> Erik Wilde | mailto:erik.wilde@dret.net    |
>          | https://youtube.com/ErikWilde |
> 



> On Jul 26, 2023, at 5:43 PM, Karen Moore <kmoore@amsl.com> wrote:
> 
> Hi Sanjay,
> 
> Thank you for your reply. We have noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9457).
> 
> We now await approval from Mark and Erik before moving forward with publication.
> 
> Best regards,
> RFC Editor/kc
> 
>> On Jul 26, 2023, at 11:51 AM, Sanjay Dalal <sanjay.dalal@cal.berkeley.edu> wrote:
>> 
>> +1 from me. Thank you Karen and everyone.  
>> 
>> On Wed, Jul 26, 2023 at 11:14 AM Karen Moore <kmoore@amsl.com> wrote:
>> Great! Type “rnc” is now reflected in our files. 
>> 
>> Awaiting all author approvals before moving this document through the publication process.
>> 
>> FILES (please refresh):
>> 
>> The updated XML file is here:
>> https://www.rfc-editor.org/authors/rfc9457.xml
>> 
>> The updated output files are here:
>> https://www.rfc-editor.org/authors/rfc9457.txt
>> https://www.rfc-editor.org/authors/rfc9457.pdf
>> https://www.rfc-editor.org/authors/rfc9457.html
>> 
>> This diff file shows all changes made during AUTH48:
>> https://www.rfc-editor.org/authors/rfc9457-auth48diff.html
>> 
>> This diff file shows all changes made to date:
>> https://www.rfc-editor.org/authors/rfc9457-diff.html
>> 
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9457
>> 
>> Best, 
>> RFC Editor/kc
>> 
>> 
>>> On Jul 26, 2023, at 11:05 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>> 
>>> Yes, thank you!
>>> 
>>>> On 26 Jul 2023, at 10:28 am, Karen Moore <kmoore@amsl.com> wrote:
>>>> 
>>>> Hello authors,
>>>> 
>>>> For the sourcecode in Appendix B, would it be agreeable to use “rnc” for the type? This is on the list of preferred types (https://www.rfc-editor.org/materials/sourcecode-types.txt), and it stands for "Relax NG Compact”.
>>>> 
>>>> Thanks,
>>>> RFC Editor/kc
>>>> 
>>>>> On Jul 25, 2023, at 5:55 PM, Karen Moore <kmoore@amsl.com> wrote:
>>>>> 
>>>>> Hi Mark,
>>>>> 
>>>>> We have changed  "problem(s) encountered" to "problem encountered” in the Introduction.
>>>>> 
>>>>> FILES (please refresh)
>>>>> 
>>>>> The updated XML file is here:
>>>>> https://www.rfc-editor.org/authors/rfc9457.xml
>>>>> 
>>>>> The updated output files are here:
>>>>> https://www.rfc-editor.org/authors/rfc9457.txt
>>>>> https://www.rfc-editor.org/authors/rfc9457.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9457.html
>>>>> 
>>>>> This diff file shows all changes made during AUTH48:
>>>>> https://www.rfc-editor.org/authors/rfc9457-auth48diff.html
>>>>> 
>>>>> This diff file shows all changes made to date:
>>>>> https://www.rfc-editor.org/authors/rfc9457-diff.html
>>>>> 
>>>>> For the AUTH48 status of this document, please see:
>>>>> https://www.rfc-editor.org/auth48/rfc9457
>>>>> 
>>>>> Best, 
>>>>> RFC Editor/kc
>>>>> 
>>>>> 
>>>>>> On Jul 25, 2023, at 2:00 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> One immediate change: could you please change "problem(s) encountered" to "problem encountered" in the Introduction?
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> 
>>>>>>> On 25 Jul 2023, at 12:25 pm, Karen Moore <kmoore@amsl.com> wrote:
>>>>>>> 
>>>>>>> Hi Mark,
>>>>>>> 
>>>>>>> This change is now reflected in our files. Note that we will get back to you shortly regarding the sourcecode type for the code in Appendix B. Aside from that, please feel free to provide further changes (if needed) and approvals.
>>>>>>> 
>>>>>>> FILES (please refresh)
>>>>>>> 
>>>>>>> The updated XML file is here:
>>>>>>> https://www.rfc-editor.org/authors/rfc9457.xml
>>>>>>> 
>>>>>>> The updated output files are here:
>>>>>>> https://www.rfc-editor.org/authors/rfc9457.txt
>>>>>>> https://www.rfc-editor.org/authors/rfc9457.pdf
>>>>>>> https://www.rfc-editor.org/authors/rfc9457.html
>>>>>>> 
>>>>>>> This diff file shows all changes made during AUTH48:
>>>>>>> https://www.rfc-editor.org/authors/rfc9457-auth48diff.html
>>>>>>> 
>>>>>>> This diff file shows all changes made to date:
>>>>>>> https://www.rfc-editor.org/authors/rfc9457-diff.html
>>>>>>> 
>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>> https://www.rfc-editor.org/auth48/rfc9457
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> 
>>>>>>> RFC Editor/kc
>>>>>>> 
>>>>>>> 
>>>>>>>> On 24 Jul 2023, at 7:02 pm, Karen Moore <kmoore@amsl.com> wrote:
>>>>>>>> 
>>>>>>>> Perhaps:
>>>>>>>> Extension arrays and objects are serialized into the XML format by
>>>>>>>> considering an element containing a child or children to represent an
>>>>>>>> object, except for elements containing only one or more child elements 
>>>>>>>> named "i"', which are considered arrays.
>>>>>>> 
>>>>>>> LGTM, thanks!
>>>>>>> 
>>>>>>> --
>>>>>>> Mark Nottingham   https://www.mnot.net/
>>>>>>> 
>>>>>>>> On Jul 24, 2023, at 7:02 PM, Karen Moore <kmoore@amsl.com> wrote:
>>>>>>>> 
>>>>>>>> Hi Mark,
>>>>>>>> 
>>>>>>>> Thank you for your reply. We have updated our files accordingly. We have a few more questions/clarifications.
>>>>>>>> 
>>>>>>>> 1) FYI: We changed “Notational Conventions” to “Requirements Language” to follow RFC 7807 more closely (it's author choice here, but FWIW, 285 RFCs use “Notational Conventions" and 1465 use “Requirements Language”).
>>>>>>>> 
>>>>>>>> 2) There is currently no guidance in the style guide about how terms with “(s)” are read. The Chicago Manual of Style recommends rephrasing for clarity. Please let us know if the following update may be agreeable.
>>>>>>>> 
>>>>>>>>>> b) Since "element(s)" is read as singular, we updated "only child
>>>>>>>>>> element(s)" to "only a child element(s)" and "which are...arrays" to
>>>>>>>>>> "which is...an array".
>>>>>>>>> 
>>>>>>>>> [MN] Personally, I read foo(s) as plural, not singular. Is this something in a style guide somewhere?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Perhaps:
>>>>>>>> Extension arrays and objects are serialized into the XML format by
>>>>>>>> considering an element containing a child or children to represent an
>>>>>>>> object, except for elements containing only one or more child elements 
>>>>>>>> named "i"', which are considered arrays.
>>>>>>>> 
>>>>>>>> 3) We have removed type “html” from the sourcecode, and we are checking on the use of “relax-ng-compact-syntax”; we will get back to you shortly on this.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> FILES
>>>>>>>> The updated XML file is here:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9457.xml
>>>>>>>> 
>>>>>>>> The updated output files are here:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9457.txt
>>>>>>>> https://www.rfc-editor.org/authors/rfc9457.pdf
>>>>>>>> https://www.rfc-editor.org/authors/rfc9457.html
>>>>>>>> 
>>>>>>>> This diff file shows all changes made during AUTH48:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9457-auth48diff.html
>>>>>>>> 
>>>>>>>> This diff file shows all changes made to date:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9457-diff.html
>>>>>>>> 
>>>>>>>> Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC.
>>>>>>>> 
>>>>>>>> Please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author prior to moving forward in the publication process.
>>>>>>>> 
>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9457
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> 
>>>>>>>> RFC Editor/kc
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Jul 21, 2023, at 10:57 AM, Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 20 Jul 2023, at 2:00 pm, rfc-editor@rfc-editor.org wrote:
>>>>>>>>>> 
>>>>>>>>>> Authors,
>>>>>>>>>> 
>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>>>>>>> 
>>>>>>>>>> 1) <!-- [rfced] Section 1. RFC 7807 is mentioned in the running text, but
>>>>>>>>>> there is no corresponding entry in the References section. We
>>>>>>>>>> have added the reference entry to the Informative References
>>>>>>>>>> section; please let us know of any objections.
>>>>>>>>>> 
>>>>>>>>>> Original:
>>>>>>>>>> See Appendix D for a list of changes from RFC 7807.
>>>>>>>>>> 
>>>>>>>>>> Current:
>>>>>>>>>> See Appendix D for a list of changes from [RFC7807].
>>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> That's fine.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 2) <!--[rfced] Would you like to update the title of Section 2 from
>>>>>>>>>> "Notational Conventions" to "Requirements Language" since the
>>>>>>>>>> latter form is used more frequently in RFCs, plus it will match
>>>>>>>>>> RFC 7807 more closely (which uses "Requirements")?
>>>>>>>>>> 
>>>>>>>>>> Original:
>>>>>>>>>> 2.  Notational Conventions
>>>>>>>>>> 
>>>>>>>>>> Perhaps:
>>>>>>>>>> 2. Requirements Language
>>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> My experience is that 'notational conventions' is more common, but maybe that's just the corner of the RFC Series that I inhabit.
>>>>>>>>> 
>>>>>>>>> Sure. 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 3) <!-- [rfced] While we understand the original document was published with the text
>>>>>>>>>> we are questioning below, the questions are aimed at making the text as
>>>>>>>>>> correct as possible.  Please let us know if these updates are incorrect or
>>>>>>>>>> undesirable.
>>>>>>>>>> 
>>>>>>>>>> a) Should "A problem's type URI" be "A problem type URI" (similar to "A problem 
>>>>>>>>>> type definition" in the next paragraph)? Please let us know if/how we may update.
>>>>>>>>>> 
>>>>>>>>>> Original:
>>>>>>>>>> A problem's type URI SHOULD resolve to HTML [HTML5] documentation
>>>>>>>>>> that explains how to resolve the problem.
>>>>>>>>>> 
>>>>>>>>>> A problem type definition MAY specify...
>>>>>>>>>> 
>>>>>>>>>> Perhaps:
>>>>>>>>>> A problem type URI SHOULD resolve to HTML [HTML5] documentation
>>>>>>>>>> that explains how to resolve the problem.
>>>>>>>>>> 
>>>>>>>>>> A problem type definition MAY specify...
>>>>>>>>> 
>>>>>>>>> Yes please.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> b) Since "element(s)" is read as singular, we updated "only child
>>>>>>>>>> element(s)" to "only a child element(s)" and "which are...arrays" to
>>>>>>>>>> "which is...an array".
>>>>>>>>>> 
>>>>>>>>>> Original:
>>>>>>>>>> Extension arrays and objects are serialized into the XML format by
>>>>>>>>>> considering an element containing a child or children to represent an
>>>>>>>>>> object, except for elements that contain only child element(s) named
>>>>>>>>>> 'i', which are considered arrays.
>>>>>>>>>> 
>>>>>>>>>> Current:
>>>>>>>>>> Extension arrays and objects are serialized into the XML format by
>>>>>>>>>> considering an element containing a child or children to represent an
>>>>>>>>>> object, except for elements that contain only a child element(s) named
>>>>>>>>>> "i"', which is considered an array.
>>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> Personally, I read foo(s) as plural, not singular. Is this something in a style guide somewhere?
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 4) <!--[rfced] Appendix A. May we add a space between "RFC" and "7807"
>>>>>>>>>> within the JSON Schema to align with the suggested format in the
>>>>>>>>>> RFC Style Guide (RFC 7322)?
>>>>>>>>>> 
>>>>>>>>>> Original:
>>>>>>>>>> "$schema": "https://json-schema.org/draft/2020-12/schema",
>>>>>>>>>> "title": "An RFC7807 problem object",
>>>>>>>>>> 
>>>>>>>>>> Perhaps:
>>>>>>>>>> "$schema": "https://json-schema.org/draft/2020-12/schema",
>>>>>>>>>> "title": "An RFC 7807 problem object",
>>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> Of course.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 5) <!-- [rfced] Please review the "type" attribute of each sourcecode
>>>>>>>>>> element in the XML file to ensure correctness. In particular,
>>>>>>>>>> "relax-ng-compact-syntax" and "html" need review as they are
>>>>>>>>>> not in our current list of preferred values for "type" (see
>>>>>>>>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>).
>>>>>>>>>> If this list does not contain an applicable type, feel free to
>>>>>>>>>> suggest a new one. Also, it is acceptable to leave the "type"
>>>>>>>>>> attribute not set.
>>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> It makes sense to omit 'html', but I wonder whether relax-ng-compact is worth putting in the list. If you think not, best omit that too.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 6) <!-- [rfced] Terminology
>>>>>>>>>> 
>>>>>>>>>> a) May we expand "RDFa" and "XSLT" in the text as follows? Please let us
>>>>>>>>>> know if this is agreeable or if you prefer otherwise.
>>>>>>>>>> 
>>>>>>>>>> RDFa
>>>>>>>>>> Original:
>>>>>>>>>> or by defining a mapping into RDFa [RDFA].
>>>>>>>>>> 
>>>>>>>>>> Current:
>>>>>>>>>> or by defining a mapping into a Resource Description 
>>>>>>>>>> Framework in Attributes (RDFa) [RDFA].
>>>>>>>>>> 
>>>>>>>>>> XSLT
>>>>>>>>>> Original:
>>>>>>>>>> When using the XML format, it is possible to embed an XML processing
>>>>>>>>>> instruction in the XML that instructs clients to transform the XML,
>>>>>>>>>> using the referenced XSLT code [XSLT]. 
>>>>>>>>>> 
>>>>>>>>>> Current:
>>>>>>>>>> When using the XML format, it is possible to embed an XML processing
>>>>>>>>>> instruction in the XML that instructs clients to transform the XML,
>>>>>>>>>> using the referenced XSL Transformations (XSLT) code [XSLT]. 
>>>>>>>>> 
>>>>>>>>> That's fine.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> ...  
>>>>>>>>>> b) We note that "problem details" appears as lowercase throughout
>>>>>>>>>> the document, except for 1 instance of "HTTP Problem Details". Please
>>>>>>>>>> confirm if this instance is okay as is or if you would like to make it
>>>>>>>>>> lowercase for consistency.
>>>>>>>>>> 
>>>>>>>>>> Original:
>>>>>>>>>> This section presents a non-normative JSON Schema [JSON-SCHEMA] for
>>>>>>>>>> HTTP Problem Details. 
>>>>>>>>>> 
>>>>>>>>>> ...
>>>>>>>>> 
>>>>>>>>> Lowercase works.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> c) For consistency, we updated 1 instance of "HTTP-generic software" 
>>>>>>>>>> to "generic HTTP software". Please let us know if you prefer 
>>>>>>>>>> otherwise.
>>>>>>>>>> 
>>>>>>>>>> Original:
>>>>>>>>>> The API's designer might decide to use
>>>>>>>>>> the 403 Forbidden status code to inform HTTP-generic software (such
>>>>>>>>>> as client libraries, caches, and proxies) of the response's general
>>>>>>>>>> semantics.
>>>>>>>>>> 
>>>>>>>>>> Current:
>>>>>>>>>> The API's designer might decide to use
>>>>>>>>>> the 403 Forbidden status code to inform generic HTTP software (such
>>>>>>>>>> as client libraries, caches, and proxies) of the response's general
>>>>>>>>>> semantics.
>>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> That's fine.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 7) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
>>>>>>>>>> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>>>>>>>> and let us know if any changes are needed.
>>>>>>>>>> 
>>>>>>>>>> Note that our script did not flag any words in particular, but this should 
>>>>>>>>>> still be reviewed as a best practice.
>>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> Understood.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Thank you.
>>>>>>>>> 
>>>>>>>>> Thank you!
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> RFC Editor/st/kc
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jul 20, 2023, at 1:57 PM, rfc-editor@rfc-editor.org wrote:
>>>>>>>>>> 
>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>> 
>>>>>>>>>> Updated 2023/07/20
>>>>>>>>>> 
>>>>>>>>>> RFC Author(s):
>>>>>>>>>> --------------
>>>>>>>>>> 
>>>>>>>>>> Instructions for Completing AUTH48
>>>>>>>>>> 
>>>>>>>>>> Your document has now entered AUTH48.  Once it has been reviewed and 
>>>>>>>>>> approved by you and all coauthors, it will be published as an RFC.  
>>>>>>>>>> If an author is no longer available, there are several remedies 
>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>>>>>>> 
>>>>>>>>>> You and you coauthors are responsible for engaging other parties 
>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing 
>>>>>>>>>> your approval.
>>>>>>>>>> 
>>>>>>>>>> Planning your review 
>>>>>>>>>> ---------------------
>>>>>>>>>> 
>>>>>>>>>> Please review the following aspects of your document:
>>>>>>>>>> 
>>>>>>>>>> *  RFC Editor questions
>>>>>>>>>> 
>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor 
>>>>>>>>>> that have been included in the XML file as comments marked as 
>>>>>>>>>> follows:
>>>>>>>>>> 
>>>>>>>>>> <!-- [rfced] ... -->
>>>>>>>>>> 
>>>>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>>>> 
>>>>>>>>>> *  Changes submitted by coauthors 
>>>>>>>>>> 
>>>>>>>>>> Please ensure that you review any changes submitted by your 
>>>>>>>>>> coauthors.  We assume that if you do not speak up that you 
>>>>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>>>> 
>>>>>>>>>> *  Content 
>>>>>>>>>> 
>>>>>>>>>> Please review the full content of the document, as this cannot 
>>>>>>>>>> change once the RFC is published.  Please pay particular attention to:
>>>>>>>>>> - IANA considerations updates (if applicable)
>>>>>>>>>> - contact information
>>>>>>>>>> - references
>>>>>>>>>> 
>>>>>>>>>> *  Copyright notices and legends
>>>>>>>>>> 
>>>>>>>>>> Please review the copyright notice and legends as defined in
>>>>>>>>>> RFC 5378 and the Trust Legal Provisions 
>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/).
>>>>>>>>>> 
>>>>>>>>>> *  Semantic markup
>>>>>>>>>> 
>>>>>>>>>> Please review the markup in the XML file to ensure that elements of  
>>>>>>>>>> content are correctly tagged.  For example, ensure that <sourcecode> 
>>>>>>>>>> and <artwork> are set correctly.  See details at 
>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>>>>>> 
>>>>>>>>>> *  Formatted output
>>>>>>>>>> 
>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the 
>>>>>>>>>> formatted output, as generated from the markup in the XML file, is 
>>>>>>>>>> reasonable.  Please note that the TXT will have formatting 
>>>>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Submitting changes
>>>>>>>>>> ------------------
>>>>>>>>>> 
>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>>>>>>>>>> the parties CCed on this message need to see your changes. The parties 
>>>>>>>>>> include:
>>>>>>>>>> 
>>>>>>>>>> *  your coauthors
>>>>>>>>>> 
>>>>>>>>>> *  rfc-editor@rfc-editor.org (the RPC team)
>>>>>>>>>> 
>>>>>>>>>> *  other document participants, depending on the stream (e.g., 
>>>>>>>>>> IETF Stream participants are your working group chairs, the 
>>>>>>>>>> responsible ADs, and the document shepherd).
>>>>>>>>>> 
>>>>>>>>>> *  auth48archive@rfc-editor.org, which is a new archival mailing list 
>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion 
>>>>>>>>>> list:
>>>>>>>>>> 
>>>>>>>>>> *  More info:
>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>>>>>>> 
>>>>>>>>>> *  The archive itself:
>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>>>>> 
>>>>>>>>>> *  Note: If only absolutely necessary, you may temporarily opt out 
>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>>>>>> If needed, please add a note at the top of the message that you 
>>>>>>>>>> have dropped the address. When the discussion is concluded, 
>>>>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and 
>>>>>>>>>> its addition will be noted at the top of the message. 
>>>>>>>>>> 
>>>>>>>>>> You may submit your changes in one of two ways:
>>>>>>>>>> 
>>>>>>>>>> An update to the provided XML file
>>>>>>>>>> — OR —
>>>>>>>>>> An explicit list of changes in this format
>>>>>>>>>> 
>>>>>>>>>> Section # (or indicate Global)
>>>>>>>>>> 
>>>>>>>>>> OLD:
>>>>>>>>>> old text
>>>>>>>>>> 
>>>>>>>>>> NEW:
>>>>>>>>>> new text
>>>>>>>>>> 
>>>>>>>>>> You do not need to reply with both an updated XML file and an explicit 
>>>>>>>>>> list of changes, as either form is sufficient.
>>>>>>>>>> 
>>>>>>>>>> We will ask a stream manager to review and approve any changes that seem
>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>>>>>>>>>> and technical changes.  Information about stream managers can be found in 
>>>>>>>>>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Approving for publication
>>>>>>>>>> --------------------------
>>>>>>>>>> 
>>>>>>>>>> To approve your RFC for publication, please reply to this email stating
>>>>>>>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>>>>>>>>> as all the parties CCed on this message need to see your approval.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Files 
>>>>>>>>>> -----
>>>>>>>>>> 
>>>>>>>>>> The files are available here:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9457.xml
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9457.html
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9457.pdf
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9457.txt
>>>>>>>>>> 
>>>>>>>>>> Diff file of the text:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9457-diff.html
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9457-rfcdiff.html (side by side)
>>>>>>>>>> 
>>>>>>>>>> Diff of the XML: 
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9457-xmldiff1.html
>>>>>>>>>> 
>>>>>>>>>> XMLv3 file that is a best effort to capture v3-related format updates 
>>>>>>>>>> only: 
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9457.form.xml
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Tracking progress
>>>>>>>>>> -----------------
>>>>>>>>>> 
>>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9457
>>>>>>>>>> 
>>>>>>>>>> Please let us know if you have any questions.  
>>>>>>>>>> 
>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>> 
>>>>>>>>>> RFC Editor
>>>>>>>>>> 
>>>>>>>>>> --------------------------------------
>>>>>>>>>> RFC9457 (draft-ietf-httpapi-rfc7807bis-07)
>>>>>>>>>> 
>>>>>>>>>> Title            : Problem Details for HTTP APIs
>>>>>>>>>> Author(s)        : M. Nottingham, E. Wilde, S. Dalal
>>>>>>>>>> WG Chair(s)      : Darrel Miller, Rich Salz
>>>>>>>>>> Area Director(s) : Murray Kucherawy, Francesca Palombini
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Mark Nottingham   https://www.mnot.net/
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Mark Nottingham   https://www.mnot.net/
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>> 
>> 
>