Original text:
SEMANTICS) of a resource identified according to Section 6.4.2 of SEMANTICS together with an indication of the algorithm used:  The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format.

Reviewer comments:
Clarifies . 1- + HEAD is used to get a resource checksum 2- no Digest in request for clarity 3- only use sha-256 to focus on the actual example.
Digest can be sent in requests and response Nope, in the example Digest is both in the request and in the response. See the hidden 607 line URL When used in conjuction with signatures, the client that want to certify that no-payload was attached will: compute the Digest of an empty string sign that Digest header with some signature mechanism attach the signature and digest to the request send the request with no payload data The server will then: verify the signature according to the chosen mechanism if no payload is provided, the Digest is the one of an empty string eventually store the signature to prove that the request had no payload Clearly the signature mechanism should provide enough information to define the semantic of the request (eg. the method and all relevant headers). HTH, R.
Well. So the Digest is for the empty request payload. Maybe it would be good to state this in the spec? (That said, this is IMHO a very misleading example, as the HTTP spec is very clear that GET/HEAD request bodies ("A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request."). It would probably better to have this example on a request that actually can take meaningful payload...
+1
NAME PTAL :)
I'll repeat what I said earlier: "That said, this is IMHO a very misleading example, as the HTTP spec is very clear that GET/HEAD request bodies ("A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request."). It would probably better to have this example on a request that actually can take meaningful payload..."
In order to make progress here, I suggest we simplify the example to remove the Request digest. That keeps the example focused on it's name "Server Returns No Representation Data".
NAME removed Digest from the HEAD request.
NAME PTAL ;)
NAME PTAL :)
YAY :rocket:
In 10.2 Server Returns No Representation Data: what does the Digest request header field on the HEAD request refer to, and what is the recipient supposed to do with it? there's only one digest in the response, but the prose talks about two
Requests without payload data can still send a field applying the digest-algorithm to an empty representation. The recipient can validate that the digest-value matches the one of an empty representation or not. True. this is confusing, should reference the previous example.:

Revised text:
SEMANTICS) of a resource identified according to Section 6.4.2 of SEMANTICS together with an indication of the algorithm used: <ins> When a message has no representation data it is still possible to assert that no representation data was sent computing the representation digest on an empty string (see usage-in-signatures). </ins> The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format.