Is the presence data sent as representation of the /oc/presence resource?
Then it would make sense to use the Max-Age option is intended: to specify for
how long the representation is valid ("fresh").
Regards
Matthias
> -----Original Message-----
> From: ???(Uze Choi) [mailto:uzchoi at samsung.com]
> Sent: Montag, 20. April 2015 19:52
> To: 'Lankswert, Patrick'; 'Carsten Bormann'
> Cc: junghyun.oh at samsung.com; 'Samidurai, Sakthivel'; 'Kesavan, Vijay S';
> Kovatsch Matthias; '???'; iotivity-dev at lists.iotivity.org
> Subject: RE: [dev] [Multicast presence Issue raise] FW: Inquire about base C
> API for multicast presence
>
> Oh. We have presence logic already.
> By extending this presence logic, we can realized the health check feature
> also.
> Currently, there is no mechanism for the client to specifying the TTL when
> notify back.
>
> Anyway, regarding the additional resource which handle the different logic, I
> have a negative opinion.
> Our common (virtual) resource need to be aligned to CoAP specification at
> least.
>
> BR, Uze Choi
> -----Original Message-----
> From: Lankswert, Patrick [mailto:patrick.lankswert at intel.com]
> Sent: Friday, April 17, 2015 11:17 PM
> To: Carsten Bormann; "???(Uze Choi)"
> Cc: junghyun.oh at samsung.com; Samidurai, Sakthivel; Kesavan, Vijay S;
> kovatsch at inf.ethz.ch; ???; iotivity-dev at lists.iotivity.org
> Subject: RE: [dev] [Multicast presence Issue raise] FW: Inquire about base C
> API for multicast presence
>
> Carsten and Uze,
>
> > -----Original Message-----
> > From: Carsten Bormann [mailto:cabo at tzi.org]
> > Sent: Friday, April 17, 2015 4:23 AM
> > To: "???(Uze Choi)"
> > Cc: junghyun.oh at samsung.com; Samidurai, Sakthivel; Kesavan, Vijay S;
> > Lankswert, Patrick; kovatsch at inf.ethz.ch; ???; iotivity-
> > dev at lists.iotivity.org
> > Subject: Re: [dev] [Multicast presence Issue raise] FW: Inquire about
> > base C API for multicast presence
> >
> > ???(Uze Choi) wrote:
> > > There is already draft for this in Conditional observe in CoAP.
> > > https://tools.ietf.org/html/draft-li-core-conditional-observe-02
> > >
> > > How about to implement it into the IoTivity. This will enable
> > > various usecases.
>
> How would you use conditional observe in conjunction with presence?
>
> Carsten: Presence is a "push" discovery mechanism. So that devices can
> notify the network when they become available to the network.
>
> > Hi Uze,
> >
> > several proposals have been made over the past couple of years for
> > options that would inform the server about more detailed client
> > requirements for an observation relationship. None of these gained
> traction.
> >
> > I think the main reason for this was that those details are often very
> > application specific, and it is hard to generalize them into a small
> > number of widely applicable options.
>
> My original reaction to the parameterized or conditional observation was the
> same. That is, these are largely application specific behaviors and covering
> all
> of the possible use cases would require pulling in an implementation or LUA
> into the stack. This idea that a resource should have more and more bells and
> whistles makes the model more and more complex. I would rather have
> additional resource types that help in these cases to keep basic functionality
> separate from this robust functionality.
>
> In this world, like an adapter pattern, a logical resource is bound to another
> resource to express the representation that a client of group of clients
> desires.
>
> For example:
> "Physical" Resource: Temperature Sensor, /temp, rt='com.example.temp',
> if='s.temp'
> "Logical" Resource: Hot/Cold, /comfort, rt='com.example.comfort',
> if="com.example.logical"...
>
> The logical resource could be created by clients (or magically by servers) and
> bound to the temperature resource with the criteria.
> The logical resource is re-useable by multiple clients who are interested in
> the same criteria.
> The logical and physical resource can be on the same or different servers
> based on device resources available.
> However, the most important part to me is that the logic for all the
> conditional logic is handle by the logical resource implementation and not by
> the CoAP (or HTTP) stack.
>
> Does that make sense?
>
> > One obvious way to supply additional information is adding query
> > parameters. What details are supplied can then be controlled by the
> > application. (The next question, of course, is how the client finds
> > out about these options -- but that is just an instance of link
> > discovery.)
>
> This is workable also. As you say the availability of additional query
> parameters could be expressed via the interface, or said another way,
> expressed as part of the function set definition during link discovery.
>
> > Now I haven't read the entire thread yet so I don't know how this
> > aspect relates to the "multicast" in the subject. Will find out later...
> >
> > Gr??e, Carsten
