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

[Paul Wouters <[e-mail]>]

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]>;
> [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 <[e-mail]>;
> [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]>;
> [e-mail] <[e-mail]>; Annabelle Backman <
> [e-mail]>; [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'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, [e-mail]
> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Authors,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve
> (as necessary)
> >>>>>>>>>>>>> the following questions, which are also in the XML file.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1) <!-- [rfced] 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, [e-mail]
> 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>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
>
>
>