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

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

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.

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

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