Subject: [core] CoAP jump mechanism

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 20 Nov 2012 15:06:41 +0000

Dear list

We just stumbled upon some issues with coap-12's jump mechanism:

The exact bounds should be given, just like for the option length encoding to avoid problems due to the integer division.
I also assumed that deltas 15..29 are handled by a 0xF1 jump. The text in Figure 9, however, may also imply that 0xF1 is only used for delta==15 and for the overlapping region, 0xF2 SHOULD be used.
I would prefer the 0xF1 jumps, as they save one byte. Or is this just left to the implementation?

Ciao
Matthias

---

From: Markus Becker <[email-masked]>
Date: Tue, 20 Nov 2012 17:02:10 +0100

> The exact bounds should be given, just like for the option length encoding
> to avoid problems due to the integer division. I also assumed that deltas
> 15..29 are handled by a 0xF1 jump.

> The text in Figure 9, however, may also
> imply that 0xF1 is only used for delta==15 and for the overlapping region,
> 0xF2 SHOULD be used.

Hello Matthias,

when implementing this, I read this figure exactly the way you say in the 
sentence above. The interpretation of the figure, might as well impact the 
ETSI interop event.

If read otherwise, the (Delta/8)-2 should be different, so that there is no 
overlap, or? Then, a delta of 30 should be coded to 0xf2 0x00? Thus, the 
equation becomes Delta-30. Similarly, (Delta/8)-258 should be changed.

For 15..29:
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1 | 0   0   0   1 |  0xf1
   +---+---+---+---+---+---+---+---+

For 30..269:
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1 | 0   0   1   0 |  0xf2
   +---+---+---+---+---+---+---+---+
   |       Option Jump Value       |  Delta-30
   +---+---+---+---+---+---+---+---+

For 270..65818:
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1 | 0   0   1   1 |  0xf3
   +---+---+---+---+---+---+---+---+
   |                               |
   +---    Option Jump Value    ---+  Delta-270
   |                               |
   +---+---+---+---+---+---+---+---+

Markus

> I would prefer the 0xF1 jumps, as they save one byte.
> Or is this just left to the implementation?
> 
> Ciao
> Matthias
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [email-masked]
| telephone: +49 421 218 62379
| building: NW1 room: N2260
------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Nov 2012 18:08:53 +0100

On Nov 20, 2012, at 16:06, "Kovatsch  Matthias" <[email-masked]> wrote:

> I also assumed that deltas 15..29 are handled by a 0xF1 jump.

That is the intention.
(15 is handled by 0xf1, and the rest of 0..14 is handled by a normal delta.)

> The text in Figure 9, however, may also imply that 0xF1 is only used for delta==15 and for the overlapping region, 0xF2 SHOULD be used.

The delta in Fig 9 is the one effected by the Jump.  The 4-bit delta in the following option has to be added to that.
(Yes, this could be said explicitly.)

I agree that it would be nicer if there were no overlap between the deltas covered by "f1 xy" and "f2 nn xy".  Unfortunately, what we wrote down in coap-12 has this overlap (caused by the attempt to avoid a division by 15), and the specific approach I chose was not so bright.
We could go ahead and introduce *another* breaking change, or live with the slight inefficiency for a number of option deltas around 2070 (which could be "f2 ff xy" instead of "f3 00 00 xy" if there were no overlap).

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Nov 2012 18:54:27 +0100

> For 30..269:

Ah, but the Jump value is multiplied by 8 to get the actual delta (plus some constant) -- we still have the 4-bit delta in the actual option header for the rest.
So if we did this, 0xf2 would reach from 30 to 2084, and only for 2085+ you would need 0xf3.
(Right now, that number is 2071; so the net effect of the mistake I made is that we waste a byte for total (jump + 4-bit) option number deltas between 2071 and 2084; I still believe that is a livable loss for not introducing another breaking change.)

So if you want to give exact ranges and start from totalDelta, for what is in coap-12 now:

> For totalDelta between 30..2070:
>     0   1   2   3   4   5   6   7
>   |       Option Jump Value       |  (totalDelta-23)/8
> For totalDelta 2071..65535:
>     0   1   2   3   4   5   6   7
>   +---    Option Jump Value    ---+  (totalDelta-2071)/8
>   |                               |

(And, if I hadn't had that thinko, it would be -37 instead of -23 and -2085 instead of -2071.  I think :-)

That's what you get for retrofitting something like this; by now I of course have a completely different, "cleaner" design in mind, but that wouldn't be less code either.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 20 Nov 2012 17:58:34 +0000

> to avoid problems due to the integer division.

Okay, good to be clear on that.

> > The text in Figure 9, however, may also imply that 0xF1 is only used for
> delta==15 and for the overlapping region, 0xF2 SHOULD be used.
> The delta in Fig 9 is the one effected by the Jump.  The 4-bit delta in the
> following option has to be added to that.

I was only confused because the overlap was not mentioned at all and usually the draft is quite helpful with implementation considerations :)

> I agree that it would be nicer if there were no overlap between the deltas
> covered by "f1 xy" and "f2 nn xy".  Unfortunately, what we wrote down in
> coap-12 has this overlap (caused by the attempt to avoid a division by 15),
> and the specific approach I chose was not so bright.
> We could go ahead and introduce *another* breaking change, or live with
> the slight inefficiency for a number of option deltas around 2070 (which could
> be "f2 ff xy" instead of "f3 00 00 xy" if there were no overlap).

Yeah, let us just keep it this way, otherwise we need another strange summand in the formula...

Ciao
Matthias

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 22 Nov 2012 02:52:08 +0000

Hi all,

This is a good opportunity to dig up my (now rather dusty) knowledge about interval analysis from my university times, even though that was continuous math, whereas here we work in the discrete domain.

Two intervals A=[aL,aH] and B=[bL,bH] can be added through the rule A+B=[aL+bL,aH+bH].

Below, I will be cheating a little as in the continuous domain, multiplying an interval by a constant properly leads to an interval that contains all values between its minimum and maximum, whereas in the discrete domain holes within the interval appear.

We can signal the regular option deltas 0..14 without long jump; the related interval is Dr=[0,14].

We denote the long jump interval for 0xf1 by L1=[15,15], for 0xf2 by L2 and for 0xf3 by L3. The option deltas that can be reached through 0xf1 are thus within D1=L1+Dr=[15,29].

For 0xf2, 0<=(Delta/8)-2<=255 resolves to L2=[16,2056] => D2=L2+Dr=[16,2070]. We see an overlap D1^D2=[16,29] (14 values).

For 0xf3, 0<=(Delta/8)-258<=65535 resolves to L3=[2064,526344] => D3=L3+Dr=[2064,526358]. Another overlap D2^D3=[2064,2070] (7 values).

I believe the form (Delta/8)-x indeed is best, as division by non-powers of two is cumbersome, and dividing by 16 would lead to holes due to the size of Dr. However, dividing by 8 means that we cannot avoid all overlap.

So for 0xf2, 0<=(Delta/8)-x2<=255 would resolve to L2=[8*x2,2040+8*x2] and thus D2=[8*x2,2054+8*x2]. To minimise the overlap, it would be best if we chose the highest x2 such that 8*x2<=30. This leads to x2=floor(30/8)=3, whereas currently it is specified as 2. The new value would give D2=[24,2078], implying an overlap D1^D2=[24,29] (6 values).

For 0xf3, 0<=(Delta/8)-x3<=65535 gives L3=[8*x3,524280+8*x3] and D3=[8*x3,524294+8*x3]. Taking x2=3, to avoid overlap, we need to maximise x3 such that 8*x3<=2079 => x3=259. This gives D3=[2072,526366] and an overlap D2^D3=[2072,2078] (7 values).

Summary
-------
Changing the formulas to (Delta/8)-3 for 0xf2 and (Delta/8)-259 for 0xf3 would save us 8 overlapping values.

I am not sure if this justifies a change in the spec though (since it is non-editorial, though small).

Probably a far too complicated way to come to this conclusion, but at least it confirms earlier findings... :-)

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kovatsch Matthias
Sent: 21 November 2012 01:59
To: Carsten Bormann
Cc: [email-masked] WG
Subject: Re: [core] CoAP jump mechanism

Ciao
Matthias

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 22 Nov 2012 13:23:14 +0200

> I am not sure if this justifies a change in the spec though (since it is non-editorial, though small).

I wouldn't worry too much about this small inefficiency. What actually
bothers me is the accumulated wealth of different solutions for the
same problem: At the beginning, the message format was designed for 0
to 15 option instances, each with a delta between 0 and 15 and a value
length between 0 and 15. All of these three artificial limitations
were found to low over time, so we ended up with 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 result is surely a small packet size, but I'm wondering if this
also applies to code size and the amount of head-scratching that an
implementer needs to do to get an implementation of CoAP.

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Nov 2012 15:29:40 +0100

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

> a zoo of mechanisms

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

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 22 Nov 2012 17:23:25 +0200

> Honestly, what worries me myself a bit more is that many implementers these days have trouble figuring out arithmetic.

Figuring out clever arithmetic is not the problem -- in particular if
this leads to an overall small packet size and code size.

What I dislike is that there are 6+ instances where a different
arithmetic needs to be figured out, just to solve the same problem:
that 4 bits are not enough to encode the useful range of option
counts, deltas and lengths. Why can't the same code (consisting of two
cases) be used for all three numbers?

I see how we ended up where we are: For us, it's much easier to just
change a few lines in our existing code base and make a small change
to the draft, than to come up with a new format that is easy to
implement in new code bases.

In my opinion though we should optimize for new CoAP implementations
with constrained code size, and not primarily for minimal changes to
the existing implementations.

> I think we have lamented about the operation wound left by the surgical removal of fenceposts already :-)

I attended the Atlanta meeting only remotely, but to me it felt like
the audience was quicker to agree to this change than you were. Did I
get a wrong impression?

> For delta, where the design is now a tiny bit suboptimal, we probably should write a couple more lines in the lwig document.

I would argue for less lines of code and text, not for more.

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Nov 2012 16:48:16 +0100

On Nov 22, 2012, at 16:23, Klaus Hartke <[email-masked]> wrote:

> arithmetic needs to be figured out

We heard you.

All but the delta computation for jump are trivial, though.
(And that's where I think documentation solves the problem nicely, because the resulting code still is trivial.)

There may be some cognitive dissonance in what we arrived at over time, but there is no design from scratch that is actually significantly simpler.
In engineering, you have to know when to stop tweaking...

Grüße, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Thu, 22 Nov 2012 18:02:48 +0200

> cases) be used for all three numbers?

Do you have a particular proposal in mind? 

I would argue that it is too late to make huge changes or redesign from scratch - we have a lot of industry really using this and just promised that coap-12 was the last breaking compatibility change (with WG consensus behind it). That said, if there is something we can remove, simplify or explain better that does not break backward compatibility with coap-12, then we should definitely consider it. In particular if there is something that can be simply removed or simplified that is not really needed, that would be perfectly fine at this point. 

> implement in new code bases.

The IETF has a policy of running code for a good reason, but it does result in having to realize protocol evolution as you are really using a protocol and moving it towards RFC while working out issues. I think we've done a great job of that, and have had running code and real products using our specifications all along. The downside is that you need to evolve a protocol and can't just do a fresh re-design. I totally prefer this to what is done in many SDOs - design a monster of a protocol, publish the standard, then cross your fingers and hope it will work :-/

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 22 Nov 2012 16:42:39 +0000

Hi Zach,

> The IETF has a policy of running code for a good reason, but it does result in having to realize protocol evolution as you are really using a protocol and moving it towards RFC while working out is…

it sounds like you're arguing that CoAP is no more in its prototyping phase.

I would counter-argue that until it is not gone through WGLC and has
passed it, it has to be considered prototypal, independently of the
cardinality of the already deployed software/hardware base.

The IETF model of running code must be a value added to the process of
creating protocols -- in that it provides early evidence of what works
and what doesn't, and allows for fixing issues before it's too late --
not as a bond that prevents us from getting a clean and satisfactory
design in the end.

I share the same "bad feeling" WRT the current option encoding
algorithm as Klaus, and would be happy to see a more elegant solution,
if at all possible.  But I can also live with Carsten's argument about
the fact that re-designing from scratch the option encoding would not
provide any major benefit over what we have now.

Instead, saying we can't move bits around because it would break
existing deployments, well, this is less likely to be an acceptable
reason, at least for me.

Cheers, Thomas.

---

From: Zach Shelby <[email-masked]>
Date: Thu, 22 Nov 2012 19:10:37 +0200

Hi,

> not as a bond that prevents us from getting a clean and satisfactory

Of course not. It just affects the way we design and evolve protocols - in a good way in my opinion. We end up with protocols that really work, with tons of experience in using them. 

> provide any major benefit over what we have now.

I happen to feel the same. 

> existing deployments, well, this is less likely to be an acceptable

Also note I said I am open to hearing good proposals :-) 

Zach

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Nov 2012 18:44:24 +0100

On Nov 22, 2012, at 17:42, Thomas Fossati <[email-masked]> wrote:

> would be happy to see a more elegant solution

I actually went to the trouble and designed that, before I came up with the current jump design.
The "elegant" solution certainly *looked* better on a napkin, but it had pretty much the same complexity.
And it would have been much more of a breaking change.

So as long as the IETF doesn't create a directorate for protocol aesthetics (I want to be a founding member!), let's stick with what we have.

Grüße, Carsten

PS.: At least we now have carved out an assignment for the next "Protocol Design" class:

Design a type-length-value encoding for a protocol that needs to be relatively compact, as well as low-complexity in implementation.
Multiple TLVs of the same type must be representable and maintain ordering; otherwise, ordering can (and should) be defined by the protocol.
The TLV section needs to be self-delimiting, i.e. at the end you need to know that you are at the end (there is a single "payload" following).
The number of TLVs in any instance is likely to be below five, but can expand without a defined bound (except that the overall packet length will stay below 2**11 bytes).
There can be zero TLV elements, this should use zero bytes.
In addition to the TLV elements themselves, you can use approximately four bits in the header.
Values can rarely have a byte length of up to about 2**10 bytes, but are typically short, often 0, 1, 2, or 3 bytes, with another small cluster below approximately 10 bytes.
The type range is focused on cardinals in the below 50s, but can expand up to 2**16 (and will typically stay in clusters if that is the case).
The sequence of TLVs must be stable when a TLV is added or removed.  
Every single value must be encoded as-is (no stuffing expansion, no intervening delimiters) so an implementation can represent it internally by a length and a pointer into the packet.
More generally, an encoding that has just one or a small number of representations for a single TLV set to be encoded is favored.
The overall processing should be on the level of bytes (possibly with a few subdivisions within, such as nibbles); bit-level compacting without regard for byte boundaries is not acceptable for complexity reasons.  There should be no need to do operations that are non-trivial on constrained systems, such as an integer divide, to build or decode the protocol encoding.
Any solution that is not much worse in encoding space or complexity than the CoAP TLV encoding is acceptable (e.g., the solution should not use more than one byte TL overhead per TLV in the typical case).

Any requirements that I have missed?  Should be a fun assignment.  But no bearing on CoAP at this point in its life.
(The fun thing is that the CoAP encoding is *simpler* than the set of requirements.  That's the way it should be...)

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 22 Nov 2012 18:16:02 +0000

> The "elegant" solution certainly *looked* better on a napkin, but it had pretty much the same complexity.

mmm, for "a more elegant solution" I mean one which lower the
complexity, not one that stays pretty much the same as the current
proposal.  But I guess half the members of the directorate for
protocol aesthetics would disagree with me on this point :-)

So, as already said, if we can't find a better solution (and in a
reasonably short time frame), I'd be perfectly fine with the current
state of art.

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 23 Nov 2012 00:22:07 +0200

I've given it a quick try.

The basic idea:

* option count: always use an end-of-options marker; get rid of the OC field.
* delta/length: use 4 bits; insert one or two additional bytes after
the option header if necessary.

I've implemented it and compared it against the current encoding using
the 23 core ETSI Plugtest2 test cases (~ 30 request/response pairs).
I've also made a first attempt at writing it down (see attachment).

                            Before      After

Request Header Bytes        544         546
Response Header Bytes       506         497

Pages of Text               5           3

Lines of Code               209         112
(for Option Count, Delta and Length combined)

So the improvements are clearly not in the packet size, but in the
code size and the number of times an implementer has to bang his head
against the wall.

I guess this can be further improved.

Klaus

--
My code to encode the option header:

public void WriteOptionHeader(CoapOption number, int length)
{
    int p = this.pos++;
    int hi = WriteOptionHeaderField(number - this.prev);
    int lo = WriteOptionHeaderField(length);
    this.buffer[p] = (byte)((hi << 4) | lo);
    this.prev = number;
}

private int WriteOptionHeaderField(int value)
{
    if (value > 255)
    {
        this.buffer[this.pos++] = (byte)(value >> 8);
        this.buffer[this.pos++] = (byte)value;
        return 14;
    }
    else if (value > 12)
    {
        this.buffer[this.pos++] = (byte)value;
        return 13;
    }
    else
    {
        return value;
    }
}

public void WriteEndOfOptions()
{
    this.buffer[this.pos++] = 0xff;
}

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 22 Nov 2012 23:11:28 +0000

> I've given it a quick try.

Heck Klaus, you are quick :-)  Besides, the proposal is sound, I like it.

Just one nit: you don't tell what we are supposed to do with the
nibble just after the Option Terminator.  Discard it, right ?

Anyway, +1 !

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 00:17:34 +0100

> Response Header Bytes       506         497

Can you check these numbers?  They don't fit your code.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 23 Nov 2012 01:49:07 +0200

> Heck Klaus, you are quick :-)  Besides, the proposal is sound, I like it.

I'm glad you like it.

> nibble just after the Option Terminator.  Discard it, right ?

The text can be improved a lot; I just wanted to write the basics down
quickly. On that nibble, something like "must set to x when sent and
ignored when received" would need to be added.

Best regards,
Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 23 Nov 2012 01:50:16 +0200

Carsten Bormann wrote:
> Klaus Hartke wrote:

I've just double-checked my code and rerun the test with the same
result. The numbers are correct.

Best regards,
Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 00:56:26 +0100

> result. The numbers are correct.

Ah, you have more code for special-casing the Token.  Got it.
I read only the code, not the text.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 23 Nov 2012 02:04:39 +0200

> Ah, you have more code for special-casing the Token.  Got it.

Yes. But it's less code. I removed 20 lines and added 12.

Best regards,
Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 01:10:33 +0100

> ignored when received" would need to be added.

It's better to keep it open for future extensions.
Only allow 0xFF as the terminator and make everything else an error.
Just don't pretend the 0xFF is an option header, it isn't.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 01:45:32 +0100

> Yes. But it's less code. I removed 20 lines and added 12.

Oh, I *like* special-casing Token.  Putting it right after the message-ID also allows some interesting additional simplifications in constrained-system code.

Your numbers look good because you aren't using the default Token very much.  This means in your corpus the Token optimization compensates spending a byte for the start-of-payload delimiter (and, because Token has a high option number, for some responses, actually saves a byte).

Grüße, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Fri, 23 Nov 2012 10:13:02 +0200

Hi,

Nice proposal, thanks.

- Regarding the Token right after the header (as some kind of special option), I am not so sure I like that. Considering we are NSTART=1 for the base protocol, you can usually do with the default value anyways. Would prefer to keep the base header fixed-length and just leave Token as an option.

- I do like dropping the Option Count, this is something we can easy do anyways (independent of the rest of the proposal). 

- The Option Delta and Length extension mechanism here is good. But it should have been proposed earlier when we were considering the jump mechanism and then approving it in the working group. Also with your mechanism of being able to easily represent 0-12, 0-255 and 0-65535 option deltas, you no longer really need option deltas at all. Why not just go to straight option numbers at that point? Yes it is slightly less efficient, but then it is a lot easier to do ultra-simple single purpose implementations (like Jari's assembler Ethernet thing) and to debug. 

Zach

On Nov 23, 2012, at 12:22 AM, Klaus Hartke wrote:

> <new-format.txt>_______________________________________________
> core mailing list
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 09:36:35 +0100

On Nov 23, 2012, at 09:13, Zach Shelby <[email-masked]> wrote:

> Hi,
> 
> Nice proposal, thanks.
> 
> - Regarding the Token right after the header (as some kind of special option), I am not so sure I like that. Considering we are NSTART=1 for the base protocol, you can usually do with the default value anyways.

Yeah. Just set TL=0 and don't send anything.

> Would prefer to keep the base header fixed-length and just leave Token as an option.

It *is* kind of optional in Klaus' current proposal -- you can send 0 bytes.

> - I do like dropping the Option Count, this is something we can easy do anyways (independent of the rest of the proposal). 

If we actually do a breaking change, we should go the whole way.
(I'm not yet convinced of that, BTW.)

> - The Option Delta and Length extension mechanism here is good. But it should have been proposed earlier when we were considering the jump mechanism and then approving it in the working group.

Yes, definitely.

> Also with your mechanism of being able to easily represent 0-12, 0-255 and 0-65535 option deltas, you no longer really need option deltas at all. Why not just go to straight option numbers at that point? Yes it is slightly less efficient, but then it is a lot easier to do ultra-simple single purpose implementations (like Jari's assembler Ethernet thing) and to debug. 

Option number deltas are:
-- indeed significantly more efficient; but more importantly:
-- guarantee an order, which is good for the receiver, and rarely adds complexity at the sender.

Item 2 is really what reduces complexity significantly.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 09:39:04 +0100

> Just don't pretend the 0xFF is an option header, it isn't.

Actually, call it "Payload Start Indicator", and only send it if there actually is a payload.
This gives the efficiency of the current scheme even for default-token messages, as long as they have no payload (which should be about half of them).

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 23 Nov 2012 10:49:54 +0200

> This gives the efficiency of the current scheme even for default-token messages, as long as they have no payload (which should be about half of them).

With this change, I get the following numbers:

                            Before      After

Request Header Bytes        544         527
Response Header Bytes       506         486

Best regards,
Klaus

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 23 Nov 2012 09:57:40 +0100

I like your proposal as well, it may also help monolithic or
"cross-layer" CoAP implementations.

I have a small improvement to it, with the aim of supporting also
small tokens that do not need to be carried inline.

This fixes also another problem with constrained devices. That devices
MAY choose also to only support small tokens that have a very limited
size. This provides an "entry level" support for tokens on hosts that
cannot allocate up to 8 bytes for the token on each request slot.

With static allocation supporting it means reserving 8 bytes for each
request slot, even if the token is smaller or absent as well.

Best,
Angelo

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 10:38:28 +0100

> small tokens that do not need to be carried inline.

Small Tokens have always been supported.

Your encoding change looks like you believe the structure of the encoding shapes the choices of the implementers: By making it more efficient to send a Token of up to three bits, implementers will choose to do so.

That may be true to some extent, but what is wrong with sending a small token in a 1-byte part?
Neither giving up the reserved bit nor adding a special case for Tokens < 8 enthuses me...
(And then there is the pesky detail that a one-byte Token with 0x00 is different from a zero-byte Token.)

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 23 Nov 2012 09:44:57 +0000

> Response Header Bytes       506         486

So, with Klaus proposal we are getting very good figures and an
extremely simple decoding algorithm.

Add to this the excellent idea proposed by Angelo for inlining tiny
tokens, and we reach a point where efficiency and simplicity of design
met without one compromising the other.

What do we want more ?

---

From: Zach Shelby <[email-masked]>
Date: Fri, 23 Nov 2012 11:51:16 +0200

> (And then there is the pesky detail that a one-byte Token with 0x00 is different from a zero-byte Token.)

Have to agree with Carstren, not sure I see the gain vs. extra code options pain here. The point of the exercise Klaus is going through is to reduce the number of options and complexity. This goes in the opposite direction. The Token is often set by the one who is not a super duper constrained node anyways (e.g. in Observation that is usually the case). 

Zach

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 23 Nov 2012 11:47:12 +0100

Carsten, Zach,

please evaluate better the reasons why I am proposing this.

A server supporting the Token option MUST be prepared o receive up to
8 bytes by the client, and MUST echo it back to the client when the
request has been successfully processed.

Tokens are a pain from a constrained server perspective, typically
constrained servers allocate memory in a static way. To avoid
statically reserving 8 bytes for *each* request slot, a server
implementor may choose to not support token option at all (is it
permitted to a server to do this, right?).

On Nov 23, 2012, Carsten Bormann wrote:
> [...] what is wrong with sending a small token in a 1-byte part?

A constrained server, thus using static allocation, has some way to
support ONLY 1-byte tokens?

On Nov 23, 2012, Carsten Bormann wrote:
> Neither giving up the reserved bit [...] enthuses me...

Yes I share your perplexity. A reserved bit in the first byte of the
header is a very precious one. We have to carefully reflect its usage.

On Nov 23, 2012, Carsten Bormann wrote:
> nor adding a special case for Tokens < 8 enthuses me...

On Nov 23, 2012, Zach Shelby wrote:
> [...] not sure I see the gain vs. extra code options pain here.
> The point of the exercise Klaus is going through is to reduce the number of options and complexity.
> This goes in the opposite direction.

Complexity is my concern too, infact my proposal is aiming to reduce
the complexity of implementing the token for servers.

My point is that if they can choose to ONLY implement a Short Token,
they will probably support it in the short version.

On Nov 23, 2012, Zach Shelby wrote:
> The Token is often set by the one who is not a super duper constrained node anyways (e.g. in Observation that is usually the case).

Zach, that is exactly the point. Clients are usually not that
constrained, but servers are!

If I am a server supporting observations and tokens, and assume that I
use static allocation which is usually the case in constrained
servers.

I have to allocate a number of memory slots to save the state of that
observation. Each slot have to contain also a field for the Token of 8
bytes, no matter that I will not receive it in my observation request,
or that the actual token received is 1 byte long!

Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 23 Nov 2012 11:48:17 +0100

> (And then there is the pesky detail that a one-byte Token with 0x00 is different from a zero-byte Token.)

I forgot to address this.

I attach an updated proposal.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 12:27:52 +0100

On Nov 23, 2012, at 11:47, "Angelo P. Castellani" <[email-masked]> wrote:

> 8 bytes by the client,

I'm not sure that is a binary choice.
What you are proposing is an encoding change.
If the semantics above were true then any server supporting the three-bit Tokens would also need to support the 8-byte tokens.
I don't know why you believe a different encoding changes the semantics here.

> and MUST echo it back to the client when the

That much is true.

In reality a server that is severely resource constrained will have to do what needs to be done.
If rejecting Tokens beyond a single byte is what makes that server possible (and it wouldn't work with long tokens), then you can always 5.00 on a long token.

I think the lwig document might be enhanced with some language on how a client should be choosing token values.

Grüße, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 23 Nov 2012 13:00:38 +0100

A server may choose arbitrarily which size of token to support?

So a client sending a request with a token, may have to poll the
server until it finds a token size that works for that server?

I share that ideally a client MUST choose the token size for a request
as the shortest possible for him, so a 5.00 will be obtained only in
that case.

But allowing a server to arbitrarily choose the size of token it
supports seems a pain for interoperability to me. Imagine that we will
have servers not supporting tokens, servers supporting tokens up to
1-byte, servers supporting tokens up to 2-bytes, etc. etc

Understanding the capabilities of a server (options supported), if
them cannot be known in advance, and intersect them with that
required/supported/needed by the client could happen to be an
operational nightmare for CoAP.

IMHO if we add to this that the Token option can be supported in 9
different ways we are really growing the operational complexity!

Angelo

p.s.: a server may support 2-bytes, 4-bytes and 8-bytes tokens, but
not 1-byte, 3-bytes, 5-bytes, 6-bytes or 7-bytes? assume that it
chooses to support only those sizes to simplify its implementation. is
it permitted?

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 13:12:17 +0100

> server until it finds a token size that works for that server?

No.  A half way reasonable client will choose the smallest token that makes the application work.
If the server can't handle that, they wont interoperate.  
(Note that we are talking about heroically small systems here, if the Token size actually does matter.)

And there is no point in retrying with a smaller token if the client needed the larger one in the first place.
(If it didn't, why did it send a large token?)

A client that uses a small NSTART will use the default Token (0 bytes) or a small one (1 byte).
A client that also needs some protection against cache poisoning from off-path attackers, but can't use DTLS for some reason, may want to use a larger token (6-8 bytes).  Those servers that are stateless will have no problem implementing this.

Maybe you are trying to use Token for something it wasn't meant for.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 23 Nov 2012 12:23:11 +0000

> Response Header Bytes       506         486

I also like the clean-up and of course the performance gain, which should be a main goal for constrained environments.
Back when tackling the 270 byte limit, the resistance seemed too big to do the clean-up. Thus, also the quick agreement in Atlanta, I guess.
It definitely is painful do have another breaking change, but only now we know what we need. Prototyping along the different drafts helped us a lot there.

In short:
+1

> Angelo P. Castellani:
> But allowing a server to arbitrarily choose the size of token it supports seems
> a pain for interoperability to me.

But is having two different ways to encode the Token not just along these lines?

Ciao
Matthias

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 23 Nov 2012 14:33:01 +0100

> Maybe you are trying to use Token for something it wasn't meant for.

I am not using Tokens anyway :)

However, since this will be a standard, I was trying to think all the
situations I can came around.

Best,
Angelo

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 14:42:43 +0100

On Nov 22, 2012, at 23:22, Klaus Hartke <[email-masked]> wrote:

> <new-format.txt>

One thing I'm not sure I like is that the "Klaus encoding" has multiple ways to say the same thing:
If an option length is, say, 10 bytes, this can be expressed by a 4-bit field of value 0xA, a 4-bit field of value 0xD followed by a byte of value 0x0A, and by a 4-bit field of value 0xE followed by two bytes of value 0x000A.

We have this problem already in the uints (with a SHOULD tying to outlaw it), but so far we didn't have it in the option encoding itself -- this was bijective between the abstract set of (sequences of) option values and the encoding.

To fully keep this property, we would have to add back some of the dreaded arithmetic, e.g.:

            13:  An 8-bit unsigned integer follows the initial byte and
                 indicates the value of ([delta/length] - 13).

            14:  A 16-bit unsigned integer follows the initial byte and
                 indicates the value of ([delta/length] - 269).

There are a couple of cases where this happens to save a byte (256-269), but this is not my main intention.
My objective is to make sure that a receiver doesn't have to cope with multiple ways of saying the same thing, which is always causing hard-to-debug interoperability problems when some of these ways work and others don't.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2012 14:45:45 +0100

On Nov 23, 2012, at 14:42, Carsten Bormann <[email-masked]> wrote:

> 256-269

Math is hard, let's go shopping (it's Black Friday!).

I meant 256-268, of course.

Grüße, Carsten

---

From: Bert Greevenbosch <[email-masked]>
Date: Sat, 24 Nov 2012 01:24:05 +0000

> operational nightmare for CoAP.

The mechanism from draft-greevenbosch-core-profile-description is intended to provide server specific information in advance.

I am not in favour of having two separate mechanisms for tokens though.

Best regards,
Bert

http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile-description/

---

From: Zach Shelby <[email-masked]>
Date: Sat, 24 Nov 2012 20:58:41 +0200

> My objective is to make sure that a receiver doesn't have to cope with multiple ways of saying the same thing, which is always causing hard-to-debug interoperability problems when some of these way…

+1. I think this is a valid improvement to Klaus's design.

Klaus, could you please do a design update so that we can properly assess it taking into account the useful suggestions from this thread? In particular including the end of options flag only when the payload is there and the ranges suggested by Carsten. If we would decide to do a change like this, the time window for doing it would need to be very short. 

Thanks,
Zach

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 25 Nov 2012 02:00:53 +0200

Attached is a new version of the text with the following changes:

* Include the end-of-options/start-of-payload marker only if payload is present.

* No payload and a zero-length payload are considered equivalent. (Is
this the right choice?)

* Payload marker is specified separately from the option format.

* Non-overlapping option delta/length field values.

* More fancy artwork.

Best regards,
Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 25 Nov 2012 07:48:41 +0100

> * More fancy artwork.

I liked the old version (32 bits in a row) better.
(The one-byte-per row format is fine for the option.)

Terminologically, I'd stick with a fixed 4-byte header, which is followed by the Token value, if any.

** Technical comments:

What happened to 8-byte Tokens?
Is that an intentional change?

Do use 0xFF for the payload marker.
(In transports without a length indication, we could use 0xF0 etc. for a payload size indication later, using the same encoding for the second nibble as for the option length.  0xF as a length nibble then just means "indefinite length", i.e. until the end of the PDU.)

"Reserved for future use" does not mean anything with respect to packet processing rules.
-> MUST be sent as 0.  MUST be processed as an encoding error unless received as 0.  
(Again with s/0/15/ later).

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 28 Nov 2012 09:20:48 +0100

I've updated the text with the two changes (0xFF payload marker and
error unless reserved fields received as 0).

Carsten Bormann wrote:
> What happened to 8-byte Tokens? Is that an intentional change?

Instead of a 3-bit field for the token length (0-7) and reserve a bit,
we could alternatively use a 4-bit field and reserve lengths 9-15.

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Nov 2012 20:23:59 +0100

> we could alternatively use a 4-bit field and reserve lengths 9-15.

OK, for now I'll assume that is the proposal, because the current range (1-8 bytes explicit, 0 bytes default) was arrived at after quite some discussion and nobody has argued for changing the Token size in a long time.
(We still could, but this is simply an orthogonal discussion from the encoding change.)

** Editorial comments

This little snippet still has somewhat out-of-character Figure 1, which should be reverted to one that looks like most other header formats we use in the IETF.  (I know that it probably was a lot of work to come up with the ASCII art...)

(It also could use "Token (if present)" just to make sure that people understand a zero-length Token is a rather normal situation; we are just no longer making it "optional" because we no longer save a byte for the option header when not actually sending it.)

It might be useful to find a good place for a sentence such as
"The sequence of options is terminated either by the end of the message or by the Payload Marker".

I don't think 3.4 defines a "Payload Format".  (That comes after the Payload Marker and is described by the Content-Format.)
Instead, I think the Payload Marker could usefully be included in Figure 1.

s/with no payload and a zero-length payload./with no payload marker and a payload marker followed by a zero-length payload./
or so.

While we are at it, we might as well fix:

s/this and previous/this and all previous/

(All these editorial fixes can, of course, be done by the editors later, but it helps to work in parallel, and editorial clarity helps ensuring a consensus is genuine.)

** Discussion here are ETSI COAP2 interop

We have had some hallway discussions here today in the ETSI plugtest event.
ETSI plugtests are covered by an NDA, but I don't think I'm breaching that by saying that the reception I saw was unanimously non-negative*) and some participants even saw a chance to run some of the tests again during the week with the new encoding (yes, swapping out the encoding is that easy).

** WG chair hat on

While the code changes are trivial, making this late change would, again, break compatibility with all the tools already out there.
(You may not be aware that one may already be installed on your laptop...)
So if the feedback continues to be positive, I would like to make an explicit consensus call for this change soon.
This will not need a two-week period, 
Because it will be a short consensus call, you might want to answer it (or prepare an answer) right away.

Grüße, Carsten

*) not everybody cared, so I couldn't say "unanimously positive", but the average was perceptibly above zero.

---

From: Zach Shelby <[email-masked]>
Date: Wed, 28 Nov 2012 22:06:35 +0100

> Because it will be a short consensus call, you might want to answer it (or prepare an answer) right away.

And since coap-12 is only being interop tested right now, (right) now would be the right time to make such a small update in coap-13 and fix the issue for good. It will only get more painful to fix after a WGLC or during the IESG process.... I can already state that I am in favor of bringing this update into a quick coap-13 update, but would prefer that to be done already next week.

Zach

---

From: Jeroen Hoebeke <[email-masked]>
Date: Thu, 29 Nov 2012 12:12:47 +0100

> error unless reserved fields received as 0).

Section 3.4 of the improved message format says that the payload marker can be used even if the payload size is 0 bytes.
This leaves open the possibility to use this marker again as an end-of-options marker. Maybe the text should state explicitly that the marker must not be used if there is no payload (0 bytes) in order to have unambiguous messages.

Kind regards,
Jeroen

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Nov 2012 17:59:11 +0100

> ** Discussion here are ETSI COAP2 interop

A quick status update from Sophia Antipolis:
It took me exactly 30 minutes to move the coap.me code from coap-12 to the "Klaus encoding".
(16 minutes of code writing and 14 minutes of debugging.  Don't hire me as a programmer...)
We are now beginning the interop testing.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Nov 2012 10:13:51 +0100

> We are now beginning the interop testing.

I can report that the first three pairings of tests are already completed successfully, so far with no glitches at all.

While this is ongoing, another data point.

Klaus' encoding saves a byte when non-default tokens are present, and uses an additional byte for non-zero-length payloads.
(The other changes in efficiency are probably second-order.)

It depends on your traffic mix whether that is a net lose or a net win.
The corpus Klaus used for his original numbers might be more Token-heavy than others, so I tried to run a more representative test.

I used the pcap files from all the plugtest runs I personally participated in on Wednesday and Thursday.
That should be a good traffic mix, closer to what a mix of current implementations is going to do.

I tallied the sum of the message sizes and subtracted the sum of the sizes of the payload, taking the original coap-12 messages and the same messages converted into Klaus' encoding.
In other words, I have, for both encodings, a sum of the sizes of the header, the options, and (in case of Klaus' encoding) the payload marker.  
(I didn't want the actual payloads to be included, because they are often just "hello world" style messages during the plug test.  
So, relative to the total size of the packets, the increase will be smaller.)

The numbers:

total_klaus_net	108751
total_12_net	106287

This seems to indicate that, for this traffic mix, we buy the decrease in complexity by an increase of 2.3 % in header overhead.

Obviously, this is just one more data point.  
The ratio in sizes is quite stable when comparing Wednesday and Thursday (different test peers).
It may still be biased by properties of my implementation, both with respect to the traffic mix originated from my implementation during the plugtests and as a result of potential performance bugs in my Klaus encoder (although the latter is not very plausible).

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Nov 2012 12:36:19 +0100

On Nov 30, 2012, at 10:13, Carsten Bormann <[email-masked]> wrote:

> another data point

And one more: code size.

Jeroen Hoebeke reports about a quick experiment, where he isolated the relevant code and compiled it for x68_64:

> iot@ubuntu:~/coaptestcode$ size *.o
>    text	   data	    bss	    dec	    hex	filename
>     583	      0	      0	    583	    247	coapv12decode.o
>     638	      0	      0	    638	    27e	coapv12encode.o
>     642	      0	      0	    642	    282	coapv13decode.o
>     636	      0	      0	    636	    27c	coapv13encode.o
> 
> Not sure where the difference in the decoding comes from…
> 
> In code lines (the actual encoding, decoding without the data structures)
> DECODING
> 	v12 = 37 lines, new format = 43 lines
> ENCODING:
> 	v12 = 57 lines, new format = 42 lines
> 
> Overall impression: some small gain, the consistency between delta encoding and length encoding in the options makes implementation easier 

My own numbers (Ruby code with some copious diagnostics code, and including empty lines where required by the coding conventions):

parse_coap12 = 66 lines
parse_klaus = 53 lines

to_wire_coap12 = 67 lines
to_wire_klaus = 55 lines

I think we now have sufficient data to support the quantifiable part of the decision.
On the not so quantifiable side, it is hard to weigh "ease of implementation" and "reduction of interoperability bugs", which both argue for choosing the simpler design, against "running code" which, even with the three new implementations is still in favor of the existing one.

(Why am I running this so meticulously?  I'm personally way more interested in how people actually make a decision on a design issue such as this than in what the actual outcome is here.  Does more real data help or confuse?)

Grüße, Carsten

---

From: Jeroen Hoebeke <[email-masked]>
Date: Fri, 30 Nov 2012 14:12:38 +0100

Hi

I found some issues with the test decode/encode programs I (too) quickly created. Using a fixed version, this is now the result:

    723	      0	      0	    723	    2d3	coapv12decode.o
    634	      0	      0	    634	    27a	coapv13decode.o

    787	      0	      0	    787	    313	coapv12encode.o
    758	      0	      0	    758	    2f6	coapv13encode.o

In both cases a reduction in code size.
 
Kind regards,
jeroen

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 30 Nov 2012 14:48:00 +0100

I've created an updated version with the following technical changes
and a few editorial changes:

* Use a 4-bit field for the token length and reserve lengths 9-15.

* The payload marker must not be used if there is no payload (0 bytes).

Best regards,
Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Nov 2012 15:09:58 +0100

On Nov 30, 2012, at 14:48, Klaus Hartke <[email-masked]> wrote:

> <new-format-04.txt>

Thanks, Klaus.  
This version doesn't contain all the editorial fixes that were discussed on the list, but these can be done in parallel to making the decision.

Normally, we do minor technical decisions by having a discussion and then simply putting in the new text into the next revision of a WG draft.
However, this is another breaking change, and although the IETF process does allow us to make breaking changes as much as we want, reality doesn't -- we should only make them if the benefits really justify the cost of changing out all tools (including the WireShark that you probably already have installed even if you don't know it), temporarily partitioning the interop testing world into the laggards and the radicals, making previous pcap files less useful for future tests etc.

Other messages have discussed the quantifiable and not so quantifiable advantages (and disadvantages) of the new proposal.
I think I can already state consensus that the new proposal is simpler, which fits the goals of the WG well.

So my question to the WG is now:  Do we as a WG have consensus to make this change at this time?
Whether you answer yes or no, it would be useful to add a line or so of text indicating what motivates your decision.

In order not to lose time, please send in your replies (with this subject) to this mailing list by

	->  2012-12-05, 23:59 UTC.

This will enable us to announce a decision (and, I hope, get coap-13 published) right on Sinterklaas.

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 30 Nov 2012 16:54:09 +0000

> I think I can already state consensus that the new proposal is simpler, which fits the goals of the WG well.

I think we are still missing one very important datum on which to base
an informed decision, i.e. an estimate of how many CoAP devices *based
on -12* are really deployed in the real world (and by real world I
mean out of test labs) at present.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Nov 2012 18:22:05 +0100

> mean out of test labs) at present.

I believe for the purposes of this discussion we can act on the assumption the number is zero.

coap-12 was published October 1, 2012.  Today is November 30, 2012.
I know many people act fast, but not that fast.
(Of course, the technical details have been known a bit longer, but not much.)
(Deploying based on Internet-Drafts that haven't even been passed up to the IESG is reasonable only if you have a great update mechanism...)

No, it's not deployments I'm concerned about, but existing infrastructure on the development side.
One breaking change didn't seem to be too big a deal for the developers present in Vancouver (August 2012).
Another one four months later, maybe a bit more.  
But please answer from what you know about *your* environment, not by imagining what problems other people could have.
(They will, or at least should, speak up on their own...)

So, just as a template for potential input, let me give my personal view:
-- I won't have any problems with my own stuff.  New code already done (those 30 minutes).  I'll just need to set the date when I switch over coap.me.
-- New code for Copper has been done today, I hope Matthias has published it or will do so tomorrow.  
-- Wireshark will need another update.  Both the C language and the Lua dissectors probably will need a couple of weeks before they are available again in any new encodings; and you might have to recompile on your own (for the C version) before it trickles through to the next release.
-- IRISA will have to update their tool, too.  Sorry, guys...
-- I will have to collect a couple new pcaps to use as a corpus for further development.  Or write a converter (shudder).
-- (And then there is a little bit of editorial work still to be done on the spec.)
-- I will have to give lectures, write articles and books etc. about this, so I'd love to regain some simplicity.
-- There are always some detractors who will use this event as a demonstration that we are unstable, unreasonable, and irresponsible.  I think we can deal with them.

But your situation may be different, and I don't want to influence you here.

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 30 Nov 2012 18:21:48 +0000

Ok, so I'm strongly in favour of changing the option encoding to the
one proposed by Klaus -- modulo the *small* set of tweaks that the WG
has agreed on.

I'm concerned with easing the future adoption of CoAP rather than any
other consideration, and I think that a simple to implement spec is
key in this regard.