Re: [Cbor] [core] WG Last Call on draft-ietf-core-problem-details

[Christian Amsüss <[e-mail]>]

Hello Carsten, Thomas and groups,

thanks for preparing this document. I've been worried about the suddenly
fast pace at which the document is moving, but apparently it *is*
possible to produce good documents even at speed.

In this review, I've been looking at the wglc-processing branch (at
2d26665a), which is roughly the WGLC'd -03.


Protocol notes:

* instance value: We have core-href in the pipeline, which would be
  quite suitable as it spares a constrained device that does no string
  processing whatsoever the path element concatenations the instance
  reference would bring.

  Is there a way forward to use CRIs as values? It should be possible
  under the "ignore unknown" rule to extend this, but is it planned to
  actually make that update later? Does it make sense to put a forward
  reference in there?

* "MUST ignore": From recent chats I understand that it does not only
  refers to keys (standard, outer and inner custom) the receiver does
  not recognize, but also to values outside the expected set.

  If that is the case, it would be good to have a few words of rationale
  and guidance, as "on error goto next" patterns are often discouraged
  -- I think they're good here, but other readers might need convincing.

* The presence of the response-code attribute implies to me that this is
  intended for persisting the problem details, and/or for exposing them
  on a different protocol. Both usually bring a change in the Base URI,
  so whoever sets the response-code WOULD PROBABLY also want to resolve
  the instance URI.

  And what of URIs for which the entity that adds the response-code
  doesn't even know they're URIs?

Procedural notes:

* I'm not sure RFC 7252 is a normative reference here; it's the typical
  transport, but understanding it is not necessary for implementing this
  spec. It might be justified by the response code reference, but the
  note on its numeric form IMO suffices to make this document usable
  without depending on 7252.

Editorial notes:

* Figure 1: The figure does not show the details (of a high-level class
  and finer-grained details) the paragraph referring to it describes;
  rather than "vocabulary), as shown in Figure 1." could say
  "vocabulary). The pattern of communication is shown in Figure 1".

  Nice vector graphics, by the way :-)

* The Tag 38 appendix talks about Unicode language tags being
  deprecated; a similar point might be made about Unicode bidirectional
  markers (U+200E and U+200F); https://www.w3.org/TR/string-meta/#rlm
  could work as a reference (albeit with some careful wording, given
  it's only a draft).


I think that all of these should be addressable easily (with the
possible exception of URI references in surprise locations, but that
problem is widespread enough that well-live-with-it is an acceptable
outcome).

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom