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

[Marco Tiloca <[e-mail]>]

Hi Marius,

Thanks, it looks good to me!

Best,
/Marco
________________________________
From: Marius Kleidl <[e-mail]>
Sent: Tuesday, February 3, 2026 10:00 PM
To: Marco Tiloca <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [httpapi] draft-ietf-httpapi-digest-fields-problem-types-03 ietf last call Artart review

You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>