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

[Thomas Fossati <[e-mail]>]

On 31/03/2020, 16:04, "Jim Schaad" <[e-mail]> 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.