Subject: [core] #218: Mostly obvious section 5.10.8 fixes

From: "core issue tracker" <[email-masked]>
Date: Thu, 19 Apr 2012 19:14:18 -0000

#218: Mostly obvious section 5.10.8 fixes

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

-- 
-----------------------------+-------------------------
 Reporter:  cabo@…           |      Owner:  hartke@…
     Type:  other technical  |     Status:  new
 Priority:  minor            |  Milestone:  post-WGLC-1
Component:  coap             |    Version:  coap-09
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/218>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Thu, 19 Apr 2012 19:47:14 -0000

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

-- 
-----------------------------+--------------------------
 Reporter:  cabo@…           |       Owner:  hartke@…
     Type:  other technical  |      Status:  new
 Priority:  minor            |   Milestone:  post-WGLC-1
Component:  coap             |     Version:  coap-09
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/218#comment:1>
core <http://tools.ietf.org/core/>