I reviewed this document as part of the Applications and Real-Time (ART) Area Review Team's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the ART Area Directors. Document authors, document editors, and WG Chairs should treat these comments just like any other IETF Last Call comments.


[General]

* The current intended status of the document is Informational.

  However, Section 2 includes the boilerplate about BCP 14, and "MUST NOT" is used in Section 3.2. The intention in that sentence of Section 3.2 is understandably normative and the use of "MUST NOT" is consistent and appropriate.

  Besides, I read the document as defining _the_ way that a server can use to indicate those three problems in an application/problem+json error response.

  Wouldn't Standards Track be more appropriate as intended document status? (I can see that this change is already being considered on the HTTPAPI mailing list)

  If Informational remains the intended status, BCP 14 key words have to be avoided and the boilerplate in Section 2 needs to be removed.


[Abstract]

* s/problem types/HTTP problem types

* It would be good if the abstract is extended with one additional sentence, using the same wording from Section 1:

  > Using an HTTP problem type, the server can provide machine-readable error details to aid debugging or error reporting.


[Section 1]

* s/a set of problem types/a set of HTTP problem types


[Section 3.3]

* In Figure 8, line wrapping is needed also for the line about the "provided-digest" member.


[Section 4]

* It would be good to start by saying that that security considerations from Section 5 of RFC 9457 also apply.


[Nits]

* Section 1
--- s/require or recommend/require, or recommend
--- s/This draft/This document

* Section 3.1
--- s/supported, algorithms/supported algorithms

* Section 3.2
--- s/value, that/value that


Best,
/Marco