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

[Jim Schaad <[e-mail]>]

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