Subject: [core] draft-core-coap-09 - Nits

From: Klaus Hartke <[email-masked]>
Date: Mon, 16 Apr 2012 17:11:58 +0200

* Section 5.4.5. (Option Numbers) states that "the numbers 14, 28, 42,
... are reserved for 'fenceposting'". It is actually not necessary to
reserve them for this; options with those numbers just need to have a
default value that is encoded with zero bytes. The Vendor option in
-misc already takes advantage of this.

* Section 5.10. (Option Definitions) defines the Uri-Path, Uri-Query,
Location-Path and Location-Query options to have a minimum length of 1
byte. This is a remnant of the time when each option could be included
only at most once instead of for each path segment/query argument
individually. Segments and arguments can have a length of zero
characters.

* Section 5.10.2. (Uri-Host, Uri-Port, Uri-Path and Uri-Query) states
that "the Uri-Path and Uri-Query Option can contain any character
sequence." It should define that it must be a string in Net-Unicode
form.

* Section 5.10.8. (Location-Path and Location-Query) state that the
Location-* options describe an "absolute path URI". But if there is
only a Location-Query option, there is no path. The section should say
that the Location-* options describe a relative URI that consists
either of an absolute path, a query string or both, and that is
resolved relative to the request target URI.

* Section 5.10.8. (Location-Path and Location-Query) should define
that "the value of a Location-Path Option MUST NOT be '.' or '..'."

* Should there be text on combining the Location-* options into a
relative URI, and splitting an URI into Location-* options? Sections
6.4 and 6.5 currently do not apply, and the steps are slightly
different.

* There's the option of adding redirects to CoAP in the future, e.g.
the response codes 96-127 (3.xx) have been reserved for this. Should
option numbers be reserved so future Location-Host and Location-Port
options would appear before Location-Path and Location-Query options
in a message?

* In section 5.6.1. (Freshness Model) it should be mentioned that, if
a client has fresh stored response and makes a new request, the new
response invalidates the old response.

Klaus