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

["Christer Holmberg" <[e-mail]>]

Hi, 

>> 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 ;-).

I am not sure I would call it SIP-for-light-bulbs either, because you
aren't really "controlling" anything. You are simply providing input
information, which is used by the server to determine which URIs to send
back to you in notifications. But, whatever people want to call it :)

>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?

I will need to take a closer look at 4660. If it solves the
requirements, that's great.

>If so, we don't have a WG problem; we have an individual submission of
a new informational-track event package.

Ok.

Regards,

Christer