Original text:
13.3. <del> &#65532; The "contentMD5" digest-algorithm token defined in Section 5 of RFC3230 is removed from the HTTP Digest Algorithm Values Registry. </del>  All digest-algorithms defined in RFC3230 are now "deprecated". 13.4. <del> The digest-algorithm values for "MD5", "SHA", "SHA-256", "SHA-512" </del>  have been updated to lowercase. The status of "MD5" and "SHA" has been updated to "deprecated", and <del> their description states that they MUST NOT be used. </del>  The "id-sha-256" and "id-sha-512" algorithms have been added to the registry.

Reviewer comments:
add registration policy cc: NAME and NAME to URL Using RFC policy avoids the issues we had to face to refresh the current table. See
NAME now it's Specification Required :)
This specification obsoletes 3230 and updates the IANA registry to point to it, but doesn't specify what the registration policy actually is.
Related to NAME says
See
NAME do we need ? [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. Also, these might be better placed in IANA Considerations.[x] 5. There should not be RFC2219-MUSTs in IANA registry text. This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."[ ] 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there.
I'm sure I made this comment somewhere but I've lost it. I don't think we should mandate RFC required, that a very high bar for algorithms (and their users) that most likely developed the algoithm elsewhere already. Instead seem like a better option here
NAME imho registering new algos should be done via an RFC, this doesn't imply that those algorithms should be defined in an RFC. While it is fair to delegate the registration to an external specification, I think the approach of an RFC (eg URL ) is a lot more clean and improves the overall interoperability. It is important to note that any type of RFC is sufficient (currently Standards Track, BCP, Informational, Experimental, or Historic). In any case, I don't think this should be a game-stopper, so if there's general consensus on "Specification Required", that's ok.
I don't think running an RFC process can provide any meaningful value to the registration requirements. I mean, that's going to add like a year of overhead to something as simple as "use algorithm $foo with token , the output is encoded using base64".
The key to Specification Required is the Designated Experts. If they do they job you basically get what you need. If there's any question from the DEs they can always kick it back out for further review.
NAME Seems that NAME is on the same page URL ;) So let it be Specification Required! Move on :)

Revised text:
13.3.  <ins> The "contentMD5" digest-algorithm token defined in Section 5 of RFC3230 has been added to the HTTP Digest Algorithm Values Registry with the "obsoleted" status. </ins> All digest-algorithms defined in RFC3230 are now "deprecated". 13.4.  <ins> The digest-algorithm tokens for "MD5", "SHA", "SHA-256", "SHA-512" </ins> have been updated to lowercase. The status of "MD5" and "SHA" has been updated to "deprecated", and  <ins> their description has been modified accordingly. </ins> The "id-sha-256" and "id-sha-512" algorithms have been added to the registry.