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

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 27 May 2009 14:45:16 +0200

Hi,

I've submitted a draft which proposes SIP requirements for CBUS, based
on work ongoing in OMA.

(The most likely protocol output is going to be a new event package, and
some mechanism to provide conditions to the CBUS server).

The document can also be found in:

http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.t
xt

Regards,

Christer

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 May 2009 11:04:59 -0400

Reading this draft, I am wondering if this actually has anything to do 
with SIP?  (Other than the fact that OMA chose to work on it, and 
decided SIP was the right solution space.)

It appears that the client is looking for some "servers" (which may be 
people) which meet certain constraints.  I am as likely to want xmpp: 
URIs, or even HTTP: URIs, as SIP: URIs (should I say TEL:?) for the 
cases that I can imagine based on the example in the draft.

This seems an interesting general application.  Unless we really want to 
turn SIP into the next HTTP: (REST over HTTP as a general application 
infrastructure), I am slightly confused.

Yours,
Joel

Christer Holmberg wrote:
> http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.txt 
> <http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.txt> 
> 
> 
> Regards,
> 
> Christer
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 May 2009 11:03:26 -0600

I read this but I could not really figure out what it was about or  
what work it was proposing.

On May 27, 2009, at 6:45 AM, Christer Holmberg wrote:

>
> Hi,
>
> I've submitted a draft which proposes SIP requirements for CBUS,  
> based on work ongoing in OMA.
>
> (The most likely protocol output is going to be a new event package,  
> and some mechanism to provide conditions to the CBUS server).
>

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 27 May 2009 14:18:03 -0400

> and some mechanism to provide conditions to the CBUS server).

The document would have been significantly easier to understand had it
actually defined some of the several acronyms it used.

As far as I can tell, this describes (in very very general terms) a
framework for a particular application.  I don't see anything here that
motivates any new feature in the SIP protocol, or indeed any reason why
SIP is especially well suited to the application.

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 27 May 2009 17:55:25 -0400

> I've submitted a draft which proposes SIP requirements for CBUS, based

You're going to have to revise the Abstract:

   This specification defines CBUS requirements for the SIP interface
   between the CBUS Client and the CBUS server, based on the
   requirements in OMA.

I've been on the SIP mailing lists for several years, and I have
absolutely no idea what this is referring to (except the appearance of
"SIP").

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 27 May 2009 18:00:19 -0400

> http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.txt

As far as I can tell, the functionality is a pure request/response
protocol.  As there are quite a number of request/response protocols out
there, is it useful to embed this in SIP?

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 27 May 2009 18:33:07 -0500

> http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.txt

I confess to having lost touch with OMA and that may have contributed,  
but after reading the draft, I must say I don't get it.

It seems like some sort of configuration-delivery problem.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 28 May 2009 08:34:55 +0200

Hi,

>Reading this draft, I am wondering if this actually has 
>anything to do with SIP?  (Other than the fact that OMA chose 
>to work on it, and decided SIP was the right solution space.)

My assumption is that the most likely protocol output of this would be a
new SIP event package (used to transport the URI list), and some
mechanism to provide the conditions from the CBUS client to the CBUS
server (most likely as part of the subscription). However, in order to
follow the procedures I decided to start with requirements.

The CBUS enabler does contain more requirements than those listed in the
draft, but those are not related to SIP. The draft only contains the
requirements on the SIP interface between the CBUS client and CBUS
server.

>URIs, or even HTTP: URIs, as SIP: URIs (should I say TEL:?) 
>for the cases that I can imagine based on the example in the draft.

The client is not looking for servers. The client is looking for users,
which fulfills certain conditions.

>This seems an interesting general application.  Unless we 
>really want to turn SIP into the next HTTP: (REST over HTTP 
>as a general application infrastructure), I am slightly confused.

Event notifications is already we something have in SIP, so there is
nothing new there. The new thing would be that the subscriber, in
addition to only indicate which event he wants to describe also, also
indicate conditions.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 28 May 2009 08:53:10 +0200

Hi,

I will try to address the comments given by Dean, Cullen, Dale and
others in a single reply. Please let me know if I forgot something.

First, I didn't want to copy/past the whole OMA spec into the draft, but
if there are problems to understand what the proposal is about more text
will of course be added. I thought I had covered all the acronyms, but
that can of course also be fixed.

Second, as I said in another e-mail, my assumption is that the outcome
of this is (at least):

1. An event package in order to deliver the URI list
2. A mechanism to provide the conditions, which the server will use for
the evaluation

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.

Last, I don't agree to that the the functionality is a pure
request/response protocol. It is a sub/not functionaltiy: you may not
get the "response" (notification") immediately, and in some cases a
single subscription may trigger multiple notifications.

Regards,

Christer

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 28. toukokuuta 2009 2:33
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [dispatch] Draft: CBUS (Condition-based URI 
> Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
> 
> 
> I confess to having lost touch with OMA and that may have 
> contributed, but after reading the draft, I must say I don't get it.
>

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 28 May 2009 09:53:55 -0400

> "new" thing is to provide the conditions as part of the subscription.

What's new about that?  The target of a SUBSCRIBE is a URI, which can
include parameters.  Putting a body on a SUBSCRIBE request that further
extends those parameters is already allowed (eg RFC 5367), and a server
is free to use any part of a SUBSCRIBE request to determine whether or
not to create a subscription and what data to send in the resulting
NOTIFY messages.

Neither defining an event package for a particular application (which is
what this appears to be), nor defining how to communicate parameters in
the requests used by that application require any change to the
protocol.

While I'm sure this is interesting work, I don't see any reason why it
should consume IETF working group time - you'd spend almost all the time
educating other participants about the application requirements.  

I'd say go ahead and develop what you need, and if you think it would be
useful to publish the results as an Informational document there's no
reason not to do so as an individual submission.

Of course, if you find some prohibition or constraint in the existing
specifications that you think needs modifying, then that would be worth
IETF review.

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 May 2009 13:02:24 -0500

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

> to deliver the subscription specific conditions as part of the

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 28 May 2009 20:09:17 +0200

Hi, 

>What's new about that?  The target of a SUBSCRIBE is a URI, which can
include parameters. 

Correct. What I meant by "new" was that I wasn't sure we had existing
event packages where you actually provided additional input information
in the SUBSCRIBE request, but I may be wrong.

>Putting a body on a SUBSCRIBE request that further extends those
parameters is already allowed (eg RFC 5367), and a server is free to use
any part of a SUBSCRIBE request to determine whether or not to 
>create a subscription and what data to send in the resulting NOTIFY
messages.

Yes, but you need to define the parameters/bodies which are used to
carry the conditions, and you need to define the event package which
carries the URIs, and in order to do that you need requirements. That is
what this is all about.

>Neither defining an event package for a particular application (which
is what this appears to be), nor defining how to communicate parameters
in the requests used by that application require any change 
>to the protocol.

I am not proposing a change to the protocol. I am proposing requirements
for new SIP parameters/body and event package. I didn't talk about SIP
parameters etc in the document, since we are supposed to provide
requirements first. But, I guess I SHOULD say that the document
specifies requirements for new parameter, body and event package, in
order to make it more clear what it is all about.

should consume IETF working group time - you'd spend almost all the time
educating other participants about the application 
>requirements.  

So, where do you think the SIP parameters etc should be defined? I
thought IETF was the place to do that... 

Are you saying that OMA should do it on their own?

>I'd say go ahead and develop what you need, and if you think it would
be useful to publish the results as an Informational document there's no
reason not to do so as an individual submission.

I thought new SIP parameters, bodies and event packages required more
than an informational document.

I don't think there is anything in existing specifications that need to
be modified. I was thinking about whether using bodies in SUBSCRIBE
requests would cause some issues (assuming a body would be used to carry
the conditions), but you seem to indicate that it is already allowed...

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 28 May 2009 20:16:55 +0200

Hi, 

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