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

[Thomas Fossati <[e-mail]>]

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

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