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

[Thomas Fossati <[e-mail]>]

Hi Christian, thanks very much for the review!

On 20/05/2022, 15:58, "Christian Amsüss" <[e-mail]> wrote:
> 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?

The timing is unfortunate indeed.  Ideally CRI and CPD should have gone
forward together, but this is apparently not possible due to the
different time pressures.

I don't see a way forward that is not minting a new standard entry for
the CRI type.

> * "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.

I don't think this is the case.  The "MUST ignore" refers to unknown
keys, or keys inside keys (in case of custom problem details), not to
values inside known keys.  I.e., once the key is associated with one or
more types it's sealed forever.

>   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.

By "persisting the problem details" are you thinking about ingesting it
into a log/analytics pipeline?  If so, I am not sure why, in that case, it
would matter switching the base URI.

As far as the second use case you mention (i.e., exposing on a different
protocol), we say that the CoAP->HTTP transformation is out of scope -
at least until 7807bis is finalised.  I think in that case one may want
to apply some form of RFC8075 URI mapping to the instance element,
but that’s future work.

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

I don't understand this.  Could you please unpack it a bit?

> 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.

I don't have a strong opinion.  One certainly doesn't need to know CoAP
inside out to implement that, but an understanding of how CoAP
serialises the entries in the Response Codes registry definitely helps
:-)

> 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".

ACK, thanks!

>   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).

ACK

> 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).

Not sure what you mean by "surprise locations" but I like very much the
sound of it :-)

cheers!

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.