Subject: Re: [core] Review of draft-fossati-core-coap-problem-02

From: Thomas Fossati <[email-masked]>
Date: Wed, 1 Apr 2020 10:36:10 +0000

On 31/03/2020, 16:04, "Jim Schaad" <[email-masked]> wrote:
> > I am torn between that and Section 4.3 of RFC 7322, last para:
> > "[...] the Abstract must not contain citations"
>
> [JLS]  The rule is that the text of the abstract is to be able to
> standalone.  This means that "[RFC7322]" is not permitted, but "RFC
> 7322" is permitted.   Referring to a document by a "well defined"
> lookup string is ok.  This means that referring to an eprint would be
> discouraged.  Note that most of us just use an <xref> in the abstract
> and make the RFC Editor staff clean this up.  But you might get
> complaints from that usage during final review.

Thanks for the explanation.  Will do.

> > Yep, application/coap-problem+cbor and diagnostic payloads are
> > mutually exclusive.  This was a precise choice because they seemed
> > to have different audiences (API user vs API developer).  That said,
> > the intersection between API users and developers is not empty, so
> > this might actually be in scope, apart from being obviously useful.
>
> [JLS] Given that I would want to test the problem info being returned,
> getting unexpected errors with information is useful for me.  This is
> the basic method that I have been using for my ACE server where a
> diagnostic string with the problem details is returned, but a stack
> trace is included in unexpected conditions (i.e. the code threw an
> exception).

I am certainly not opposed to that.  Happy to call it "diagnostic"?

> > Good point, we haven't thought about this.  Not sure how one can
> > successfully handle localisation in CoAP though.  It seems like the
> > only sensible recommendation we could make here is "try to choose
> > based on present and future audience.".   That, or force English
> > from the onset?
>
> [JLS] In some ways the method that is used by Windows to log events
> works out pretty well, but might be too weighty for this.  In that
> case a list of information with the title and a set of attributes are
> returned from the server (event) and these are then placed into a
> localized string.  It might be possible to provide a default string, a
> set of attributes and a method of getting a localized string if
> needed.

Sounds like we could do something slightly less sophisticated but maybe
sufficient in most situations by letting the application map "ns" and
"type" into a localised "title".

> > > If negative values are used for private details for a public
> > > namespace in section 5.2.1 - How I am to understand which the
> > > different private registrations are being referred to?  Or are
> > > these all expected to be registered?
>
> > Yes, the idea is that when you go public, you need to register all
> > the "extra" details your API is using picking from the unused parts
> > of the 0..4294967295 space.
>
> [JLS] But in that case you would not have private details for a public
> namespace?  If the CoRE group creates a basic public namespace and
> setups up a type FOO.  Is it legal for me, as an individual or
> company, to augment that and return negative attributes for that type?
> Think about the example in A.2 being in a public rather than in a
> private namespace.  Is the -1 attribute legal?

I think now I get what you are saying.  We need to be able to clearly
separate two cases:
(1) stack X wants to enrich an *existing* problem type with some extra
    keys;
(2) private API Y is making use of a number of "negative" keys and now
    needs to go public.

I guess we could have that kind of clean cut if we grouped (1) into a
nested map and handle (2) using the kind of promotion via registration
I was hinting before.

WDYT?

cheers!
--

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.

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 7 Apr 2020 14:32:30 +0200

Hello Thomas and Jim,

> I am certainly not opposed to that.  Happy to call it "diagnostic"?

Are these cases not independent cases anyway?

If there is a known condition, its problem-detail is returned. On
exceptions, there is no problem-detail but a stack-trace (without a
content format).

Of course, a framework might create an entry for (ns=my-framework,
type=0, title="Exception in resource handler", response-code=5.00,
coapp-roblem-details-extension = [* stackframe])

But as I understand that use case, you don't need both simultaneously.

KR
c

-- 
You don't use science to show that you're right, you use science to
become right.
  -- Randall Munroe

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 7 Apr 2020 20:26:40 +0000

Hi Christian,

On 07/04/2020, 13:32, "Christian Amsüss" <[email-masked]> wrote:
> > > [JLS] Given that I would want to test the problem info being
> > > returned, getting unexpected errors with information is useful for
> > > me.  This is the basic method that I have been using for my ACE
> > > server where a diagnostic string with the problem details is
> > > returned, but a stack trace is included in unexpected conditions
> > > (i.e. the code threw an exception).
> >

It doesn't necessarily have to be mutually exclusive.

> coapp-roblem-details-extension = [* stackframe])

Sure, an extension could work as well.  In fact, one thing I'm trying to
assess atm is whether we feel there are good reasons to subsume the
diagnostic payload (or at least one specific usage pattern -- the "API
developer"'s) under the problem structure or, as you suggest, this
should be left as a decision to each and every API.

ISTM that if we take Jim's approach, there are (at least) two options:

1. if trace_enabled: extend the "detail" string with diagnostic info;
2. if trace_enabled: add diagnostic info to a separate channel.

From a log consumer point of view, a more structured approach (i.e., 2.)
seems easier to ingest & process.  From a producer perspective the cost
is the same.  From the pov of the transport, 2. inflicts a slight
increase in bandwidth to support the extra structuring but I'd expect it
to be dwarfed by the diagnostic payload.

Cheers, thanks!