Re: [core] duration type comments

[Carsten Bormann <[e-mail]>]

On Aug 26, 2010, at 13:23, Peter Bigot wrote:

> Rather than spend a lot of time on this one:
> 
> 1. It is suggested that many options require a duration.  I could find only two: subscription-lifetime and max-age.  Before determining the encoding, the characteristics of these durations should be reviewed.  I suspect virtually every use of subscription-lifetime will be either "forever" or "stop".  What range of durations are reasonably expected for Max-Age for resources that reflect measurements of real-world data?

I don't have a scientifically grounded answer for that, but various discussions I have had so far indicate that 1 second to a couple of months is about the right range.

> 2. While we could select an encoding that supports only those durations we're thinking about now, I would prefer one that could handle other natural uses of duration, like "how long until a scheduled event".  For that use, a set of representable values that is not closed under subtraction is unsuitable.

It is always hard to design for unknown future requirements.
The duration type was indeed meant for soft-state/lifetime-like durations, not for anything approaching precise timing (there is no consideration of clock skew or leap seconds, for instance).

> 3. A detailed description of the subscription-lifetime option encoding in variable-length-integer format takes one third of a page in draft-hartke-coap-observe-02.  The pseudo-FP approach takes three pages to motivate and describe, plus five pages to list its values.  It's a nice solution, but any claim that this decreases complexity relative to variable-length-integer is indefensible.

This is a deliberately unfair statement.
I wrote expansive text, erring on the side of redundancy, when I noticed not every implementer has the CS background about number representations I would have expected.
A description of binary numbers at this level of detail would be about as long.
The actual description is five lines of C, four of which are constant definitions.

The reduced complexity comes from the reduced variability in length, not from a shorter description.
But maybe I'm the only one who sees that advantage.

> 4. I'm not going to bother to implement this right now to see how much space it takes, but if we continue to create novel encodings that require, for example, three times as much ROM as a comparable straightforward encoding, CoAP will be unimplementable on the very devices where it's most needed.

The implementation is in the draft.

I think the meta-observation here is that the technical advantages or disadvantages are mostly irrelevant where people are significantly more familiar with one way of doing things than with another way.  I do think that is an important consideration in protocol design.  I just wasn't prepared for such a reaction in this case.  (This is not about you, others had the same reaction.)  I'm willing to learn.

Gruesse, Carsten