[art] Re: [httpapi] draft-ietf-httpapi-digest-fields-problem-types-03 ietf last call Artart review

[Marius Kleidl <[e-mail]>]

Hello Marco,

thank you for your review! I've opened https://github.com/ietf-wg-httpapi/digest-fields-problem-types/pull/6 to address the feedback regarding the draft's content.

Best regards,
Marius

On Fri, Jan 30, 2026, at 23:54, Marco Tiloca via Datatracker wrote:
> Document: draft-ietf-httpapi-digest-fields-problem-types
> Title: HTTP Problem Types for Digest Fields
> Reviewer: Marco Tiloca
> Review result: Ready with Issues
> 
> 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
> 
> 
> 
> -- 
> httpapi mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>