Code change:
Reorder Digest section. Cumulative PR of: NAME this patch ends the reordering and achieves: Digest header defined at §3 (pag. 7) Non-normative section moved in Annex Replaces
NAME WDYT about this roadmap? I'd address each one in a separate PR. If you agree, I can cherry-pick the first ones from your PR so you won't have to do it twice :) Digest Headers to be reordered: [x] move the "deprecated algorithms" security consideration directly in {{digest-agorithms}} [x] merge the {{digest-algorithm-encoding-examples}} in its parent section {{representation-digest}} [x] move Digest Header and Want-Digest header outside Header Field Specifications [x] move {{representation-digest}} under {{digest-header}} [x] move {{digest-algorithms}} down [x] move {{resource-representation}} examples to Annex B [x] ensure people start reading from {{representation-digest}} [x] refactor Digest to be more direct Optional: [ ] integrate examples from into {{resource representation}}
That sounds like a good plan, thanks. Please action it and I'll review promptly. This is a set of editorial changes that I think would add value to the specification readability. My jumbo PR () had some problems, so lets focus on landing the easy-to-agree items and not try to rush everything through before the submission deadline if we are uncomfortable. We can continue working on the thornier editorials even after the submission deadline.
Here's a first bunch of PRs. PTAL :) thanks for all the support!
NAME I'm trying to refactor and I have this proposal: URL we need rewording but just look at the sections ordering and let me know. The next PR to merge is
This section outline looks good. I approved, so let's merge it. What's next?
Now we have and which should end the refactoring. I think that's a reasonable cutout for IETF107 but we are clearly not over :)
All the PRs look good, even the optional one. Thanks for your work on this. Let's get them merged, then take a once-over review to catch any basic errors that might have crept in. Then one of us can cut the release.

Related discussion:
text: 3. <del> The Digest header field provides a digest of the representation data. </del> <ins> The Digest header field contains a list of one or more representation digest values as defined in representation-digest.  It can be used in both request and response. </ins> The resource is specified by the effective request URI and any "validator" contained in the message. <del> For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. Digest can be used in requests too. The "Digest" value depends on the representation metadata. </del> <ins> See post-not-request-uri for an example of how digest relates to header fields such as Content-Location (see RFC7231 Section 3.1.4.2) while a comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on digest is provided in examples-solicited and examples-unsolicited. </ins> A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in