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:
Cc:

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: http://tools.ietf.org/wg/core/trac/ticket/241

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.