[core] Roman Danyliw's No Objection on draft-ietf-core-problem-details-05: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-core-problem-details-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-problem-details/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 1.
   It is designed to be reused by REST
   APIs, which can identify distinct shapes of these data items specific
   to their needs.

I don’t understand the notion of “identif[ing] distinct shapes.”  Section 2
uses the terminology again.

** Section 2.  This section is called “Basic Problem Details”.  Is that
something different than “Concise Problem Details”

** Section 2.
      It SHOULD
      NOT change from occurrence to occurrence of the same problem
      shape.

Is this guidance saying that things shouldn’t change on a per application
basis, or something else?  As an aside, some comment on a “problem shape.”

** Section 2.

   The "detail" member, if present, ought to focus on helping the client
   correct the problem, rather than giving debugging information.

What is the difference between providing enough information to “correct the
problem” vs. providing debugging information?

** Section 2.  Thank you for adding the base-lang to -05.  I was using -04 as
the basis of my review and was going to mention BCP 18.  Should text be added
to say that the base-lang and base-rtl are ignored if tag38 strings are used?

** Section 3.2
   Note that the URI given for the extension is for identification
   purposes only and, even if dereferenceable in principle, it MUST NOT
   be dereferenced in the normal course of handling problem details
   (i.e., outside diagnostic/debugging procedures involving humans).

Thank you for adding this text.  Consider clarifying the impact of this
dereferencing by explaining that this could become a tracking mechanism.

** Section 4.  Given the instance and base-uri fields, and the flexibility in
the extensions, it seems that there is a possibility this format to introduce
URLs that could be dereferenced.  The standard cautions of Section 7 of RFC3986
would seem to apply if the client would follow them.