Re: [auth48] [IANA #1358618] [IANA] AUTH48: RFC-to-be 9421 <draft-ietf-httpbis-message-signatures-19> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, David.  Looks great; thank you!

RFC Editor/lb

> On Feb 12, 2024, at 10:52 AM, David Dong via RT <[e-mail]> wrote:
> 
> Hi Lynne,
> 
> These changes are complete; please see:
> 
> https://www.iana.org/assignments/http-message-signature/
> 
> Thank you.
> 
> Best regards,
> 
> David Dong
> IANA Services Sr. Specialist
> 
> On Fri Feb 09 21:15:50 2024, [e-mail] wrote:
>> Dear IANA,
>> 
>> We are preparing this document for publication.  Per author-approved
>> updates to this document, please make the following updates on
>> <https://www.iana.org/assignments/http-message-signature/>:
>> 
>> In the "HTTP Signature Algorithms" registry:
>> 
>> OLD:
>> ed25519    Edwards Curve DSA using curve edwards25519    Active
>> [RFC-ietf-httpbis-message-signatures-19, Section 3.3.6]
>> 
>> NEW:
>> ed25519    EdDSA using curve edwards25519    Active    [RFC-ietf-
>> httpbis-message-signatures-19, Section 3.3.6]
>> 
>> = = = = =
>> 
>> In the "HTTP Signature Component Parameters" registry:
>> 
>> OLD:
>> sf    Strict structured field serialization    [RFC-ietf-httpbis-
>> message-signatures-19, Section 2.1.1]
>> key    Single key value of dictionary structured fields    [RFC-ietf-
>> httpbis-message-signatures-19, Section 2.1.2]
>> 
>> NEW:
>> sf    Strict Structured Field serialization    [RFC-ietf-httpbis-
>> message-signatures-19, Section 2.1.1]
>> key    Single key value of Dictionary Structured Fields    [RFC-ietf-
>> httpbis-message-signatures-19, Section 2.1.2]
>> 
>> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>>> On Feb 9, 2024, at 1:00 PM, Lynne Bartholomew <[e-mail]>
>>> wrote:
>>> 
>>> Hi again, Justin and Manu.
>>> 
>>> Thank you very much for your quick replies!  We have updated this
>>> document accordingly and will email IANA with the requested updates
>>> shortly.
>>> 
>>> In the meantime, the latest files are here.  Please refresh your
>>> browser:
>>> 
>>> https://www.rfc-editor.org/authors/rfc9421.txt
>>> https://www.rfc-editor.org/authors/rfc9421.pdf
>>> https://www.rfc-editor.org/authors/rfc9421.html
>>> https://www.rfc-editor.org/authors/rfc9421.xml
>>> https://www.rfc-editor.org/authors/rfc9421-diff.html
>>> https://www.rfc-editor.org/authors/rfc9421-rfcdiff.html
>>> https://www.rfc-editor.org/authors/rfc9421-auth48diff.html
>>> https://www.rfc-editor.org/authors/rfc9421-lastdiff.html
>>> https://www.rfc-editor.org/authors/rfc9421-lastrfcdiff.html
>>> 
>>> https://www.rfc-editor.org/authors/rfc9421-xmldiff1.html
>>> https://www.rfc-editor.org/authors/rfc9421-xmldiff2.html
>>> 
>>> (FYI that per the fix for trouble ticket #1097
>>> (https://github.com/ietf-tools/xml2rfc/issues/1097), the listing for
>>> [BCP195] in the References section has been updated as well.)
>>> 
>>> Thanks again!
>>> 
>>> RFC Editor/lb
>>> 
>>> 
>>>> On Feb 9, 2024, at 12:39 PM, Manu Sporny <[e-mail]>
>>>> wrote:
>>>> 
>>>> On Fri, Feb 9, 2024 at 3:29 PM Justin Richer <[e-mail]>
>>>> wrote:
>>>>> Yes, that change is fine — I checked the defining RFC and it uses
>>>>> "EdDSA" regularly, so we can go with "EdDSA using curve
>>>>> edwards25519" as the value here.
>>>> 
>>>> Agreed.
>>>> 
>>>> -- manu
>>>> 
>>>> --
>>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>>> Founder/CEO - Digital Bazaar, Inc.
>>>> https://www.digitalbazaar.com/
>>> 
>>>> On Feb 9, 2024, at 12:28 PM, Justin Richer <[e-mail]> wrote:
>>>> 
>>>> Hi Lynne,
>>>> 
>>>> Yes, that change is fine — I checked the defining RFC and it uses
>>>> "EdDSA" regularly, so we can go with "EdDSA using curve
>>>> edwards25519" as the value here.
>>>> 
>>>> Thank you!
>>>> 
>>>> — Justin
>>>> 
>>>>> On Feb 9, 2024, at 3:19 PM, Lynne Bartholomew
>>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Hi, Justin and Manu.
>>>>> 
>>>>> We are preparing this document for publication along with RFC-to-be
>>>>> 9530.
>>>>> 
>>>>> Apologies for not spotting this earlier:
>>>>> 
>>>>> The last entry in the "HTTP Signature Algorithms" registry on
>>>>> <https://www.iana.org/assignments/http-message-signature/> and the
>>>>> last entry in Table 2 do not follow the format/pattern used for the
>>>>> other entries.  Would you like "Edwards Curve DSA using curve
>>>>> edwards25519" in Table 2 and on the IANA page to be "EdDSA using
>>>>> curve edwards25519"?  We ask because the other entries appear to
>>>>> follow the form of the corresponding section titles.
>>>>> 
>>>>> We have a couple other updates that we need to ask IANA to make
>>>>> before we publish this document, so if you agree to the update
>>>>> listed above, we will add it to the list of update requests for
>>>>> IANA.
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>> 
>>>>>> On Feb 6, 2024, at 4:11 PM, Lynne Bartholomew
>>>>>> <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi, Paul.
>>>>>> 
>>>>>> Thank you for approving on Annabelle's behalf.  We have noted
>>>>>> approvals for publication for both of you:
>>>>>> 
>>>>>> https://www.rfc-editor.org/auth48/rfc9421
>>>>>> 
>>>>>> This document will be published when RFC-to-be 9530 is published.
>>>>>> 
>>>>>> Thank you!
>>>>>> 
>>>>>> RFC Editor/lb
>>>>>> 
>>>>>>> On Feb 6, 2024, at 10:48 AM, Paul Wouters <[e-mail]>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Feb 6, 2024 at 1:16 PM Lynne Bartholomew
>>>>>>> <[e-mail]> wrote:
>>>>>>> Hi, Paul.
>>>>>>> 
>>>>>>> Per the emails below, would you please approve this document for
>>>>>>> publication on behalf of Annabelle?
>>>>>>> 
>>>>>>> I was checking to see when we last heard from her, which seems to
>>>>>>> be October 2023. Since that's been
>>>>>>> a while, I approve publication on her behalf.
>>>>>>> 
>>>>>>> Paul
>>>>>>> 
>>>>>>> Please see <https://www.rfc-editor.org/auth48/rfc9421> for the
>>>>>>> AUTH48 timeline for this document.
>>>>>>> 
>>>>>>> The latest files are posted here.  Please refresh your browser:
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/authors/rfc9421.txt
>>>>>>> https://www.rfc-editor.org/authors/rfc9421.pdf
>>>>>>> https://www.rfc-editor.org/authors/rfc9421.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9421.xml
>>>>>>> https://www.rfc-editor.org/authors/rfc9421-diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9421-rfcdiff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9421-auth48diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9421-lastdiff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9421-lastrfcdiff.html
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/authors/rfc9421-xmldiff1.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9421-xmldiff2.html
>>>>>>> 
>>>>>>> Thank you.
>>>>>>> 
>>>>>>> RFC Editor/lb
>>>>>>> 
>>>>>>>> On Feb 6, 2024, at 10:09 AM, Lynne Bartholomew
>>>>>>>> <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hi, Justin and Manu.
>>>>>>>> 
>>>>>>>> Thank you for the quick replies.  We will email the AD to
>>>>>>>> request AD approval on behalf of Annabelle.
>>>>>>>> 
>>>>>>>> RFC Editor/lb
>>>>>>>> 
>>>>>>>>> On Feb 6, 2024, at 10:01 AM, Manu Sporny
>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> On Tue, Feb 6, 2024 at 12:54 PM Justin Richer <[e-mail]>
>>>>>>>>> wrote:
>>>>>>>>>> I strongly prefer option 3.
>>>>>>>>> 
>>>>>>>>> Agreed.
>>>>>>>>> 
>>>>>>>>> -- manu
>>>>>>>> 
>>>>>>>>> On Feb 6, 2024, at 9:54 AM, Justin Richer <[e-mail]>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> I strongly prefer option 3.
>>>>>>>>> 
>>>>>>>>> Thank you,
>>>>>>>>> -Justin
>>>>>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>>>>>> Sent: Tuesday, February 6, 2024 11:26 AM
>>>>>>>>> To: Justin Richer <[e-mail]>
>>>>>>>>> Cc: Sandy Ginoza <[e-mail]>; [e-mail]
>>>>>>>>> <[e-mail]>; Manu Sporny <[e-mail]>;
>>>>>>>>> [e-mail] <[e-mail]>; httpbis-
>>>>>>>>> [e-mail] <[e-mail]>; [e-mail]
>>>>>>>>> <[e-mail]>; Tommy Pauly <[e-mail]>; Paul
>>>>>>>>> Wouters <[e-mail]>; [e-mail]
>>>>>>>>> <[e-mail]>
>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9421 <draft-ietf-httpbis-
>>>>>>>>> message-signatures-19> for your review   Hi, Justin.  We have
>>>>>>>>> three options, as listed on <https://www.rfc-
>>>>>>>>> editor.org/faq/#missingauthor>.
>>>>>>>>> 
>>>>>>>>> It sounds like Option 3 might be best in this case, but please
>>>>>>>>> let us know your preference regarding next steps.
>>>>>>>>> 
>>>>>>>>> Thank you.
>>>>>>>>> 
>>>>>>>>> RFC Editor/lb
>>>>>>>>> 
>>>>>>>>>> On Feb 5, 2024, at 3:11 PM, Justin Richer <[e-mail]>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Sandy et al,
>>>>>>>>>> 
>>>>>>>>>> In addition to these emails, I have reached out to Annabelle
>>>>>>>>>> on personal channels and have not heard back from her there
>>>>>>>>>> either in quite some time. I am not sure what her situation is
>>>>>>>>>> right now, but I am not sure we can anticipate her responding
>>>>>>>>>> soon. I hate to be in the position to ask this, but is there a
>>>>>>>>>> process for moving forward if we don't hear a response from
>>>>>>>>>> her?
>>>>>>>>>> 
>>>>>>>>>> - Justin
>>>>>>>>>> From: Sandy Ginoza <[e-mail]>
>>>>>>>>>> Sent: Wednesday, January 31, 2024 11:29 AM
>>>>>>>>>> To: [e-mail] <[e-mail]>; Justin Richer
>>>>>>>>>> <[e-mail]>
>>>>>>>>>> Cc: Lynne Bartholomew <[e-mail]>; Manu Sporny
>>>>>>>>>> <[e-mail]>; RFC Editor <rfc-editor@rfc-
>>>>>>>>>> editor.org>; [e-mail] <[e-mail]>;
>>>>>>>>>> [e-mail] <[e-mail]>; Tommy Pauly
>>>>>>>>>> <[e-mail]>; Paul Wouters <[e-mail]>;
>>>>>>>>>> [e-mail] <[e-mail]>
>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9421 <draft-ietf-httpbis-
>>>>>>>>>> message-signatures-19> for your review   Hi Annabelle,
>>>>>>>>>> 
>>>>>>>>>> We do not believe we have heard from you regarding this
>>>>>>>>>> document’s readiness for publication.  Please review the files
>>>>>>>>>> and let us know if any updates are needed or if you approve
>>>>>>>>>> the RFC for publication.
>>>>>>>>>> 
>>>>>>>>>> Thank you,
>>>>>>>>>> RFC Editor/sg
>>>>>>>>>> 
>>>>>>>>>>> On Jan 29, 2024, at 7:54 PM, Justin Richer <[e-mail]>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Thank you!
>>>>>>>>>>> 
>>>>>>>>>>> - Justin
>>>>>>>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>>>>>>>> Sent: Monday, January 29, 2024 7:15 PM
>>>>>>>>>>> To: Justin Richer <[e-mail]>
>>>>>>>>>>> Cc: Manu Sporny <[e-mail]>; rfc-editor@rfc-
>>>>>>>>>>> editor.org <[e-mail]>; Annabelle Backman
>>>>>>>>>>> <[e-mail]>; [e-mail] <httpbis-
>>>>>>>>>>> [e-mail]>; [e-mail] <httpbis-
>>>>>>>>>>> [e-mail]>; Tommy Pauly <[e-mail]>; Paul
>>>>>>>>>>> Wouters <[e-mail]>; [e-mail]
>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9421 <draft-ietf-httpbis-
>>>>>>>>>>> message-signatures-19> for your review
>>>>>>>>>>> 
>>>>>>>>>>> Hi, Justin.
>>>>>>>>>>> 
>>>>>>>>>>> We've made the additional updates in Sections 7.1.1 and 7.2.5
>>>>>>>>>>> per your notes below.  The latest files are here:
>>>>>>>>>>> 
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.txt
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.pdf
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.xml
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-diff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-rfcdiff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-auth48diff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-lastdiff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-lastrfcdiff.html
>>>>>>>>>>> 
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-xmldiff1.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-xmldiff2.html
>>>>>>>>>>> 
>>>>>>>>>>> We have noted your approval on the AUTH48 status page:
>>>>>>>>>>> 
>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9421
>>>>>>>>>>> 
>>>>>>>>>>> Again, many thanks for your help with this document!
>>>>>>>>>>> 
>>>>>>>>>>> RFC Editor/lb
>>>>>>>>>>> 
>>>>>>>>>>>> On Jan 29, 2024, at 12:35 PM, Justin Richer
>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I think it’s fine to lowercase those items. I may have been
>>>>>>>>>>>> going a little overboard on Assuming Terms Are Proper Nouns
>>>>>>>>>>>> there. :)
>>>>>>>>>>>> 
>>>>>>>>>>>> Two small changes we need to make:
>>>>>>>>>>>> 
>>>>>>>>>>>> - In section 7.1.1, "HTTP message without the Signature
>>>>>>>>>>>> fields" should be "HTTP message without the Signature or
>>>>>>>>>>>> Signature-Input fields".
>>>>>>>>>>>> - In section 7.2.5, "HTTP message signature field values are
>>>>>>>>>>>> identified" should be reverted to "HTTP message signature
>>>>>>>>>>>> values are identified", as I think I was over-zealous at
>>>>>>>>>>>> adding "field" here.
>>>>>>>>>>>> 
>>>>>>>>>>>> With those in place, I approve this version. Thank you so
>>>>>>>>>>>> much!
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> — Justin
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Jan 29, 2024, at 2:09 PM, Lynne Bartholomew
>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi, Justin.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thank you for the latest XML file!  We made further updates
>>>>>>>>>>>>> as noted below.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> * Removed the [rfced] questions again
>>>>>>>>>>>>> * Changed "boolean" to "Boolean" (per your note that we can
>>>>>>>>>>>>> go with "Boolean" for all cases)
>>>>>>>>>>>>> * Changed "HTTP Message" to "HTTP message where used
>>>>>>>>>>>>> generally (per your note that "HTTP message" is fine and
>>>>>>>>>>>>> seems to align with RFC 9110)
>>>>>>>>>>>>> * Changed "HTTP Message Signature" to "HTTP message
>>>>>>>>>>>>> signature" in running text (per your note below)
>>>>>>>>>>>>> * Updated our XML comment for draft-ietf-httpbis-digest-
>>>>>>>>>>>>> headers again, to point out that draft-ietf-httpbis-digest-
>>>>>>>>>>>>> headers is in AUTH48-DONE as of January 2024; if draft-
>>>>>>>>>>>>> ietf-httpbis-digest-headers is published first, we will
>>>>>>>>>>>>> update this document to list RFC 9530 instead
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please note that we found five instances each of "HTTP
>>>>>>>>>>>>> Message Component" and "HTTP message component" in running
>>>>>>>>>>>>> text.  Apologies for missing this earlier.  Because we
>>>>>>>>>>>>> couldn't find a precedent for this term in published RFCs
>>>>>>>>>>>>> to date (nor could we find a precedent for "HTTP Message
>>>>>>>>>>>>> Signature" or "HTTP message signature"), we lowercased to
>>>>>>>>>>>>> "HTTP message component", "HTTP message component name",
>>>>>>>>>>>>> and "HTTP message component values" in running text.
>>>>>>>>>>>>> Please review, and let us know any objections.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The latest files are posted here.  Please refresh your
>>>>>>>>>>>>> browser:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.txt
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.pdf
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.html
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.xml
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-diff.html
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-rfcdiff.html
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-auth48diff.html
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-lastdiff.html
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-lastrfcdiff.html
>>>>>>>>>>>>> 
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-xmldiff1.html
>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-xmldiff2.html
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks again!
>>>>>>>>>>>>> 
>>>>>>>>>>>>> RFC Editor/lb
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Jan 29, 2024, at 8:45 AM, Justin Richer
>>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I went through all instances of the word "string" in the
>>>>>>>>>>>>>> text and I believe there were only four places that needed
>>>>>>>>>>>>>> to change. The resulting file is attached here.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> — Justin
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Jan 26, 2024, at 5:57 PM, Justin Richer
>>>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Jan 26, 2024, at 5:45 PM, Lynne Bartholomew
>>>>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi, Justin.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Apologies for not being clear.  Please let us know your
>>>>>>>>>>>>>>>> preference regarding how we should update the four items
>>>>>>>>>>>>>>>> below.  (Question 12)b) says "The following terms appear
>>>>>>>>>>>>>>>> to be used inconsistently in this document.  Please let
>>>>>>>>>>>>>>>> us know which form is preferred.")
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Oh, my apologies, I misunderstood — answers inline below.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Regarding RFC-to-be 9530:  Per our standard process,
>>>>>>>>>>>>>>>> even though I updated the entry, if RFC-to-be 9530
>>>>>>>>>>>>>>>> hasn't been published before this document is ready to
>>>>>>>>>>>>>>>> go, I will revert to the previous [DIGEST]/draftstring
>>>>>>>>>>>>>>>> reference entry.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> OK, that’s fine. My question was that RFC-to-be 9530 has
>>>>>>>>>>>>>>> an informative reference to RFC-to-be 9421 (this
>>>>>>>>>>>>>>> document). Would it be possible to publish the two
>>>>>>>>>>>>>>> documents together and have them cross-reference each
>>>>>>>>>>>>>>> other’s RFC number, since we’re so close?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thank you!
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> RFC Editor/lb
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Jan 26, 2024, at 2:17 PM, Justin Richer
>>>>>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Thank you, yes please update each of those as you have
>>>>>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I believe RFC 9530 [DIGEST] is done as well, but I
>>>>>>>>>>>>>>>>> don’t see a good reason to wait until it’s published. I
>>>>>>>>>>>>>>>>> think it references this specification informationally
>>>>>>>>>>>>>>>>> as well — has that reference also been changed? If
>>>>>>>>>>>>>>>>> they’re both close to complete then they should
>>>>>>>>>>>>>>>>> probably have each others’ RFC numbers instead of ID
>>>>>>>>>>>>>>>>> names in them, I think. They weren’t put in as a batch
>>>>>>>>>>>>>>>>> though, and this isn’t critical as they’re
>>>>>>>>>>>>>>>>> informational references.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> — Justin
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Jan 26, 2024, at 5:07 PM, Lynne Bartholomew
>>>>>>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Hi, Justin and Manu.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Justin, thank you very much for the updated XML file,
>>>>>>>>>>>>>>>>>> diff file, and replies to our questions!
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Follow-up items for you:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Regarding your side question for [DIGEST]:  We have
>>>>>>>>>>>>>>>>>> updated this entry to reflect RFC 9530 for now.  Thank
>>>>>>>>>>>>>>>>>> you for pointing that out.  It appears that RFC 9530
>>>>>>>>>>>>>>>>>> might be published soon, but if not, would you like us
>>>>>>>>>>>>>>>>>> to hold publication of this document until RFC 9530 is
>>>>>>>>>>>>>>>>>> published?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Regarding our question 12)b) and your replies:  We see
>>>>>>>>>>>>>>>>>> that the following four items were not addressed in
>>>>>>>>>>>>>>>>>> the updated XML file.  Would you like us to make
>>>>>>>>>>>>>>>>>> updates to some or all of these?  If yes, please
>>>>>>>>>>>>>>>>>> specify which items:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> boolean / Boolean
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> We can go with "Boolean" for all cases.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> HTTP Message / HTTP message (used generally in text,
>>>>>>>>>>>>>>>>>>>> e.g.,
>>>>>>>>>>>>>>>>>>>> "of an HTTP message.  Note that a given HTTP Message
>>>>>>>>>>>>>>>>>>>> can contain",
>>>>>>>>>>>>>>>>>>>> "the HTTP message and", "the HTTP Message and",
>>>>>>>>>>>>>>>>>>>> "from the HTTP
>>>>>>>>>>>>>>>>>>>> Message", "from the HTTP message")
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> "HTTP message" is fine, and seems to align with RFC9110.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> HTTP Message Signature(s) / HTTP message
>>>>>>>>>>>>>>>>>>>> signature(s) /
>>>>>>>>>>>>>>>>>>>> HTTP Message signature (in running text)
>>>>>>>>>>>>>>>>>>>> (e.g., "Applications of HTTP Message Signatures",
>>>>>>>>>>>>>>>>>>>> "an application
>>>>>>>>>>>>>>>>>>>> of HTTP message signatures", "An HTTP Message
>>>>>>>>>>>>>>>>>>>> Signature"
>>>>>>>>>>>>>>>>>>>> (Section 3), "an HTTP message signature" (Section
>>>>>>>>>>>>>>>>>>>> 3.1),
>>>>>>>>>>>>>>>>>>>> "An HTTP Message signature MUST use")
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> With the above, let’s go with "HTTP message signature".
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> string value / String value
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> This one is more tricky — if it’s talking about the
>>>>>>>>>>>>>>> Structured Field type of String, it should be
>>>>>>>>>>>>>>> capitalized. If it’s talking about a "string" in general,
>>>>>>>>>>>>>>> it shouldn’t be.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> = = = = =
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> The latest files are posted here:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.txt
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.pdf
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.html
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.xml
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-diff.html
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-
>>>>>>>>>>>>>>>>>> rfcdiff.html
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-
>>>>>>>>>>>>>>>>>> auth48diff.html
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-
>>>>>>>>>>>>>>>>>> xmldiff1.html
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-
>>>>>>>>>>>>>>>>>> xmldiff2.html
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Manu, we have noted your approval on the AUTH48 status
>>>>>>>>>>>>>>>>>> page:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9421
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Thanks again!
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> RFC Editor/lb
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Jan 26, 2024, at 5:58 AM, Manu Sporny
>>>>>>>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Thu, Jan 25, 2024 at 11:48 PM Justin Richer
>>>>>>>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>> Attached please find the XML file with some small
>>>>>>>>>>>>>>>>>>>> edits applied with regard to the below, as well as a
>>>>>>>>>>>>>>>>>>>> diff file from the provided XML.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This email is just noting my approval of the edits
>>>>>>>>>>>>>>>>>>> (thank you,
>>>>>>>>>>>>>>>>>>> Justin!) as well as the publication of the RFC.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> -- manu
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>>>>>>>>>>>>>>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>>>>>>>>>>>>>>>> https://www.digitalbazaar.com/
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Jan 25, 2024, at 8:48 PM, Justin Richer
>>>>>>>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Hi RFC Editor!
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Attached please find the XML file with some small
>>>>>>>>>>>>>>>>>>> edits applied with regard to the below, as well as a
>>>>>>>>>>>>>>>>>>> diff file from the provided XML.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> There were a couple of small changes to the text that
>>>>>>>>>>>>>>>>>>> I caught on this read through that I fixed in the
>>>>>>>>>>>>>>>>>>> XML, not covered in the sections below:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - Section 1.3, bullet 2, "A combination" should be
>>>>>>>>>>>>>>>>>>> reverted to "Combination", as we are trying to say
>>>>>>>>>>>>>>>>>>> "the act and result of combining the fields with the
>>>>>>>>>>>>>>>>>>> same name" which is specifically described in HTTP
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - Section 2.1, "content identifier" should be
>>>>>>>>>>>>>>>>>>> "component identifier"
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - Section B.1.1. should be named "Example RSA Key",
>>>>>>>>>>>>>>>>>>> so I’ve updated the XML as appropriate.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - Example B.2 had an incorrect digest value, this has
>>>>>>>>>>>>>>>>>>> been corrected (see https://github.com/httpwg/http-
>>>>>>>>>>>>>>>>>>> extensions/pull/2669) — the calculated signature
>>>>>>>>>>>>>>>>>>> example that uses this value in B.2.4 had already
>>>>>>>>>>>>>>>>>>> been corrected and did not need to be changed.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I’ve also replied to the questions inline.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Jan 22, 2024, at 6:54 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] Note that we have removed the URI
>>>>>>>>>>>>>>>>>>>> <https://manu.sporny.org/>.  We checked its
>>>>>>>>>>>>>>>>>>>> availability many times (including today) and were
>>>>>>>>>>>>>>>>>>>> unable to connect.
>>>>>>>>>>>>>>>>>>>> <uri>https://manu.sporny.org/</uri> -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> That’s fine with me.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 2) <!-- [rfced] Sections 1 and subsequent:  Because
>>>>>>>>>>>>>>>>>>>> many changes were
>>>>>>>>>>>>>>>>>>>> made to this document during the EDIT and AUTH
>>>>>>>>>>>>>>>>>>>> states, please review
>>>>>>>>>>>>>>>>>>>> all updates in this document carefully, and let us
>>>>>>>>>>>>>>>>>>>> know if anything
>>>>>>>>>>>>>>>>>>>> is incorrect.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I’ve reviewed and, apart from the edits noted above,
>>>>>>>>>>>>>>>>>>> this section is good.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Also, a follow-on to December 2023 email discussions
>>>>>>>>>>>>>>>>>>>> regarding the
>>>>>>>>>>>>>>>>>>>> use of <tt>:  Please (1) review current instances of
>>>>>>>>>>>>>>>>>>>> <tt> and
>>>>>>>>>>>>>>>>>>>> (2) review changes from "header" to "header field"
>>>>>>>>>>>>>>>>>>>> as instructed
>>>>>>>>>>>>>>>>>>>> during the AUTH state (not applied to all
>>>>>>>>>>>>>>>>>>>> parameters).  Let us know
>>>>>>>>>>>>>>>>>>>> if further updates are needed. -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I’ve gone through the document and have checked
>>>>>>>>>>>>>>>>>>> instances of <tt> and "header/header field" and these
>>>>>>>>>>>>>>>>>>> seem to be OK with the suggested edits.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 3) <!-- [rfced] Please review the "type" attribute
>>>>>>>>>>>>>>>>>>>> of each sourcecode
>>>>>>>>>>>>>>>>>>>> element in the XML file to ensure correctness.  If
>>>>>>>>>>>>>>>>>>>> the current list
>>>>>>>>>>>>>>>>>>>> of preferred values for "type"
>>>>>>>>>>>>>>>>>>>> (https://www.rfc-editor.org/materials/sourcecode-
>>>>>>>>>>>>>>>>>>>> types.txt) does not
>>>>>>>>>>>>>>>>>>>> contain an applicable type, please let us know.
>>>>>>>>>>>>>>>>>>>> Also, it is
>>>>>>>>>>>>>>>>>>>>  acceptable to leave the "type" attribute not set.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> In addition, review each artwork element.
>>>>>>>>>>>>>>>>>>>> Specifically, should any
>>>>>>>>>>>>>>>>>>>> artwork element be tagged as sourcecode? -->
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I’ve gone through all of these, and they look
>>>>>>>>>>>>>>>>>>> correct. I made not changes in the attached file.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 4) <!-- [rfced] Sections 2.2.8 and subsequent:
>>>>>>>>>>>>>>>>>>>> Please review the links
>>>>>>>>>>>>>>>>>>>> that we provided when we made updates to the
>>>>>>>>>>>>>>>>>>>> citations to [HTMLURL]
>>>>>>>>>>>>>>>>>>>> (best viewed in the HTML and PDF output files), and
>>>>>>>>>>>>>>>>>>>> let us know if
>>>>>>>>>>>>>>>>>>>> there are any issues.  For example, it appears to us
>>>>>>>>>>>>>>>>>>>> that these links
>>>>>>>>>>>>>>>>>>>> would be stable, but please let us know if this is
>>>>>>>>>>>>>>>>>>>> incorrect:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> <https://url.spec.whatwg.org/#application/x-www-
>>>>>>>>>>>>>>>>>>>> form-urlencoded>
>>>>>>>>>>>>>>>>>>>> for Section 5
>>>>>>>>>>>>>>>>>>>> <https://url.spec.whatwg.org/#urlencoded-parsing>
>>>>>>>>>>>>>>>>>>>> for Section 5.1
>>>>>>>>>>>>>>>>>>>> <https://url.spec.whatwg.org/#urlencoded-
>>>>>>>>>>>>>>>>>>>> serializing>
>>>>>>>>>>>>>>>>>>>> for Section 5.2 -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> These all seem to be correct. I made no changes in
>>>>>>>>>>>>>>>>>>> the attached file.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 5) <!-- [rfced] For alignment with the IANA
>>>>>>>>>>>>>>>>>>>> registry, would it be appropriate to change
>>>>>>>>>>>>>>>>>>>> "Specification document(s)" to "Reference(s)" in the
>>>>>>>>>>>>>>>>>>>> descriptions and the column headers throughout
>>>>>>>>>>>>>>>>>>>> Section 6?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Example from Section 6.2.1:
>>>>>>>>>>>>>>>>>>>> Specification document(s):
>>>>>>>>>>>>>>>>>>>> Reference to the document(s) that specify the
>>>>>>>>>>>>>>>>>>>> algorithm,
>>>>>>>>>>>>>>>>>>>> preferably including a URI that can be used to
>>>>>>>>>>>>>>>>>>>> retrieve a copy of
>>>>>>>>>>>>>>>>>>>> the document(s).  An indication of the relevant
>>>>>>>>>>>>>>>>>>>> sections may also
>>>>>>>>>>>>>>>>>>>> be included but is not required.
>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I’m OK with this change. I have changed the attached
>>>>>>>>>>>>>>>>>>> file to use "Reference" (with no (s) attached) for
>>>>>>>>>>>>>>>>>>> both the description and column name to match the
>>>>>>>>>>>>>>>>>>> created IANA registry.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 6) <!-- [rfced] The description for ed25519 is
>>>>>>>>>>>>>>>>>>>> slightly different than the other entries.  Is this
>>>>>>>>>>>>>>>>>>>> intentional, or perhaps the description could be
>>>>>>>>>>>>>>>>>>>> updated as follows:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>> Edwards Curve DSA using curve edwards25519
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>>>>>>>> ECDSA using curve edwards25519
>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> The existing text is correct as per rfc8032, no
>>>>>>>>>>>>>>>>>>> changes should be made.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 7) <!-- [rfced] We were unable to verify this
>>>>>>>>>>>>>>>>>>>> statement.  Please confirm that the reference is
>>>>>>>>>>>>>>>>>>>> correct.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>> As discussed in [DIGEST], the value of the Content-
>>>>>>>>>>>>>>>>>>>> Digest field is
>>>>>>>>>>>>>>>>>>>> dependent on the content encoding of the message.
>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Yes, this is discussed at length in sections 2 and 3
>>>>>>>>>>>>>>>>>>> of DIGEST.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> An aside from the authors - we will need to update
>>>>>>>>>>>>>>>>>>> this reference to the digest RFC number, right?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 8) <!-- [rfced] Section 7.3.3:  As it appears that
>>>>>>>>>>>>>>>>>>>> "its" actually refers
>>>>>>>>>>>>>>>>>>>> to the symmetric cryptographic methods, we changed
>>>>>>>>>>>>>>>>>>>> "its" to "their".
>>>>>>>>>>>>>>>>>>>> If this is incorrect, please clarify what "its"
>>>>>>>>>>>>>>>>>>>> refers to.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Original (the previous sentence is included for
>>>>>>>>>>>>>>>>>>>> context):
>>>>>>>>>>>>>>>>>>>> The HTTP Message Signatures specification allows for
>>>>>>>>>>>>>>>>>>>> both asymmetric
>>>>>>>>>>>>>>>>>>>> and symmetric cryptography to be applied to HTTP
>>>>>>>>>>>>>>>>>>>> messages.  By its
>>>>>>>>>>>>>>>>>>>> nature, symmetric cryptographic methods require the
>>>>>>>>>>>>>>>>>>>> same key material
>>>>>>>>>>>>>>>>>>>> to be known by both the signer and verifier.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Currently:
>>>>>>>>>>>>>>>>>>>> By their
>>>>>>>>>>>>>>>>>>>> nature, symmetric cryptographic methods require the
>>>>>>>>>>>>>>>>>>>> same key material
>>>>>>>>>>>>>>>>>>>> to be known by both the signer and verifier. -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Yes, this change is OK.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 9) <!-- [rfced] For clarity, may we update "other
>>>>>>>>>>>>>>>>>>>> historical drafts" to "other Internet-Drafts"?  Is
>>>>>>>>>>>>>>>>>>>> mention of "historical" important?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>> It is recommended
>>>>>>>>>>>>>>>>>>>> that developers wishing to support both this
>>>>>>>>>>>>>>>>>>>> specification and other
>>>>>>>>>>>>>>>>>>>> historical drafts do so carefully and deliberately,
>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>> incompatibilities between this specification and
>>>>>>>>>>>>>>>>>>>> various versions of
>>>>>>>>>>>>>>>>>>>> other drafts could lead to unexpected problems.
>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I think "historical" is reasonable to keep as it is.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 10) <!-- [rfced] Because this document is a Proposed
>>>>>>>>>>>>>>>>>>>> Standard, may we update the following text?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>> It is recommended that implementers first detect and
>>>>>>>>>>>>>>>>>>>> validate the
>>>>>>>>>>>>>>>>>>>> Signature-Input field defined in this specification
>>>>>>>>>>>>>>>>>>>> to detect that
>>>>>>>>>>>>>>>>>>>> this standard is in use and not an alternative.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>>>>>>>> It is recommended that implementers first detect and
>>>>>>>>>>>>>>>>>>>> validate the
>>>>>>>>>>>>>>>>>>>> Signature-Input field defined in this specification
>>>>>>>>>>>>>>>>>>>> to detect that
>>>>>>>>>>>>>>>>>>>> the mechanism described in this document is in use
>>>>>>>>>>>>>>>>>>>> and not an
>>>>>>>>>>>>>>>>>>>> alternative.
>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Yes, this change is fine. I have updated the text as
>>>>>>>>>>>>>>>>>>> proposed. The sentence also ends with "this
>>>>>>>>>>>>>>>>>>> specification", is this OK to keep?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 11) <!-- [rfced] Please review the "Inclusive
>>>>>>>>>>>>>>>>>>>> Language" portion of the
>>>>>>>>>>>>>>>>>>>> online Style Guide at
>>>>>>>>>>>>>>>>>>>> <https://www.rfc-
>>>>>>>>>>>>>>>>>>>> editor.org/styleguide/part2/#inclusive_language>,
>>>>>>>>>>>>>>>>>>>> and let us know if any changes are needed.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> For example, please consider whether the following
>>>>>>>>>>>>>>>>>>>> should be updated:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> whitespace -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This is the specific term used in [HTTP] so I believe
>>>>>>>>>>>>>>>>>>> we shouldn’t vary from it.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 12) <!-- [rfced] Please let us know if any changes
>>>>>>>>>>>>>>>>>>>> are needed for the
>>>>>>>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> a) The following terms were used inconsistently in
>>>>>>>>>>>>>>>>>>>> this document.
>>>>>>>>>>>>>>>>>>>> We chose to use the latter forms.  Please let us
>>>>>>>>>>>>>>>>>>>> know any objections.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> "@authority" derived component (last paragraph of
>>>>>>>>>>>>>>>>>>>> Section 7.2.4) /
>>>>>>>>>>>>>>>>>>>> @authority derived component (per unquoted names of
>>>>>>>>>>>>>>>>>>>> derived
>>>>>>>>>>>>>>>>>>>> components in the rest of this document)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I have changed this to be wrapped in <tt> tags as in
>>>>>>>>>>>>>>>>>>> other places in the document, removing the quotes.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> dictionary / Dictionary (per [STRUCTURED-FIELDS]; we
>>>>>>>>>>>>>>>>>>>> see that
>>>>>>>>>>>>>>>>>>>> [STRUCTURED-FIELDS] uses the term "Dictionary".)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> dictionary structured field / Dictionary structured
>>>>>>>>>>>>>>>>>>>> field /
>>>>>>>>>>>>>>>>>>>> Dictionary Structured Field
>>>>>>>>>>>>>>>>>>>> (per [STRUCTURED-FIELDS]; we see that [STRUCTURED-
>>>>>>>>>>>>>>>>>>>> FIELDS] uses
>>>>>>>>>>>>>>>>>>>> the terms "Dictionary" and "Structured Field".)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Note:  We also changed instances of "structured
>>>>>>>>>>>>>>>>>>>> field" where used
>>>>>>>>>>>>>>>>>>>> more generally to "Structured Field", also per usage
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> [STRUCTURED-FIELDS].  Please let us know any
>>>>>>>>>>>>>>>>>>>> concerns.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> ed25519 algorithm / Ed25519 algorithm (per RFC 8032)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> encoded in big-endian unsigned integers /
>>>>>>>>>>>>>>>>>>>> encoded as big-endian unsigned integers
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Host field (1 instance) / Host header field
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine. I believe I found a few other
>>>>>>>>>>>>>>>>>>> places that were not using "field" and have updated
>>>>>>>>>>>>>>>>>>> them in the attached text.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> host name (2 instances in original) /
>>>>>>>>>>>>>>>>>>>> hostname (5 instances in original)
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> HTTP Signature Algorithm(s) (used generally in
>>>>>>>>>>>>>>>>>>>> Sections 6.2
>>>>>>>>>>>>>>>>>>>> and 6.2.1) / HTTP signature algorithm(s)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> key id (Section 4.3) / keyid
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I changed this to "key" to be consistent with other
>>>>>>>>>>>>>>>>>>> uses of identifying keys directly in examples.
>>>>>>>>>>>>>>>>>>> "keyid" on its own is used as "<tt>keyid</tt>
>>>>>>>>>>>>>>>>>>> parameter" or similar, and "key identifier" is used
>>>>>>>>>>>>>>>>>>> when speaking of the term generically.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> line-folding / line folding (per RFC 9112)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> RSA PSS / RSA-PSS (per post-6000 published RFCs,
>>>>>>>>>>>>>>>>>>>> including
>>>>>>>>>>>>>>>>>>>> RFC 8017)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> signature field / Signature field
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Unix timestamp / UNIX timestamp
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> b) The following terms appear to be used
>>>>>>>>>>>>>>>>>>>> inconsistently in this
>>>>>>>>>>>>>>>>>>>> document.  Please let us know which form is
>>>>>>>>>>>>>>>>>>>> preferred.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Accept header (noun) (4 instances) /
>>>>>>>>>>>>>>>>>>>> Accept-Header (adj.) ("Accept-Header signature") (1
>>>>>>>>>>>>>>>>>>>> instance)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This should be "Accept header field", I have changed
>>>>>>>>>>>>>>>>>>> this in the attached file.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> boolean / Boolean
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> "host" header field ('"host" header field is
>>>>>>>>>>>>>>>>>>>> specific to HTTP/1.1') /
>>>>>>>>>>>>>>>>>>>> Host header ('the Host header field in HTTP/1.1')
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This should be Host header field, I have changed this
>>>>>>>>>>>>>>>>>>> in the attached file.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> HTTP Message / HTTP message (used generally in text,
>>>>>>>>>>>>>>>>>>>> e.g.,
>>>>>>>>>>>>>>>>>>>> "of an HTTP message.  Note that a given HTTP Message
>>>>>>>>>>>>>>>>>>>> can contain",
>>>>>>>>>>>>>>>>>>>> "the HTTP message and", "the HTTP Message and",
>>>>>>>>>>>>>>>>>>>> "from the HTTP
>>>>>>>>>>>>>>>>>>>> Message", "from the HTTP message")
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> HTTP Message Signature(s) / HTTP message
>>>>>>>>>>>>>>>>>>>> signature(s) /
>>>>>>>>>>>>>>>>>>>> HTTP Message signature (in running text)
>>>>>>>>>>>>>>>>>>>> (e.g., "Applications of HTTP Message Signatures",
>>>>>>>>>>>>>>>>>>>> "an application
>>>>>>>>>>>>>>>>>>>> of HTTP message signatures", "An HTTP Message
>>>>>>>>>>>>>>>>>>>> Signature"
>>>>>>>>>>>>>>>>>>>> (Section 3), "an HTTP message signature" (Section
>>>>>>>>>>>>>>>>>>>> 3.1),
>>>>>>>>>>>>>>>>>>>> "An HTTP Message signature MUST use")
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Referer / Referrer (Appendix B.4)
>>>>>>>>>>>>>>>>>>>> We see both spellings used in post-6000 published
>>>>>>>>>>>>>>>>>>>> RFCs.  Google
>>>>>>>>>>>>>>>>>>>> searches for "what is a referer header?" and "what
>>>>>>>>>>>>>>>>>>>> is a referrer
>>>>>>>>>>>>>>>>>>>> header?" both seem to indicate that "Referer" is
>>>>>>>>>>>>>>>>>>>> technically
>>>>>>>>>>>>>>>>>>>> correct but that it is "a misspelling of Referrer".
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Because RFC 9110 uses "Referer", it might be best to
>>>>>>>>>>>>>>>>>>>> use that
>>>>>>>>>>>>>>>>>>>> form, but we defer to your choice.  Please advise.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This should be "Referer header field", I have updated
>>>>>>>>>>>>>>>>>>> the text in the attached file.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> signature value(s) (37 instances in text) /
>>>>>>>>>>>>>>>>>>>> Signature value(s) (6 instances in text)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> The distinction is correct, but was unclear in the
>>>>>>>>>>>>>>>>>>> text. When used uppercase as "Signature value" it is
>>>>>>>>>>>>>>>>>>> referring specifically to the Signature field value,
>>>>>>>>>>>>>>>>>>> so I have changed those instances to "Signature field
>>>>>>>>>>>>>>>>>>> value" to be precise. I’ve made the same change to
>>>>>>>>>>>>>>>>>>> Signature-Input field value here. The lowercase
>>>>>>>>>>>>>>>>>>> instances all refer to the value of the HTTP message
>>>>>>>>>>>>>>>>>>> signature itself, not specifically the field.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> status code derived component / @status code /
>>>>>>>>>>>>>>>>>>>> @status derived component
>>>>>>>>>>>>>>>>>>>> (We suggest the latter, as @status is defined as
>>>>>>>>>>>>>>>>>>>> "The status code
>>>>>>>>>>>>>>>>>>>> for a response" in Section 2.2.)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This should be left as is.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> string value / String value
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This change is fine.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> The hash function (Hash) SHA-<###> / The hash SHA-
>>>>>>>>>>>>>>>>>>>> <###> /
>>>>>>>>>>>>>>>>>>>> The hash function SHA-<###>
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> This should be left as -is since <tt>Hash</tt> is
>>>>>>>>>>>>>>>>>>> defined as an algorithm variable in the associated
>>>>>>>>>>>>>>>>>>> RFC8017.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> c) Spacing after colons in message examples:  Should
>>>>>>>>>>>>>>>>>>>> there be only
>>>>>>>>>>>>>>>>>>>> one space after the colons for the following?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> X-OWS-Header:   Leading and trailing whitespace.
>>>>>>>>>>>>>>>>>>>> Cache-Control:    must-revalidate
>>>>>>>>>>>>>>>>>>>> Example-Dict:  a=1,    b=2;x=1;y=2,   c=(a   b   c)
>>>>>>>>>>>>>>>>>>>> Example-Dict:  a=1,    b=2;x=1;y=2,   c=(a   b   c)
>>>>>>>>>>>>>>>>>>>> Example-Dict:  a=1, b=2;x=1;y=2, c=(a   b    c), d
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> For example, in post-6000 published RFCs, we see
>>>>>>>>>>>>>>>>>>>> entries for
>>>>>>>>>>>>>>>>>>>> "Cache-Control:" (e.g., RFCs 9126, 9205, and 9449)
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> "Example-Dict:" (RFC 8941) with only one space
>>>>>>>>>>>>>>>>>>>> between the colon
>>>>>>>>>>>>>>>>>>>> and the parameter(s) in question.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> The extra spaces here are specifically for an
>>>>>>>>>>>>>>>>>>> aberrant example of what to do with non-conforming
>>>>>>>>>>>>>>>>>>> text on the wire, and they should be left in.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> d) Should "Digest" in this sentence be "Content-
>>>>>>>>>>>>>>>>>>>> Digest"?  We ask
>>>>>>>>>>>>>>>>>>>> because of "Content-Digest field defined in
>>>>>>>>>>>>>>>>>>>> [DIGEST]" in Section 1.4.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>> *  Requiring a specific set of header fields to be
>>>>>>>>>>>>>>>>>>>> signed (e.g.,
>>>>>>>>>>>>>>>>>>>> Authorization, Digest). -->
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Yes, this can change to "Content-Digest", I have
>>>>>>>>>>>>>>>>>>> updated the attached file.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> RFC Editor
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Jan 22, 2024, at 3:47 PM, rfc-editor@rfc-
>>>>>>>>>>>>>>>>>>>> editor.org wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Updated 2024/01/22
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 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/rfc9421.xml
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.html
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.pdf
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.txt
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-diff.html
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-
>>>>>>>>>>>>>>>>>>>> rfcdiff.html (side by side)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Diff of the XML:
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421-
>>>>>>>>>>>>>>>>>>>> xmldiff1.html
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> The following files are provided to facilitate
>>>>>>>>>>>>>>>>>>>> creation of your own
>>>>>>>>>>>>>>>>>>>> diff files of the XML.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Initial XMLv3 created using XMLv2 as input:
>>>>>>>>>>>>>>>>>>>> https://www.rfc-
>>>>>>>>>>>>>>>>>>>> editor.org/authors/rfc9421.original.v2v3.xml
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> XMLv3 file that is a best effort to capture v3-
>>>>>>>>>>>>>>>>>>>> related format updates
>>>>>>>>>>>>>>>>>>>> only:
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9421.form.xml
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Tracking progress
>>>>>>>>>>>>>>>>>>>> -----------------
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> The details of the AUTH48 status of your document
>>>>>>>>>>>>>>>>>>>> are here:
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9421
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> RFC Editor
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>>>>>>> RFC9421 (draft-ietf-httpbis-message-signatures-19)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Title            : HTTP Message Signatures
>>>>>>>>>>>>>>>>>>>> Author(s)        : A. Backman, Ed., J. Richer, Ed.,
>>>>>>>>>>>>>>>>>>>> M. Sporny
>>>>>>>>>>>>>>>>>>>> WG Chair(s)      : Mark Nottingham, Tommy Pauly
>>>>>>>>>>>>>>>>>>>> Area Director(s) : Murray Kucherawy, Francesca
>>>>>>>>>>>>>>>>>>>> Palombini
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> <rfc9421-jricher.xml><rfc9421-jricher.diff>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> <rfc9421-jricher2.xml>
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>