Subject: [core] private option type codes

From: Peter Bigot <[email-masked]>
Date: Tue, 20 Jul 2010 11:15:22 -0500

Can/should we reserve a block of option types for application use, as with
link-extension fields in the resource description?  If I find a situation
where my application needs such a feature (e.g., an option providing
application-specific authentication information), I'd rather not have to
worry that IANA will come along and use the same type code for something
else.

Peter

---

From: "Pete St. Pierre" <[email-masked]>
Date: Tue, 20 Jul 2010 09:45:03 -0700

This is a really good question. I'm curious if we're really using the Option Code field in the most efficient manner right now. Using the odd/even mechanism to distinguish "critical" from "elective" is interesting and has some conveniences, but I certainly wouldn't object to using some of the 4 bits assigned as 'length' bits to give us additional flexibility. 

We could then have a constant 8 bit length field (allow options of 0-255 bytes instead of 0-270) which further simplifies packet processing.

Out of curiousity, in the original options code creation, how many IANA approved options were we really expecting?  It is expected to be an even split between "criticial" options and "elective" options?

...Pete

On Jul 20, 2010, at 9:15 AM, Peter Bigot wrote:

> Can/should we reserve a block of option types for application use, as with link-extension fields in the resource description?  If I find a situation where my application needs such a feature (e.g., an option providing application-specific authentication information), I'd rather not have to worry that IANA will come along and use the same type code for something else.
> 
> Peter
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

--
Pete St. Pierre
[email-masked]
Sun Labs
Oracle 
16 Network Circle
Menlo Park, CA 94025

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Jul 2010 19:34:44 +0200

On Jul 20, 2010, at 18:45, Pete St. Pierre wrote:

> This is a really good question. I'm curious if we're really using the Option Code field in the most efficient manner right now. [...]

Right now, we have more critical than elective ones.  I expect that to change a bit when people start thinking up real "options" though.

How critical (pun intended) is it to have an even split?  We would have wasted a bit on the critical/elective decision anyway, and using it for the option type as well is prudent.  

I think the interesting observation is that in nearly all messages that came to coap://ns.tzi.org:61616 so far, *all* option headers (the things in front of option values) were exactly one byte.  Longer takes too much space, shorter is a pain to process.  So I think we are *exactly* where we want to be.

Gruesse, Carsten

---

From: Brian Frank <[email-masked]>
Date: Tue, 20 Jul 2010 14:10:21 -0400

+1 - I'd vote for some sort of application layer specific options (I think
the value of doing this in HTTP has proved its worth)

---

From: Peter Bigot <[email-masked]>
Date: Thu, 22 Jul 2010 10:51:18 -0500

Whether the option type is encoded as deltas or values is a subject for a
different post.  In any case, it seems 8 bits is considered enough for the
option type.  Rather than use just the low bit for critical/elective,
I'd suggest two bits to partition the space into IANA-controlled critical
(64 values), IANA-controlled elective (128 values), and private (64
values).  If delta-encoding is used, the least significant bits would be the
best choice; otherwise the most significant bits would be more natural.
Other balances could be argued as long as the three categories are
maintained; I'm not committed to 64/128/64.

I don't think observations from the test server in the first few weeks of
prototype implementation provide much evidence regarding what the use of
options will be once we understand what's required to use CoAP in industrial
situations.  I expect we're going to find that things like Uri-Authority
aren't as optional as they first appear.  For example, see section 6.3.2.1
in http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3,
which highlights the problems inferring URI components from envelope
information gave to HTTP.  Since Uri-Authority is not optional if the server
is a proxy, making it optional would require a client to know whether it's
talking directly to the authoritative server, a situation which requires
external knowledge and which might change over time without a change to the
URI itself.

Peter

On Tue, Jul 20, 2010 at 12:34 PM, Carsten Bormann <[email-masked]>wrote:

> > This is a really good question. I'm curious if we're really using the
> Option Code field in the most efficient manner right now. [...]
> > Out of curiousity, in the original options code creation, how many IANA
> approved options were we really expecting?  It is expected to be an even
> split between "criticial" options and "elective" options?
>
> Right now, we have more critical than elective ones.  I expect that to
> change a bit when people start thinking up real "options" though.
>
> How critical (pun intended) is it to have an even split?  We would have
> wasted a bit on the critical/elective decision anyway, and using it for the
> option type as well is prudent.
>
> I think the interesting observation is that in nearly all messages that
> came to coap://ns.tzi.org:61616 so far, *all* option headers (the things
> in front of option values) were exactly one byte.  Longer takes too much
> space, shorter is a pain to process.  So I think we are *exactly* where we
> want to be.
>
> Gruesse, Carsten
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2010 17:56:10 +0200

Private options could be put into a "private options" option that works like the "options" option I described except that it is not exclusive.

Alternatively, there might be a "private option" option that can be repeated.

In both cases, the start of the option (first byte?) would indicate more about what the option is.
There you have your 8 bits :-)

I nominate option numer 14 for either of these.

Gruesse, Carsten