Subject: [core] Observe option in proxying: what to pool by?

From: Christian Amsüss <[email-masked]>
Date: Thu, 29 Jan 2015 15:05:38 +0100

Hello CoRE mailing list members,

as of implementing a CoAP proxy that can deal with observations (an
intermediary as described in draft-ietf-core-observe-16#section-5), I'm
unsure on what to pool client requests based on.

In particular, the line

> If two or more clients have registered their interest in a resource
> with an intermediary, the intermediary MUST register itself only once
> with the next hop[...]

troubles me, as it does not detail which connections to pool. It would
be logical, for example, to establish different observations when two
clients observe the resource with different Accept options -- but the
document talks only about "a resource".

My current approach would be to create a distinct observation based on
every request that has a cache-key for which no obervation is active,
discarding handled options like Observe from the cache-key before. Is
this behavior in line with the specification?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 29 Jan 2015 15:12:26 +0100

Hi Christian,

Christian Amsüss wrote:
> [...]

Yes, this is what the specification intends. See Section 3.1 [1]:

   A client
   MUST aggregate such requests and MUST NOT register more than once for
   the same target resource.  The target resource is identified by all
   options in the request that are part of the cache-key.  This
   includes, for example, the full request URI and the Accept Option.

Klaus

[1] https://tools.ietf.org/html/draft-ietf-core-observe-16#section-3.1

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 29 Jan 2015 22:00:06 +0100

Hello Klaus,

>    includes, for example, the full request URI and the Accept Option.

thank you for the hint, I missed looking this up in the client-side
part.

I'd suggest adding a cross-reference (a la "the intermediary MUST
register itself only once *per resource (as would any client per section
3.1)* with the next hop"), but given how far the spec is in the
specification process, and given it should be obvious to people who read
the whole spec, it should be alright.

best regards
Christian