Subject: [core] End of Options Marker/Use of a delta of 15

From: Stephan Lohse <[email-masked]>
Date: Wed, 18 Apr 2012 01:39:41 +0200

Hi,

do "unlimited options" and the need for an end-of-options marker mean
that deltas of 15 should not be used in that case, or is using a delta
of 15 fine as long as the length is not zero?

Regards,
- Stephan Lohse

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Apr 2012 09:20:55 -0600

Good question - I just found a bug in my code - thanks :-) 

On Apr 17, 2012, at 5:39 PM, Stephan Lohse wrote:

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

---

From: Stephan Lohse <[email-masked]>
Date: Fri, 20 Apr 2012 18:43:44 +0200

Glad to be of help, however, that didn't answer my question...? :D
Although, looking at issue #212 I might hazard a guess...

Regards,
- Stephan

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 21 Apr 2012 05:06:14 +0200

> Although, looking at issue #212 I might hazard a guess...

Ticket #212 is about the option *number* 14 (and option numbers that
are multiples of 14), not the option *delta* 14.

The option *delta* 15 is special in that it is used as the
end-of-option marker -- if and only if (a) the 'oc' field in the
message header is set to 15 and (b) the 'length' field in the option
header is set to 0. So using 15 as a delta is fine as long 'oc' is not
15 or 'length' is not 0.

(This is what coap-09 says at moment. I think the length constraint
should be dropped.)

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 21 Apr 2012 09:33:41 +0200

On Apr 21, 2012, at 05:06, Klaus Hartke wrote:

> (This is what coap-09 says at moment.

Indeed, that is what I had in mind when I wrote this.

The "Note..." was just meant to point out that the end-of-options marker in no way makes option number 15 special.

> I think the length constraint
> should be dropped.)

I was hoping to get a bit feedback from implementers which approach is better, but it appears to turn out this is pretty much a bike shed decision.

My current decoder code just compares the next byte to 0xF0.  So 0xFx with x ≠ 0 is not special in that decoder.
But then my encoder code does not go to the trouble of trying to use 15 as an option delta at all (which for oc=15 would require checking that this is a non-zero-length option).

Bike shed, bike shed.

But I'm a little in favor of reserving the entirety of 0xFx for oc=15.
If we ever start to make use of that reserved space, x would be a normal option data structure length (including x=15 taking another byte).

Grüße, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 14:23:37 -0600

On Apr 20, 2012, at 10:43 , Stephan Lohse wrote:

> Although, looking at issue #212 I might hazard a guess…

Sorry - I don't know what it should be. The issues from my point of view is having too ways to indicate the number of items in the list just seems to be an optimization that is probably not needed.

---

From: Jeroen Hoebeke <[email-masked]>
Date: Sun, 22 Apr 2012 22:16:29 +0200

> I was hoping to get a bit feedback from implementers which approach is better, but it appears to turn out this is pretty much a bike shed decision.

Easiest way of adding this to our implementation would be:
- encoder: use fencepost whenever difference between last and current option number is >= 15 (=> never use 15 as option delta, except for the end-of-option marker). 
- decoder: oc = 15 and delta = 15 -> end-marker (without checking length)

For the case where the difference is equal to 15, you have the 1-byte overhead for the fencepost.
But it safes the trouble of dealing with the encoding of a zero-length option that would normally result in an option delta of 15.

So, +1 for reserving the entirety of 0xFx for oc=15

> If we ever start to make use of that reserved space, x would be a normal option data structure length (including x=15 taking another byte).

Kind regards,
Jeroen