Re: [core] http observe unification

[Adam Roach <[e-mail]>]

On 10/29/10 3:48 PM, Cullen Jennings wrote:
> On Oct 28, 2010, at 6:43 AM, Peter Bigot wrote:
>> The clearly relevant one is draft-roach-sip-http-subscribe, but that's based on SIP event notification.  Were we to take that approach, it might be best to define a CoAP-like protocol "csip", rather than integrate that functionality directly into CoAP.  On first glance, it appears this would be at least as much work as defining CoAP has been.  It would, though, give us a solution to observation, notification, and group communication that is compatible with the HTTP family of protocols, so is certainly worth considering.
> I helped design the SIP Sub/Notify system and it's design goals were very different from what we are trying to do here. At a high level it is isomorphic to what we want but as you did into the details, it was optimized for something fairly different than the CoAP use cases. I'm certainly not pushing the approach that was used in SIP thought I tend to fall into using the terminology from SIP just because I know it well.

Oh, yeah, wow. You don't want to use SIP for this, unless you change 
what the "Co" stands for in "CoAP." You don't really even want to try to 
mirror its semantics into a CoAP-related protocol. One of the things I'm 
finding refreshing about CoAP at this stage of its life is that no one 
has started adding in giant arrays of nuclear-powered kitchen sinks. At 
least, not yet.

What we've done with SIP events is arbitrarily flexible, which is why 
it's used for everything from presence to dialog state monitoring, user 
agent configuration, and even certificate management. We've even seen 
proposals to use it to monitor automotive data in real-time. Really.

You don't need this.

Now, what's kind of nice about RFC 5989 (draft-roach-sip-http-subscribe 
was published as an RFC last night) is that it's a very simple use of 
SIP events. Just about any explicit observation model you come up with 
for CoAP should be able to interwork with RFC 5989 (at least, as long as 
you're using CoAP servers and HTTP clients -- I wouldn't want to try to 
make it go in the other direction, but I don't think that's on the table).

I really wouldn't focus on the semantics of the SIP events mechanism 
when you're designing CoAP observations, anyway. There are other ways to 
monitor for changes to a resource, such as PubSubHubbub, that are 
designed for certain niches.

In terms of a model that is simple, deployed, and works over UDP 
(well... and proprietary), you might look here for design inspiration: 
http://msdn.microsoft.com/en-us/library/aa143117%28EXCHG.65%29.aspx

/a