Re: [auth48] AUTH48: RFC-to-be 9530 <draft-ietf-httpbis-digest-headers-13> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] We have updated the following sentence for readability. 
Please let us know if you prefer otherwise.

Original:
   It also coined the term "instance" and "instance                 
   manipulation" in order to explain concepts that are now more
   universally defined, and implemented, as HTTP semantics such as
   selected representation data (Section 8.1 of [HTTP]). 

Current: 
   It also coined the terms "instance" and "instance
   manipulation" in order to explain concepts, such as selected
   representation data (Section 8.1 of [HTTP]), that are now more
   universally defined and implemented as HTTP semantics.
-->


2) <!-- [rfced] May this be rephrased as follows for readability
and to reduce the usage of "of"?

Original: 
   The term "checksum" describes the output of the application of an
   algorithm to a sequence of bytes, whereas "digest" is only used in
   relation to the value contained in the fields.

Perhaps: 
   The term "checksum" describes the output of applying an algorithm
   to a sequence of bytes, whereas "digest" is only used in relation 
   to the value contained in the fields.
-->


3) <!-- [rfced] May we format these terms as follows to be similar to how 
the terms appear earlier within Section 1.4?

Original:
   Integrity fields: collective term for Content-Digest and Repr-Digest

   Integrity preference fields: collective term for Want-Repr-Digest and
   Want-Content-Digest

Perhaps:
   "Integrity fields" is the collective term for Content-Digest and 
   Repr-Digest.

   "Integrity preference fields" is the collective term for Want-Repr-Digest 
   and Want-Content-Digest. -->


4) <!--[rfced] May we move this note outside of the sourcecode
elements? Also, may we update to one note that applies to all the
wrapped lines (as follows), or do you prefer to keep the 18 instances 
of the note?

Current (18 instances):
   NOTE: '\' line wrapping per RFC 8792  

Suggested:
   NOTE: Throughout this document, '\' line wrapping is per [RFC8792].
-->


5) <!--[rfced] For clarity, may the final phrase be moved as follows?

Original:
   Want-Content-Digest indicates that the sender would like to receive a
   content digest on messages associated with the request URI and
   representation metadata, using the Content-Digest field.

   Want-Repr-Digest indicates that the sender would like to receive a
   representation digest on messages associated with the request URI and
   representation metadata, using the Repr-Digest field.

Perhaps:
   Want-Content-Digest indicates that the sender would like to receive 
   (via the Content-Digest field) a content digest on messages 
   associated with the request URI and representation metadata.

   Want-Repr-Digest indicates that the sender would like to receive 
   (via the Repr-Digest field) a representation digest on messages 
   associated with the request URI and representation metadata.
-->


6) <!-- [rfced] May this be rephrased as follows to improve readability?

Original: 
   For adversarial situations,
   selecting which of the "Active" algorithms are acceptable will depend
   on the level of protection the circumstances demand.

Perhaps: 
   For adversarial situations, selection of the acceptable "Active"
   algorithms will depend on the level of protection the circumstances
   demand. -->


7) <!-- [rfced] Please clarify; is the intended meaning 
"help some applications avoid undue operational overhead"?
If so, we suggest rephrasing as follows.

Original:
   Permitting the use of these algorithms can help some
   applications, for example, those that previously used [RFC3230], are
   migrating to this specification (Appendix E), and have existing
   stored collections of computed digest values avoid undue operational
   overhead caused by recomputation using other more-secure algorithms.

Option A:
   Permitting the use of these algorithms can help some
   applications (such as those that previously used [RFC3230], are
   migrating to this specification (Appendix E), and have existing
   stored collections of computed digest values) avoid undue
   operational overhead caused by recomputation using other more-secure
   algorithms.

Option B:
   Permitting the use of these algorithms can help some 
   applications -- specifically those applications that previously used
   [RFC3230], are migrating to this specification (Appendix E), and have
   existing stored collections of computed digest values -- avoid undue
   operational overhead caused by recomputation using other more-secure
   algorithms.
-->


8) <!-- [rfced] Please clarify "can remove or recalculate and substitute". 
If substitution can happen after either removal or recalculation, 
we suggest adding 'then' as follows.

Original:
   In the absence of additional
   security mechanisms, an on-path, malicious actor can remove or
   recalculate and substitute a digest value.

Perhaps:
   In the absence of additional
   security mechanisms, an on-path, malicious actor can remove or
   recalculate and then substitute a digest value. -->


9) <!--[rfced] May this be rephrased for conciseness, or is the word
"manipulation" needed?

Original:
   In the scenario where there is no content to send, the digest of an empty
   string can be included in the message and, if signed, can help the
   recipient detect if content was added either as a result of accident
   or purposeful manipulation. 

Perhaps:
   In the scenario where there is no content to send, the digest of an empty
   string can be included in the message and, if signed, can help the
   recipient detect if content was added accidentally or purposely.
-->


10) <!-- [rfced] References

a) For [UNIX], would you like the title and publication date to be 
updated to match how it appears in this file:
<https://unix.org/version2/u98paper.pdf>?  Or do you prefer to 
leave the reference as is, similar to how it appears in RFC 3230?

Original:
[UNIX]     The Open Group, "The Single UNIX Specification, Version 2
           - 6 Vol Set for UNIX 98", February 1997.

Perhaps:
[UNIX]     The Open Group, "The Single UNIX® Specification, Version 2
           and UNIX 98", January 1998.

b) The following reference has a Warning Notice stating that the
publication has been "withdrawn (archived)". Please let us know if 
any updates are needed.

Original:
[NIST800-32]
           National Institute of Standards and Technology, U.S.
           Department of Commerce, "Introduction to Public Key
           Technology and the Federal PKI Infrastructure", February
           2001, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
           nistspecialpublication800-32.pdf>. 

c) RFC 7807 has been obsoleted by RFC 9457. May we replace 
RFC 7807 with RFC 9457 in this document?
-->


11) <!-- [rfced] Please clarify "the first 10" here.

Original:
   The server satisfies the client request by responding with a partial
   representation (equivalent to the first 10 of the JSON object
   displayed in whole in Figure 2).

Perhaps:
   The server satisfies the client request by responding with a partial
   representation (equivalent to the first 10 bytes of the JSON object
   displayed in whole in Figure 2). -->


12) <!-- [rfced] May "bytes CRLF" be updated to "CRLF bytes"?

Original:
In the response content below, the string "\r\n" represent the bytes CRLF.

Perhaps:
In the response content below, the string "\r\n" represents the CRLF bytes.
-->


13) <!-- [rfced] For the list of digest values in Appendix D, would you prefer 
to format it as a definition list rather than a sourcecode element? 
If you do, placing the line break would not be necessary.
-->


14) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Note that our script did not flag 
any words in particular, but this should still be reviewed as a best
practice. -->


15) <!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness. -->


16) <!-- [rfced] Terminology

a) The following term appears inconsistently in this document. If there 
are no objections, we will update to the form on the right.

  Range Request(s) vs. range request(s)


b) Regarding "gzip" vs. "GZIP", both forms are used in this document; 
may all caps be used when it appears outside a header field? 
Specifically, may we update (4 instances) to all caps as follows?

   the same data with a GZIP coding ...
   Figure 2: Request Containing a GZIP-Encoded JSON Object
   Sending the GZIP-coded data without ...
   Figure 6: Partial Response from a GZIP-Encoded Representation


c) This term appears as Content-Encoding (with hyphen) for the header 
field. Should the title of Section 6.5 be updated?

Current: 6.5.  Variations within Content Encoding
Perhaps: 6.5.  Variations within Content-Encoding

("Merkle Integrity Content Encoding" will remain as is because 
it matches the title of the referenced Internet-Draft.)


d) Do the following terms mean the same thing? If so, would you like
to choose one form to use throughout the document for consistency?

  Repr-Digest field vs. Repr-Digest HTTP field
  hash algorithm vs. hashing algorithm 


e) The following terms use <tt> tags inconsistently throughout the
document. Please review the usage of <tt> and let us know if any 
updates are needed.

Byte Sequence
Content-Digest
Dictionary
Digest (field)
PATCH (when referring to PATCH requests)
Repr-Digest  
Want-Digest
Want-Repr-Digest 
-->


Thank you.

RFC Editor/mc/ar


On Dec 1, 2023, [e-mail] wrote:

*****IMPORTANT*****

Updated 2023/12/01

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/rfc9530.xml
  https://www.rfc-editor.org/authors/rfc9530.html
  https://www.rfc-editor.org/authors/rfc9530.pdf
  https://www.rfc-editor.org/authors/rfc9530.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9530-diff.html
  https://www.rfc-editor.org/authors/rfc9530-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9530-xmldiff1.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9530

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9530 (draft-ietf-httpbis-digest-headers-13)

Title            : Digest Fields
Author(s)        : R. Polli, L. Pardue
WG Chair(s)      : Mark Nottingham, Tommy Pauly
Area Director(s) : Murray Kucherawy, Francesca Palombini