Subject: [core] #212: Option numbers 14, 28, 42, ... reserved but usable

From: "core issue tracker" <[email-masked]>
Date: Thu, 19 Apr 2012 11:03:13 -0000

#212: Option numbers 14, 28, 42, ... reserved but usable

 Section 5.4.5. (Option Numbers) states that "the numbers 14, 28, 42, ...
 are reserved for 'fenceposting'". It is actually not necessary to reserve
 them for this; options with those numbers just need to have a default
 value that is encoded with zero bytes. The Vendor option in -misc already
 takes advantage of this.

 ->

 Clarify that while the positive option numbers divisible by 14 are indeed
 reserved, they still are available for allocation as long as a zero-length
 option with each of these numbers remains available as a no-operation
 option for fenceposting.

 (msg03034a, also covers msg03072cc)

-- 
-----------------------------+------------------------------------
 Reporter:  cabo@…           |      Owner:  draft-ietf-core-coap@…
     Type:  editorial        |     Status:  new
 Priority:  minor            |  Milestone:  post-WGLC-1
Component:  coap             |    Version:  coap-09
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/212>
core <http://tools.ietf.org/core/>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 16:06:59 -0600

> (msg03034a, also covers msg03072cc)

I wonder how many existing implementations do the right thing is they encounter a non zero length option code 14.  This gives us a very small gain in the size of the option space (less than 10%) and makes things more complicated. I think the goal here is small simple code that interoperates - if we think we need a bigger options space, we can make a bigger option space. I'm more worried about simplicity, bugs, and small code than squeezing every last bit out of the bandwidth.