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

[Thomas Fossati <[e-mail]>]

Hi Christian,

On 07/04/2020, 13:32, "Christian Amsüss" <[e-mail]> wrote:
> On Wed, Apr 01, 2020 at 10:36:10AM +0000, Thomas Fossati 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).
> >
> > 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).
> But as I understand that use case, you don't need both simultaneously.

It doesn't necessarily have to be mutually exclusive.

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

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!


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.