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

[Sanjay Dalal <[e-mail]>]

+1 from me. Thank you Karen and everyone.

On Wed, Jul 26, 2023 at 11:14 AM Karen Moore <[e-mail]> 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 <[e-mail]> wrote:
> >
> > Yes, thank you!
> >
> >> On 26 Jul 2023, at 10:28 am, Karen Moore <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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=
> [e-mail]> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 20 Jul 2023, at 2:00 pm, [e-mail] 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, [e-mail] 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
> >>>>>>>>
> >>>>>>>> *  [e-mail] (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).
> >>>>>>>>
> >>>>>>>> *  [e-mail], 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,
> >>>>>>>> [e-mail] 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/
> >
>
>