Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count and length limitations

From: "Kovatsch Matthias" <[email-masked]>
Date: Mon, 26 Mar 2012 17:20:43 +0000

> 1 -- removing the 270 limit, enabling us to fix long Uri-Proxy values.

Sounds good.

> 2 -- going back to the drawing board on the message format to solve a problem you don't state (except that you are "unhappy").

The only reason not to do it can see is legacy. But this is a draft, there should not be any legacy.
During the Plugtests there was no issue parsing the bit-fields of the headers, as it is trivial. I do not know how many implementations would have had support for more than 15 options, but it was not tested anyway. Updates to draft-09 will need to change their OC handling, so changing the header handling will not be that painful. So no loss there.
With the current two-fold handling more code is required for the unified length handling and the current design is one of those where future generations will ask "why?!"

Ciao
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Mar 2012 19:34:46 +0200

> The only reason not to do it can see is legacy. But this is a draft, there should not be any legacy.

There is not a single point in time where the cost of making changes suddenly increases from zero to infinite.
This is a gradual process.  We are pretty advanced on this curve already.
Most of CoAP has been stable since -06, and we have been tweaking minor points since.

We are way beyond the place where making gratuitous changes would be justifiable.

Every single change has a cost and a benefit.  This change (what I called 2) has a high cost (everybody has to change their implementation and we have to re-test, and we are likely to have a transition period in which there are both versions as we had with coap-03 and coap-06).  I happen to believe the actual benefits are negative, as well, but even if they were positive, we'd have to have a good reason now.

1 is a change with very small cost (the majority of cases will still interoperate).  Let's find out whether it is the best way to do this and then agree to do it.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Mon, 26 Mar 2012 21:02:14 +0000

> We are way beyond the place where making gratuitous changes would be

Okay. Maybe we can then at least change to always using the option terminator and make use of the 4 OC bits. Even if it is only reserving them for new versions.

Matthias