Subject: [core] draft-ietf-core-coap-09 - Editorial comments WGLC

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 17 Apr 2012 06:28:46 +0000

Below my editorial comments and questions for core-coap. I'll send some more review comments shortly after the WGLC deadline.

* Abstract: "a method/response interaction model"  -> "a request/response interaction model"
(seems more common terminology. Or is it different on purpose?)

* Section 4.1: "The same Message ID MUST NOT be re-used (per Message ID variable)"
There seems to be a requirement here on the MID variable(s) of an implementation instead of requirements on MID (re)use in messages. (Any reason for this?)

* Section 4.2: "The same rules for generating the Message ID apply."
"Same rules" could refer to Section 4.1 for the rules just to be clear.

* Section 4.5: "unicast reply to the multicast request" -> "unicast response" ?

* Section 5.2 / Figure 10: numbers alignment issue

* Section 5.2 "To ensure that this message is not lost, it is again sent as a confirmable message"
This sounds like a separate response is always CON, which is not the case?

* Section 5.2 "Responses can be sent in multiple ways" and Section 5.2.3
The subsections suggest 3 major ways. The third (5.2.3) Non-Confirmable as a separate category is a bit puzzling, since the second (5.2.2) Separate response also clearly includes Non-Confirmable responses. Or is 5.2.3 only about NON response to a NON request? If so the subsection title should be more descriptive.

* Section 5.2.3 "(preceded or followed an empty acknowledgement message)" -> "followed by"

* Section 5.3 "the response SHOULD be rejected with a reset message"
Section 4.1 defines "MUST reject it with a reset message". Why different?
Section 4.2 defines "it MAY reject the message with a reset message" for NON.
Should Section 5.3 also distinguish the CON/NON cases?
Is Section 5.3 (about matching) the best place to define such rejection conditions? (a ref. could be made to a section).

* Section 5.6.2 "after updating its freshness with the value of the Max-Age Option
that is included with the response (see Section 5.9.1.3)"
This suggests that a Max-Age Option is always included with the response.
-> "may be included with the response" ?

* Section 5.8.1 "inlcudes" -> "includes"

* Section 5.8.2. "If a resource has been created on the server, a 2.01 (Created)
   response that includes the URI of the new resource in a sequence of
   one or more Location-Path and/or Location-Query Options SHOULD be
   returned."
While section 5.10.8 defines this optional: "The two options MAY be included in a response to indicate the
   location of a new resource created with POST."
Should 5.8.2. refer to 5.10.8 to define the right behaviour (to avoid double definitions) ?

Btw "the two options MAY" -> this sounds like they have to be included as a pair, which is not the case.

* Section 5.9.1.3
"When a cache receives a 2.03 (Valid) response, it needs to update the
   stored response with the value of the Max-Age Option included in the
   response (see Section 5.6.2)."
There seems to be a requirement here to update freshness of the stored response. While Section 5.6.2 does not require an end-point to update its stored response in case new content arrives ("MAY replace the stored response"). Any reason for this difference?

* Section 5.10.3
"An end-point receiving a request with a Proxy-Uri Option that is
   unable or unwilling to act as a proxy for the request MUST cause the
   return of a 5.05 (Proxying Not Supported) response."
Section 8.1 has a SHOULD requirement on returning 5.05. Any reason for the difference, SHOULD for CoAP-HTTP proxy and MUST for CoAP proxy?

* Section 5.10.8
"If a response with one or more Location-Path and/or Location-Query
   Options passes through a cache and the implied URI identifies one or
   more currently stored responses, those entries SHOULD be marked as
   not fresh."
This feels like optimizing for a case that almost never happens (I may be wrong here).
These are only used to indicate a new resource created. Typically a new resource would not be cached anywhere, so why do implementations need to expend effort to check this?
Or can "new resource" in REST terms also include an update of an existing resource?

* Section 5.10.9
"If any of the ETags
   given as an option value match the ETag of the selected
   representation for the target resource"
"selected" is not entirely clear. Does this mean "current representation" ?

* "If none of the ETags match and," -> "If none of the ETags match OR," ?

(comments continued in next email)

regards,
Esko

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.