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

From: Jim Schaad <[email-masked]>
Date: Mon, 30 Mar 2020 14:31:34 -0700

I have been wondering for some a draft addressing this problem was going to
show up.   I must have missed it last year when it was first published.

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

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

*  There seem to be three different points of extensibility.  You are not
documenting the namespace extension point.  I I started reading section 3.1
as if it were namespaces and was running into problems because of that.

*  Are additional attributes defined based on the namespace or on the
problem type?  While I can see both as being true, defining them based on
namespace might be easier to understand.  You might otherwise end up with an
attribute with the same id for different problem types but that mean either
the same thing, almost the same thing or completely different things.

* Are we making any statements about language for the 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?

* Insert into table 4 a row for -2^64 to -L as Private Use.  This makes life
easier on IANA

* Insert in section B.1 that the namespace is not needed because ....  Note
that CoRAL appears to think that additional attributes are based on the
namespace and not on the type.  This would lead to some potential problems
going forward.

Jim

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 31 Mar 2020 13:51:06 +0000

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"

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

> There seem to be three different points of extensibility.  You are not
> documenting the namespace extension point.  I started reading
> section 3.1 as if it were namespaces and was running into problems
> because of that.

I understand how the current structure can be confusing.  We need to
provide clearer wording.

> Are additional attributes defined based on the namespace or on the
> problem type?  While I can see both as being true, defining them based
> on namespace might be easier to understand.  You might otherwise end
> up with an attribute with the same id for different problem types but
> that mean either the same thing, almost the same thing or completely
> different things.

Agree, namespace-based attributes is the right granularity.  Thanks.
[+]

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

> 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

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.

> Insert into table 4 a row for -2^64 to -L as Private Use.  This makes
> life easier on IANA

Makes sense.  We should also fix the Specification Required range now
that you made me look at it :-)

> Insert in section B.1 that the namespace is not needed because ....

OK

> Note that CoRAL appears to think that additional attributes are based
> on the namespace and not on the type.  This would lead to some
> potential problems going forward.

See above [+]

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: Jim Schaad <[email-masked]>
Date: Tue, 31 Mar 2020 08:04:23 -0700

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

Jim

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

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

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

> registrations are being referred to?  Or are these all expected to be 

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