Re: [core] CoAP jump mechanism

[Carsten Bormann <[e-mail]>]

On Nov 22, 2012, at 12:23, Klaus Hartke <[e-mail]> wrote:

> a zoo of mechanisms
> to work around them:
> 
> * option count: (1) OC field, (2) end-of-options marker;
> * delta: (1) option header, (2) jump by 15, (3) long jump;
> * option length: (1) option header, (2) elongated option header.

The three numbers have a different use, a different nature, and a different distribution function.
For all of them, there is a likely small case and less likely larger cases.
So having two cases in each of them is just fine.
The delta is a bit more different because it can get very large due to the way we changed the registration policies.  So we have three (actually: four) cases.
I think we have lamented about the operation wound left by the surgical removal of fenceposts already :-)
Yes, there is a little scar on the code because of that.  But this is ten lines of code.
(I also have a design in mind that would be nine lines of code.  But let's not go there at this point...)

Honestly, what worries me myself a bit more is that many implementers these days have trouble figuring out arithmetic.
As another data point, base32 was replaced by base16 in draft-farrell-decade-ni-10.txt because implementers thought that juggling 5-bit units in 8-bit bytes was "too hard" (and this isn't even about constrained systems).  Well, it doesn't make too much of a difference here, so we are now stuck with base16.
I learn from that: protocols should be designed to be implementable requiring minimal arithmetic skills from the implementers, and I'm happy to accept this as another non-technical requirement.
I think we are safe here with CoAP for option count and option length. 
For delta, where the design is now a tiny bit suboptimal, we probably should write a couple more lines in the lwig document.
Fortunately, all these number ranges are small enough that implementers can (and should!) write exhaustive automatic tests for them.

Grüße, Carsten