Re: [auth48] AUTH48: RFC-to-be 9440 <draft-ietf-httpbis-client-cert-field-06> for your review

[Karen Moore <[e-mail]>]

Hi Mike,

Our files now reflect “response” instead of “request”. Please let us know if you have any further updates or if the document is approved in its current form.

FILES (please refresh)

The updated XML file is here:
 https://www.rfc-editor.org/authors/rfc9440.xml

The updated output files are here:
 https://www.rfc-editor.org/authors/rfc9440.txt
 https://www.rfc-editor.org/authors/rfc9440.pdf
 https://www.rfc-editor.org/authors/rfc9440.html

This diff file shows all changes made during AUTH48:
 https://www.rfc-editor.org/authors/rfc9440-auth48diff.html

This diff shows only the changes made during the last edit round:
 https://www.rfc-editor.org/authors/rfc9440-lastdiff.html

This diff file shows all changes made to date:
 https://www.rfc-editor.org/authors/rfc9440-diff.html

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9440

We will await approval from Mike before moving forward with the publication process.

Thank you!
RFC Editor/kc


> On Jul 20, 2023, at 1:19 PM, Mike Bishop <[e-mail]> wrote:
> 
> You are, of course, correct -- that was intended to be the response, not the request.
> 
> -----Original Message-----
> From: Karen Moore <[e-mail]> 
> Sent: Thursday, July 20, 2023 1:34 AM
> To: Mike Bishop <[e-mail]>; Brian Campbell <[e-mail]>
> Cc: RFC Editor <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Francesca Palombini <[e-mail]>; [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9440 <draft-ietf-httpbis-client-cert-field-06> for your review
> 
> Hi Mike,
> 
> We have updated our files accordingly; please review and let us know if any further changes are needed. We have one additional question below.
> 
> 1)  Please confirm that the intension is to change “a response” to “a request” in the following:
> 
>> • Let’s spell out “a client-cert field name” instead, i.e. “If a TTRP 
>> encounters a request with Client-Cert or Client-Cert-Chain in the Vary header field….”
> 
> 
> Original:
>   If a TTRP encounters a response with a client-cert field name in the Vary
>   header field, it SHOULD prevent the user agent from caching the response
>   by transforming the value of the Vary response header field to *.
> 
> Current:
>   If a TTRP encounters a request with Client-Cert or Client-Cert-Chain in the
>   Vary header field (Section 12.5.5 of [HTTP]), it SHOULD prevent the user
>   agent from caching the response by transforming the value of the Vary
>   response header field to "*”.
> 
> 
> FILES (please refresh)
> The updated XML file is here:
> https://www.rfc-editor.org/authors/rfc9440.xml
> 
> The updated output files are here:
> https://www.rfc-editor.org/authors/rfc9440.txt
> https://www.rfc-editor.org/authors/rfc9440.pdf
> https://www.rfc-editor.org/authors/rfc9440.html
> 
> This diff file shows all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9440-auth48diff.html
> 
> This diff shows only the changes made during the last edit round:
> https://www.rfc-editor.org/authors/rfc9440-lastdiff.html
> 
> This diff file shows all changes made to date:
> https://www.rfc-editor.org/authors/rfc9440-diff.html
> 
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9440
> 
> We will await approval from Mike before moving forward with the publication process.
> 
> Thank you,
> RFC Editor/kc
> 
> 
>> On Jul 19, 2023, at 12:06 PM, Mike Bishop <[e-mail]> wrote:
>> 
>> Thanks for pointing these additional instances out.
>> 
>> In the next-to-last paragraph of 2.4:
>> 	• “Vary header field” should be unquoted and without <tt> per the style guide, since it’s not defined in this document. It should also reference Section 12.5.5 of HTTP for the definition.
>> 	• “Client-Cert header value” should be “Client-Cert header field value”
>> 	• Let’s spell out “a client-cert field name” instead, i.e. “If a TTRP encounters a request with Client-Cert or Client-Cert-Chain in the Vary header field….”
>> 	• “Vary: Client-Cert” is a full field name and value, which the style guide doesn’t currently specify the formatting of.  I’ve openedhttps://github.com/httpwg/admin/issues/54 for guidance, but the occurrences I’ve found in RFC 911X where the full field is inlined in the text use quotes.
>> 	• “*” is quoted in multiple occurrences in RFCs 9110 and 9111, so I’m content to leave that.
>> 
>> In Appendix B.2, Forwarded should be unquoted, since it’s not defined in this document.
>> 
>> -----Original Message-----
>> From: Karen Moore <[e-mail]>
>> Sent: Tuesday, July 18, 2023 4:37 PM
>> To: Mike Bishop <[e-mail]>; Brian Campbell 
>> <[e-mail]>
>> Cc: RFC Editor <[e-mail]>; [e-mail]; 
>> [e-mail]; [e-mail]; Francesca Palombini 
>> <[e-mail]>; [e-mail]
>> Subject: Re: AUTH48: RFC-to-be 9440 
>> <draft-ietf-httpbis-client-cert-field-06> for your review
>> 
>> Hi Mike,
>> 
>> Thanks for clarifying.  We have updated our files by removing <tt> from "Client-Cert" and "Client-Cert-Chain” throughout and adding quote marks only to the first mentions in Section 1.
>> 
>> We notice that there are a few more terms that contain the <tt> tags. We have added quotes to the first mentions and removed the <tt> tags thereafter for the following:
>> 
>>  In Section 2.4: "Vary:  Client-Cert”, "Vary header”, and “*”
>>  In Appendix B.2: “Forwarded”
>> 
>> Please review and let us know if this is agreeable or if you would like to revert or make further changes.
>> 
>> FILES (please refresh)
>> The updated XML file is here:
>> https://www.rfc-editor.org/authors/rfc9440.xml
>> The updated output files are here:
>> https://www.rfc-editor.org/authors/rfc9440.txt
>> https://www.rfc-editor.org/authors/rfc9440.pdf
>> https://www.rfc-editor.org/authors/rfc9440.html
>> This diff file shows all changes made during AUTH48:
>> https://www.rfc-editor.org/authors/rfc9440-auth48diff.html
>> This diff shows only the changes made during the last edit round:
>> https://www.rfc-editor.org/authors/rfc9440-lastdiff.html
>> This diff file shows all changes made to date:
>> https://www.rfc-editor.org/authors/rfc9440-diff.html
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9440
>> 
>> We will await approval from Mike before moving forward with the publication process.
>> Thank you,
>> RFC Editor/kc
>> 
>> 
>>> On Jul 18, 2023, at 12:27 PM, Mike Bishop <[e-mail]> wrote:
>>> 
>>> I'm sorry for the miscommunication -- that was my original suggestion, but Mark pointed out that it didn’t accord with the HTTP style guide.  That reference says this:
>>> 
>>> When defining a field, the first instance should be quoted; e.g.,
>>> 
>>>> This document defines the “Foo” response header field.
>>> 
>>> If the field is specific to headers, trailers, requests, and/or responses, the definition should include the relevant terms, as above.
>>> 
>>> When referring to a field defined in a different document, the first instance should include a reference, and all instances should be unquoted. For example:
>>> 
>>>> Add the Foo-Example header field (see {{RFCxxxx}}) to the response.
>>> 
>>> Subsequent occurrences should be unquoted, but always be followed by “field”, “header field”, or “trailer field” as appropriate.
>>> 
>>> That suggests the first occurrence of each field name (in Section 1) should change from <tt> to quotes, and the remainder should omit the <tt>.  Fortunately, that should just be a search-and-replace for the two terms with the <tt>s now.
>>> 
>>> -----Original Message-----
>>> From: Karen Moore <[e-mail]>
>>> Sent: Tuesday, July 18, 2023 2:54 PM
>>> To: Brian Campbell <[e-mail]>; Mike Bishop 
>>> <[e-mail]>
>>> Cc: RFC Editor <[e-mail]>; [e-mail]; 
>>> [e-mail]; [e-mail]; Francesca Palombini 
>>> <[e-mail]>; [e-mail]
>>> Subject: Re: AUTH48: RFC-to-be 9440 
>>> <draft-ietf-httpbis-client-cert-field-06> for your review
>>> 
>>> Hi Mike, Brian, and Mark,
>>> 
>>> Thank you for your replies.  We have updated the document with Mike’s suggested text and added “<tt>” as directed.
>>> 
>>> Mike, please review and let us know if further changes are needed or if you approve the document in its current form.
>>> 
>>> FILES
>>> The updated XML file is here:
>>> https://www.rfc-editor.org/authors/rfc9440.xml
>>> 
>>> The updated output files are here:
>>> https://www.rfc-editor.org/authors/rfc9440.txt
>>> https://www.rfc-editor.org/authors/rfc9440.pdf
>>> https://www.rfc-editor.org/authors/rfc9440.html
>>> 
>>> This diff file shows all changes made during AUTH48:
>>> https://www.rfc-editor.org/authors/rfc9440-auth48diff.html
>>> 
>>> This diff shows only the changes made during the last edit round:
>>> https://www.rfc-editor.org/authors/rfc9440-lastdiff.html
>>> 
>>> This diff file shows all changes made to date:
>>> https://www.rfc-editor.org/authors/rfc9440-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.
>>> 
>>> For the AUTH48 status of this document, please see:
>>> https://www.rfc-editor.org/auth48/rfc9440
>>> 
>>> Thank you,
>>> RFC Editor/kc
>>> 
>>> 
>>>> On Jul 17, 2023, at 2:08 PM, Brian Campbell <[e-mail]> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Mon, Jul 17, 2023 at 2:28 PM Mike Bishop <[e-mail]> wrote:
>>>> A few changes I’d like to check, but the document overall looks good. Thanks for the work you’ve put into this!
>>>> 
>>>> 
>>>> 
>>>> Section 1
>>>> 
>>>> The specific details from the certificate needed certificate
>>>> 
>>>> 
>>>> This change suggests that it’s the certificate that is needed, rather than the details.  Perhaps “The specific details needed from the certificate also vary…”?
>>>> 
>>>> 
>>>> Thanks for catching that Mike. I missed the implications of the change. But you are right and I think your suggested text fixes it.
>>>> 
>>>> 
>>>> 
>>>> Section 1.2
>>>> 
>>>> In contemporary  Contemporary versions of TLS [TLS] [TLS1.2] this
>>>>   requires that require the
>>>>   client to send
>>>> 
>>>> 
>>>> This change could be read as saying that clients are always required to send these messages, which is not the case when client authentication isn’t being used.  Expanding rather than deleting “this” might be preferable; perhaps “In contemporary versions of TLS, mutual authentication requires…”?  Open to wording suggestions here, so long as it’s clear that we’re discussing the process referenced in this paragraph and not a general statement about modern TLS.
>>>> 
>>>> 
>>>> I had the same worry about the change. But didn't speak up because I thought maybe it was evident enough from the context of the rest of the paragraph. Now that Mike has said something though, I agree that additional change is needed along the lines of his suggestion. Or even reverting the sentence to what it was in -06 would be okay with me too.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Throughout, the field names Client-Cert and Client-Cert-Chain are marked up with <tt>…</tt>.  The exceptions are two occurrences in 2.2, six occurrences in 2.3, and two occurrences in 3.3. For consistency, should these be <tt> as well?
>>>> 
>>>> 
>>>> I overlooked those <tt> inconsistencies in my review but agree with the suggestion to make them all the same.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> - Mike Bishop
>>>> 
>>>> 
>>>> 
>>>> From: Mike Bishop
>>>> Sent: Thursday, July 13, 2023 8:39 PM
>>>> To: Karen Moore <[e-mail]>; Brian Campbell 
>>>> <[e-mail]>
>>>> Cc: RFC Editor <[e-mail]>; [e-mail]; 
>>>> [e-mail]; [e-mail]; Francesca Palombini 
>>>> <[e-mail]>; [e-mail]
>>>> Subject: Re: AUTH48: RFC-to-be 9440 
>>>> <draft-ietf-httpbis-client-cert-field-06> for your review
>>>> 
>>>> 
>>>> 
>>>> I am on vacation and haven't had a chance to read through the diff and final document. I will do so Monday, but I don't anticipate any issues.
>>>> 
>>>> 
>>>> 
>>>> Sent from Nine
>>>> 
>>>> From: Karen Moore <[e-mail]>
>>>> Sent: Thursday, July 13, 2023 5:14 PM
>>>> To: Brian Campbell; Mike Bishop
>>>> Cc: RFC Editor; [e-mail]; [e-mail]; 
>>>> [e-mail]; Francesca Palombini; [e-mail]
>>>> Subject: Re: AUTH48: RFC-to-be 9440 
>>>> <draft-ietf-httpbis-client-cert-field-06> for your review
>>>> 
>>>> 
>>>> 
>>>> Brian,
>>>> 
>>>> We have noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9440).
>>>> 
>>>> We now await further changes (if needed) and approval from Mike.
>>>> 
>>>> Best regards,
>>>> RFC Editor/kc
>>>> 
>>>> 
>>>>> On Jul 13, 2023, at 1:30 PM, Brian Campbell <[e-mail]> wrote:
>>>>> 
>>>>> Thanks Karen,
>>>>> 
>>>>> It looks good to me. I approve this RFC for publication.
>>>>> 
>>>>> On Tue, Jul 11, 2023 at 6:24 PM Karen Moore <[e-mail]> wrote:
>>>>> Hi Brian,
>>>>> 
>>>>> Thank you for your reply. Our files have been updated accordingly. Note that for future documents, responding within the email as you did is preferred, and we are happy to make the updates to the XML file or you may update the XML file and attach it to the email.
>>>>> 
>>>>> 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.
>>>>> 
>>>>> FILES
>>>>> The updated XML file is here:
>>>>> https://www.rfc-editor.org/authors/rfc9440.xml
>>>>> 
>>>>> The updated output files are here:
>>>>> https://www.rfc-editor.org/authors/rfc9440.txt
>>>>> https://www.rfc-editor.org/authors/rfc9440.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9440.html
>>>>> 
>>>>> This diff file shows all changes made during AUTH48:
>>>>> https://www.rfc-editor.org/authors/rfc9440-auth48diff.html
>>>>> 
>>>>> This diff file shows all changes made to date:
>>>>> https://www.rfc-editor.org/authors/rfc9440-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.
>>>>> 
>>>>> For the AUTH48 status of this document, please see:
>>>>> https://www.rfc-editor.org/auth48/rfc9440
>>>>> 
>>>>> Thank you,
>>>>> RFC Editor/kc
>>>>> 
>>>>> 
>>>>>> On Jul 10, 2023, at 3:09 PM, Brian Campbell <bcampbell=[e-mail]> wrote:
>>>>>> 
>>>>>> Thank you RFC Editor(s),
>>>>>> 
>>>>>> Despite having done this a few times previously, responding to AUTH48 is always a bit intimidating and I'm never sure how best to engage. In this instance, it seems maybe best to respond directly to the questions inline below in this email and let you make the corresponding updates. So that's what I"ve done here - I hope that works okay for you.
>>>>>> 
>>>>>> 
>>>>>> On Fri, Jul 7, 2023 at 5:19 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] Please review the text enclosed in <tt> 
>>>>>> carefully and let us know if any updates are needed. In the 
>>>>>> html and pdf outputs, the text enclosed is output in 
>>>>>> fixed-width font. In the txt output, there is no difference in font.
>>>>>> -->
>>>>>> 
>>>>>> I do not believe any updates are needed in this regard. But would happily defer to the RFC Editors' opinion on the matter (such as with quoting the (BEGIN|END) CERTIFICATE stuff suggested below).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2) <!--[rfced] Please review the following questions about the 
>>>>>> text in Section 2.1:
>>>>>> 
>>>>>> a) Would it be correct to say that certificates are stored "in 
>>>>>> an encoded textual format"?
>>>>>> 
>>>>>> I think that's still correct, yes.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> b) Does "if so" mean "if the certificates are encoded in a textual format"?
>>>>>> If so, may we rephrase as "If certificates are encoded as such"?
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>> 
>>>>>> c) For clarity, may we place quote marks around the 
>>>>>> information to be replaced?  (Note that per the format of our 
>>>>>> questions, we cannot include the sets of 3 dashes below, but 
>>>>>> they are included in the XML
>>>>>> file.)
>>>>>> 
>>>>>> Yes. 
>>>>>> 
>>>>>> 
>>>>>> Original:
>>>>>>   Note that certificates are often stored encoded in a textual format,
>>>>>>   such as the one described in Section 5.1 of [RFC7468], which is
>>>>>>   already nearly compatible with a Byte Sequence; if so, it will be
>>>>>>   sufficient to replace -(BEGIN|END) CERTIFICATE- with : and remove
>>>>>>   line breaks in order to generate an appropriate item.
>>>>>> 
>>>>>> Perhaps:
>>>>>>   Note that certificates are often stored in an encoded textual format,
>>>>>>   such as the one described in Section 5.1 of [RFC7468], which is
>>>>>>   already nearly compatible with a Byte Sequence. If certificates are
>>>>>>   encoded as such, it will be sufficient to replace "-(BEGIN|END) CERTIFICATE-"
>>>>>>   with ":" and remove line breaks in order to generate an appropriate item.
>>>>>> -->
>>>>>> 
>>>>>> Yes, that works. 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 3) <!--[rfced] In the second sentence, is "list" referring to 
>>>>>> "Client-Cert-Chain"? If so, should "list" be capitalized?
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Original:
>>>>>>   Client-Cert-Chain is a List (Section 3.1 of [STRUCTURED-FIELDS]).
>>>>>>   Each item in the list MUST be a Byte Sequence encoded as described
>>>>>>   in Section 2.1. 
>>>>>> 
>>>>>> Perhaps:
>>>>>>   Client-Cert-Chain is a List (Section 3.1 of [STRUCTURED-FIELDS]).
>>>>>>   Each item in the List MUST be a Byte Sequence encoded as described
>>>>>>   in Section 2.1. 
>>>>>> -->
>>>>>> 
>>>>>> Yes, I think "list" can be capitalized there.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 4) <!--[rfced] May we update this sentence as follows for clarity?
>>>>>> 
>>>>>> Original:
>>>>>>   Use of the technique is to be a configuration or deployment
>>>>>>   option, and the processing rules described herein are for servers
>>>>>>   operating with that option enabled.
>>>>>> 
>>>>>> Perhaps:
>>>>>>   This technique is to be used as a configuration or deployment
>>>>>>   option, and the processing rules described herein are for
>>>>>>   servers operating with that option enabled. 
>>>>>> -->
>>>>>> 
>>>>>> Yes, please do.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 5) <!-- [rfced] Should the references be alphabetized or left 
>>>>>> in their current order?
>>>>>> -->
>>>>>> 
>>>>>> The current order is produced by the tooling and I have no attachment to it whatsoever. Alphabetized would be totally fine, if that's prefered.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 6) <!-- [rfced] This reference has been superseded. Would you like to update to the newest version (February 2021) as follows?
>>>>>> 
>>>>>> Original:
>>>>>>   [ITU.X690.1994]
>>>>>>              International Telecommunications Union, "Information
>>>>>>              Technology - ASN.1 encoding rules: Specification of Basic
>>>>>>              Encoding Rules (BER), Canonical Encoding Rules (CER) and
>>>>>>              Distinguished Encoding Rules (DER)", ITU-T Recommendation
>>>>>>              X.690, 1994.
>>>>>> 
>>>>>> Perhaps:
>>>>>>   [ITU.X690]
>>>>>>              International Telecommunications Union, "Information
>>>>>>              Technology - ASN.1 encoding rules: Specification of Basic
>>>>>>              Encoding Rules (BER), Canonical Encoding Rules (CER) and
>>>>>>              Distinguished Encoding Rules (DER)", ITU-T Recommendation
>>>>>>              X.690, February 2021, <https://www.itu.int/rec/T-REC-X.690/en>.
>>>>>> -->
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 7) <!-- [rfced] Please review whether the "type" attribute 
>>>>>> should be set for sourcecode elements in the XML file. If the 
>>>>>> current list of preferred values for "type"
>>>>>> (https://www.rfc-editor.org/materials/sourcecode-types.txt) 
>>>>>> does not contain an applicable type, then feel free to suggest 
>>>>>> a new one.  Also, it is acceptable to leave the "type" 
>>>>>> attribute not set.
>>>>>> -->
>>>>>> 
>>>>>> I believe leaving the "type" attribute not set is okay/preferable for the sourcecode elements in this doc.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 8) <!--[rfced] May we rephrase this text for easier 
>>>>>> readability as follows?
>>>>>> 
>>>>>> Original:
>>>>>>   In the absence of a generic common solution existing
>>>>>>   currently, stripping/sanitizing the fields is the de
>>>>>>   facto means of protecting against field injection in
>>>>>>   practice.
>>>>>> 
>>>>>> Perhaps:
>>>>>>   Since a generic common solution does not currently exist,
>>>>>>   stripping and sanitizing the fields is the de facto
>>>>>>   means of protecting against field injection in practice.
>>>>>> -->
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 9) <!-- [rfced] Please review the "Inclusive Language" portion 
>>>>>> of the online Style Guide 
>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_langua
>>>>>> ge
>>>>>>> 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.
>>>>>> -->
>>>>>> 
>>>>>> I try to be reasonably aware of using inclusive language in 
>>>>>> drafts and believe this one is okay (esp.  given the script 
>>>>>> did not flag anything specific)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> RFC Editor/st/kc
>>>>>> 
>>>>>> 
>>>>>> On Jul 7, 2023, at 4:15 PM, [e-mail] wrote:
>>>>>> 
>>>>>> *****IMPORTANT*****
>>>>>> 
>>>>>> Updated 2023/07/07
>>>>>> 
>>>>>> 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-4
>>>>>> Q9
>>>>>> l2
>>>>>> USxIAe6P8O4Zc
>>>>>> 
>>>>>>    *  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/rfc9440.xml
>>>>>>  https://www.rfc-editor.org/authors/rfc9440.html
>>>>>>  https://www.rfc-editor.org/authors/rfc9440.pdf
>>>>>>  https://www.rfc-editor.org/authors/rfc9440.txt
>>>>>> 
>>>>>> Diff file of the text:
>>>>>>  https://www.rfc-editor.org/authors/rfc9440-diff.html
>>>>>>  https://www.rfc-editor.org/authors/rfc9440-rfcdiff.html 
>>>>>> (side by
>>>>>> side)
>>>>>> 
>>>>>> Diff of the XML: 
>>>>>>  https://www.rfc-editor.org/authors/rfc9440-xmldiff1.html
>>>>>> 
>>>>>> XMLv3 file that is a best effort to capture v3-related format 
>>>>>> updates
>>>>>> only: 
>>>>>>  https://www.rfc-editor.org/authors/rfc9440.form.xml
>>>>>> 
>>>>>> 
>>>>>> Tracking progress
>>>>>> -----------------
>>>>>> 
>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>  https://www.rfc-editor.org/auth48/rfc9440
>>>>>> 
>>>>>> Please let us know if you have any questions.  
>>>>>> 
>>>>>> Thank you for your cooperation,
>>>>>> 
>>>>>> RFC Editor
>>>>>> 
>>>>>> --------------------------------------
>>>>>> RFC9440 (draft-ietf-httpbis-client-cert-field-06)
>>>>>> 
>>>>>> Title            : Client-Cert HTTP Header Field
>>>>>> Author(s)        : B. Campbell, M. Bishop
>>>>>> WG Chair(s)      : Mark Nottingham, Tommy Pauly
>>>>>> Area Director(s) : Murray Kucherawy, Francesca Palombini
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>>>>> 
>>>>> 
>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>>>> 
>>>> 
>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>