Subject: [core] #230: Put Location options in an envelope

From: "core issue tracker" <[email-masked]>
Date: Tue, 01 May 2012 09:40:37 -0000

#230: Put Location options in an envelope

 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.

 ->

 Use an envelope "Location" option to contain all Location-* options, so
 they are ignored or used as a whole.

 Also:

 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.

-- 
-----------------------------+------------------------------------
 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  |   Keywords:
-----------------------------+------------------------------------

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

---

From: "core issue tracker" <[email-masked]>
Date: Wed, 02 May 2012 07:41:17 -0000

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

Description changed by cabo@…:

> Location-Port options appear before Location-Path and Location-Query

New description:

 ->

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

--

-- 
-----------------------------+-------------------------------------
 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:1>
core <http://tools.ietf.org/core/>

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 2 May 2012 14:46:20 +0000

" Expressing such interdependencies is
 currently not possible in CoAP."

I'm curious what is the problem here in expressing? Can't the specification of such elective options simply say, for each option, what other options MUST be understood/supported also?

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of core issue tracker
Sent: Wednesday 2 May 2012 9:41
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [core] #230: Multiple Location options need to be processed as a unit (was: Put Location options in an envelope)

New description:

 ->

--

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

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

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 2 May 2012 17:37:21 +0200

> I'm curious what is the problem here in expressing? Can't the specification of such elective options simply say, for each option, what other options MUST be understood/supported also?

This works if an implementation recognizes all of such options, but
not if we add an option later that also belongs to the group and must
be understood.

The case is that there's the option of adding redirects to CoAP in the
future. We don't need redirects now, but we agreed that it's a good
idea not to prevent their future addition if we need them. The
response codes 96-127 (3.xx) have been reserved for this, and we would
need to add a Location-Host and Location-Port option. But if a client
recognizes Location-Path and Location-Query but not Location-Host and
Location-Port then it will interpret a redirect to a full URI like
<coap://example.org:1234/foo?bar=1> erroneously as a redirect to the
URI </foo?bar=1> relative to the request URI.

So it is important that the group of Location options, including
possible future additions, is processed or ignored as a whole.

Klaus