Subject: Re: [core] #230: Multiple Location options need to be processed as a unit

From: "core issue tracker" <[email-masked]>
Date: Mon, 04 Jun 2012 09:10:34 -0000

#230: Multiple Location options need to be processed as a unit

Comment (by zach@…):

 Proposed solution in http://tools.ietf.org/html/draft-bormann-coap-
 misc-17#section-6

-- 
-----------------------------+-------------------------------------
 Reporter:  hartke@…         |       Owner:  draft-ietf-core-coap@…
     Type:  protocol defect  |      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/230#comment:2>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 04 Jun 2012 13:47:06 -0000

Comment (by fluffy@…):

 summary of call

 Would not add envelope now - might add later.

 In addition we allocate a few reserved number for use be later specs in
 the URI that have to be understood. Could use for port, host, etc later.

 Proposal made that we have a rule that “safe to forward without
 understanding options” have a number of something like option number mod 7
 = 5. (of course more thought on 7 and 5 but you get the idea)

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

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 08:09:14 -0000

#choose ticket.new
  #when True
 Before the location in a response was split into multiple options, there
 was only one Location Option which was defined to be "elective". This
 worked well, because a client that doesn't recognize the option could
 ignore it without harm.

 However, with the Location-Path and Location-Query options (and possible
 future Location-Host and Location-Port options), the client must either
 understand or ignore all of them. Expressing such interdependencies is
 currently not possible in CoAP.

 ->

 Solution to be defined.  Focus on the problem right now.
 (One solution would be to use an envelope "Location" option to contain all
 Location-* options, so they are ignored or used as a whole.
 Reserve space in the envelope option so possible future Location-Host and
 Location-Port options appear before Location-Path and Location-Query
 options in a message.)
  #end
  #otherwise
    #if changes_body
Changes (by zach@…):

    #end
    #if changes_descr
      #if not changes_body and not change.comment and change.author
Description changed by zach@…:
      #end

--
    #end
    #if change.comment

Comment(by zach@…):

 The proxy forwarding issue now has its own ticket:
 http://tools.ietf.org/wg/core/trac/ticket/241
    #end
  #end
#end

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

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 08:59:47 -0000

#choose ticket.new
  #when True

 ->

    #end
    #if changes_descr

--
    #end
    #if change.comment

Comment(by zach@…):

 Initial fix to this ticket included in r685.

 Reserved the option numbers 44, 46, and 48 for future Location-* use, and
 defined in Section 5.10.8 that a 4.02 must be returned if any of those
 reserved options are not understood in the presence of Location-Path
 and/or Location-Query.

 Question: Are 44, 46 and 48 suitable options to reserve? Do we need to
 worry about the ordering of these? If so, it would mean moving Location-
 Path and Location-Query after these reserved values. In that case they
 could be moved lower into the 20s for example.
    #end
  #end
#end

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

---

From: "core issue tracker" <[email-masked]>
Date: Fri, 22 Jun 2012 19:27:28 -0000

Comment (by hartke@…):

 I think the option numbers reserved for future Location-* use should be
 less than the options numbers of Location-Path and Location-Query.
 Otherwise an implementation needs to perform two passes over the list of
 options to interpret the indicated location URI.

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