Subject: [core] Observe + ETag clarification

From: Thomas Fossati <[email-masked]>
Date: Mon, 13 Feb 2012 12:10:24 +0100

Observe-03 I-D, last paragraph of section 3.3 says:

"When the observed resource changes its state to a representation identified by one of the ETag Options, the server can send a 2.03 (Valid) notification instead of a 2.05 (Content) notification."

I don't get the use case for this: how is the client expected to guess in advance the ETag matching a future representation of the resource ?

I'm probably reading this the wrong way :-)

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 13 Feb 2012 20:15:50 +0100

> I don't get the use case for this: how is the client expected to guess in advance the ETag matching a future representation of the resource ?

A client can not guess future representations. But when it's observing
a resource, it receives representations from the server and can keep a
small set of them in its cache according to some cache algorithm (MRU,
LFU, ...). It can submit the entity-tags of these representations to
the server. Should the resource then change to one of these
representations, the server can simply select it from the client's
cache instead of sending a full response.

Does that make sense to you? If you have any suggestion how to improve
the text in section 3.3, please make it :-)

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Feb 2012 20:41:25 +0100

On Feb 13, 2012, at 12:10, Thomas Fossati wrote:

> use case

Adding to Klaus' explanation:

Imaging observing the resource description (/.well-known/core) of a device that actually loses and later again wins resources based on some state (e.g., whether some part of it has been manually switched on or off).  If the client observes (English sense) that toggling, it might offer both ETags, and the server will only need to 2.03 the right one.

Yes, maybe a bit esoteric, but it comes for free with the caching model, and you don't have to use it if it would create complexity in your implementation.   (Maybe this should be pointed out with an explicit MAY, but then this already follows from the rest of the spec, so it is not anything new.)

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 13 Feb 2012 21:23:50 +0100

On Feb 13, 2012, at 8:15 PM, Klaus Hartke wrote:
> Does that make sense to you?

Well, it really depends on the nature of the representations' set produced by the CoAP server for the observed resource: i.e. reps must be fat enough, and cardinality of the set must be very low to really take advantage of this mechanism.

> If you have any suggestion how to improve

A concrete use case -- something like the one cited by Carsten in this same thread -- would perhaps aid the reader who lacks a bit of imagination :-)