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

["Salz, Rich" <[e-mail]>]

Marco,

We expect that there will be a new version of the draft that goes to Proposed Standard.  The WG needs to confirm that by the end of this week.

I think that addresses the bulk of your concerns (in wordcount, if not important of issue:), and the authors will be in touch next week.

From: Marco Tiloca via Datatracker <[e-mail]>
Date: Friday, January 30, 2026 at 5:54 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: draft-ietf-httpapi-digest-fields-problem-types-03 ietf last call Artart review

!-------------------------------------------------------------------|
  This Message Is From an External Sender
  This message came from outside your organization.
|-------------------------------------------------------------------!

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