Subject: [core] information on option delta

From: Hari Hara Sudhan R <[email-masked]>
Date: Mon, 23 Aug 2010 14:45:58 +0530

Hi all,

I'm not clear on how to handle negative values for option delta.
If the header contains options in following order CoAP will compute option delta
it in the following way.

1. uri_Path - type 9 (option delta is 9 since this is first option)
2. uri_Scheme - type 3 (option delta here is 3 - 9 = -6. In 2's
complement form it would be 10)

Is my understanding correct?

While decoding the options.

1. first option delta is 9 so the option is calculated as 0+9 = 9
which is uri_Path
2. For second option delta is 10 so the option is 10+9 = 19. Now Im
confused on how to use this value
19 to get the option uri_Scheme (type 3).

The spec mentions about fencepost. How can i use that value for this situation?

Thanks and Regards,
Hari Hara Sudhan R

---

From: Szymon <[email-masked]>
Date: Mon, 23 Aug 2010 12:27:21 +0300

Hi,

You have to place options in ascending order before encoding, so there 
is no need for negative delta.

Szymon

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

---

From: Markus Becker <[email-masked]>
Date: Mon, 23 Aug 2010 11:27:53 +0200

> If the header contains options in following order CoAP will compute option
> delta it in the following way.
> 

As far as I understand the option delta computation:

Your options need to be ordered in increasing order, so that you do not have 
negative values.

-> first uri_scheme (3), then uri_path (9) -> delta 6

> The spec mentions about fencepost. How can i use that value for this

I think the fencepost is for jumping to higher values, if you do not have 
intermediate values.

> Hari Hara Sudhan R
------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [email-masked]
------------------------------------------------

---

From: Hari Hara Sudhan R <[email-masked]>
Date: Mon, 23 Aug 2010 16:06:45 +0530

Hi Marcus,

>I think the fencepost is for jumping to higher values, if you do not have

Thanks for your answer.

What is meant by an intermediate value here?. I could not find any
reference in specs.
If it was encoded in a sorted way how can "prev_option + delta" go beyond 9?.

Thanks and Regards
Hari Hara Sudhan R

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Aug 2010 12:49:53 +0200

> If it was encoded in a sorted way how can "prev_option + delta" go beyond 9?.

The assumption here seems to be that we will allocate more and more options, with higher and higher option numbers, and at some point someone may want to send just option 0 and option 27.  In this case, the delta would be 27 and cannot be expressed in 4 bits.  So you need to add a NOP option, in this case option 14.  The deltas are then 0, 14 and 13.
If the sender had wanted to send option 0, 12, and 27, no such "fencepost option" would be needed (the deltas would be 0, 12, 15).

Note that this only becomes relevant for a sender that indeed wants to send option combinations with such a large gap in the option numbers.  As you note, with the options we have defined so far, that cannot happen yet, but it is good to know what to do when option 16 or higher finally does get allocated.
(Also note that any properly implemented receiver already has the code to ignore an option 14.)

Gruesse, Carsten