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

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

Hello Thomas,

On Fri, May 20, 2022 at 04:33:54PM +0000, Thomas Fossati wrote:
> 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.

OK, that makes sense in the light of the next item.

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

Then I misunderstood -- fine with me as well. This will need to be
understood by authors of custom details; if they want to have extensible
types, I suppose they may still define their data items as

my-value = tstr / any .feature "extended-my-value"

and tell users to not fail processing the document if they fail to
understand the type of my-value.

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

I was thinking "file stored on disk in a log folder". If that file is
later accessed, the program accessing it will see only the file and not
where it was obtained from, and will thus be unable to resolve the
instance URI.

Otherwise, I'd read the intention of the document is that any stored
form will be suitably encapsulated (eg. because the log infrastructure
tells the accessing program that this was an error response to a request
made to this-and-that-base-URI -- but then that same mechanism could
also tell the original response-code, so there'd be no need to have that
code in the file.

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

I think that this can well be used over HTTP without a 7807bis mapping
-- there's a content format, and CBOR can go over HTTP just fine.

When accessed through a proxy, mapping the URI is much less of an issue
(many URI references work fine after being proxied). But maybe that's
the answer to my issue (at least the response-code vs.
relative-resolution part): Relative references can survive a proxy, but
the information on the original response-code will get lost.

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

Assume the instance-uri, when traversing a proxy that fixes up
problem-details documents (whose existence I assume based on the
presence of response-code), gets resolved to its full URI form.

If a later (standard or custom) entry also uses `~uri` as its value
type, that URI reference would require the same treatment, but can't get
it because the fix-up proxy may not know that this is a URI typed key.

BR
c

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