Opened 10 years ago

Closed 10 years ago

#218 closed other technical (fixed)

Mostly obvious section 5.10.8 fixes

Reported by: cabo@… Owned by: hartke@…
Priority: minor Milestone: post-WGLC-1
Component: coap Version: coap-09
Severity: In WG Last Call Keywords:
Cc:

Description

Klaus Hartke (msg03034d):

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.

Also:

Esko Dijk (msg03057m):

Section 5.10.8 “The two options MAY be included in a response to indicate the location of a new resource created with POST.”

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

Also:

Klaus Hartke (msg03034e):

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

Also:

Make sure it is obvious that all the options together indicate *one* Location.
(cf. msg03072ba)

Also:

(Fix grammar of sentence 1 in the process.)

Change History (2)

comment:1 Changed 10 years ago by cabo@…

Just to check that we have been doing the right thing here (no change is being proposed): in the HTTP space, there is draft-nottingham-linked-cache-inv that states:

HTTP [...] provides for [...] a state-changing

request to invalidate related resources (using the Location and
Content-Location headers in the response), but this is of limited
utility, because those headers have defined semantics, *and can only
occur once each.*

The draft solves that problem by showing how to use the Link: header field to invalidate more cached representations.
CoAP does not have an equivalent Link option (we carry Link information in link-format payloads, so far).
But maybe it also doesn't need to solve the original problem either.

comment:2 Changed 10 years ago by zach@…

  • Resolution set to fixed
  • Status changed from new to closed

The following fix to r689 was made:

5.10.8.  Location-Path and Location-Query

   The Location-Path and Location-Query Options together indicate a
   relative URI Location that consists either of an absolute path, a
   query string or both, and that is resolved relative to the request
   target URI.  The Location-Path Option is similar to the Uri-Path
   Option, and the Location-Query Option similar to the Uri-Query
   Option.  The value of a Location-Path Option MUST NOT be '.' or '..'.

   Any combination of these options MAY be included in a response to
   indicate the location of a new resource created with POST.

   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.

   More Location-* options may be defined in the future, and have been
   reserved option numbers 44, 46 and 48.  If any of these reserved
   option numbers occurs in addition to Location-Path and/or Location-
   Query and are not supported, then a 4.02 (Bad Option) error MUST be
   returned.

   Both options are "elective" and MAY occur one or more times.
Note: See TracTickets for help on using tickets.