Multiple Location options need to be processed as a unit

[hartke@…]

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

[zach@…]

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

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

[zach@…]

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

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

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

[cabo@…]

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