Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt

[Dean Willis <[e-mail]>]

On May 28, 2009, at 1:53 AM, Christer Holmberg wrote:
> ...

> So, the idea is to use the existing SIP SUB/NOT mechanism. The only
> "new" thing is to provide the conditions as part of the subscription.
>
> Third, I am not sure I would call it a configuration-delivery problem.
> Of course, the conditions can be said to "configure" the CBUS server,
> when it starts looking for matching URIs. But, the conditions can be
> unique for every subscription, so that is the reason why it is  
> proposed
> to deliver the subscription specific conditions as part of the
> subscription.
>

Ok, this is starting to make more sense to me. I suspect it's a case  
of SIP-for-light-bulbs, but that's OK with me; I liked the idea of  
controlling light bulbs using SIP to start with. We have a general- 
purpose rendezvous, messaging,  and pub/sub protocol here, and it  
seems silly to say it's only usable for phone calls. Of course, the  
same could be said for XMPP ;-).

How are these "conditions" you describe different from the "filters"  
of  RFC 4660?

 From RFC 4660's abstract:

> This document describes the operations a subscriber performs in  
> order to put filtering rules associated with a subscription to event  
> notification information in place. The handling, by the subscriber,  
> of responses to subscriptions carrying filtering rules and the  
> handling of notifications with filtering rules applied to them are  
> also described. Furthermore, the document conveys how the notifier  
> behaves when receiving such filtering rules and how a notification  
> is constructed.

Could the "conditions" requirement be met using RFC 4660? If so, we  
don't have a WG problem; we have an individual submission of a new  
informational-track event package.


--
Dean