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

[Jim Schaad <[e-mail]>]

I have done a bit of trimming - but more responses.

Jim


-----Original Message-----
From: Thomas Fossati <[e-mail]> 
Sent: Tuesday, March 31, 2020 6:51 AM
To: Jim Schaad <[e-mail]>; [e-mail]
Cc: [e-mail]; Thomas Fossati <[e-mail]>
Subject: Re: Review of draft-fossati-core-coap-problem-02

Hi Jim, thanks very much for your comments.

> The abstract should also point to RFC 7807 so that people who 
> understand that problem set will also be able to find this one.

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.

> Give that currently RFC 7252 currently says that a server can return 
> information for diagnostic purposes, I think that there should be a 
> field defined for that purpose as part of this document as well.  This 
> would not be the same as what goes into "detail" as this is more debug 
> info than would be placed that field.  As an example, I might return 
> an error along with a debug stack when running in specific modes.  I 
> don't want to lose that ability.

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

> Are we making any statements about language for the title?

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.

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


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.