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

[David Dong via RT <[e-mail]>]

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>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >