Opened 10 years ago

Closed 10 years ago

#230 closed protocol defect (fixed)

Multiple Location options need to be processed as a unit

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

Description (last modified by cabo@…)

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

Change History (7)

comment:1 Changed 10 years ago by cabo@…

  • Description modified (diff)
  • Summary changed from Put Location options in an envelope to Multiple Location options need to be processed as a unit

comment:3 Changed 10 years ago 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)

comment:4 Changed 10 years ago by zach@…

The proxy forwarding issue now has its own ticket:

comment:5 Changed 10 years ago 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.

comment:6 Changed 10 years ago 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.

comment:7 Changed 10 years ago by cabo@…

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

Fixed in coap-10.
There was no specific support for reordering the options in order to keep the reserved values earlier.

Note: See TracTickets for help on using tickets.