Subject: RE: [Simple] The way forward in data manipulation work

From: [email-masked]
Date: Tue, 1 Oct 2002 12:36:34 +0300

Hi,

Here are some use cases (i.e. requirements) I have for the SIP URI - generic URI binding solution:

- A user must be able to create dynamically new service/AoR instances. These include conferences, presence lists, IM delivery lists and any other SIP services. I assume some RPC-mechanism instead of SIP will be used for the CREATE operation. So, the user must be able to discover the (generic) URI where to send such commands. I'm not sure if this is in the scope of BIND at all, since neither SIP nor the generic URI exist yet. But, I would be happy with the solution where user could query such generic URIs using her own AoR or the domain name as the starting point. (I.e. give me the addresses of the interfaces related to this AoR or this domain.). Local service discovery mechanisms won't work for this, since the user might not be (in IP-topology) in her "home" network.

- A user must be able to bind and manage objects (lists, authorization policies) related to any SIP AoR hosting an appropriate service. These services include presence (auth. policy, using matching against list memberships), presence lists (the list itself), IM delivery lists (the list itself), conferences (whatever conf. or media policies or even foor control) and any other similar ones. Binding header in BIND or OPTIONS (or INVITE) would be a sufficient solution.  

Markus

> -----Original Message-----
> From: ext Rohan Mahy [mailto:[email-masked]]
> Sent: 30 September, 2002 22:32
> To: Henning Schulzrinne
> Cc: Sean Olson; Isomaki Markus (NRC/Helsinki);
> [email-masked]
> Subject: Re: [Simple] The way forward in data manipulation work
> 
> 
> 
> On Monday, September 30, 2002, at 11:03 AM, Henning Schulzrinne wrote:
> 
> > We have discussed this before, but I still fail to see how 
> you can, in 
> > general,
> 
> "in general"
> 
> well, that's the disagreement. In all the specific motivating 
> scenarios 
> for SIP BIND, there has been another very reasonable way to 
> map between 
> the SIP and non-SIP URIs. I'm not convinced that a general 
> solution is 
> needed (the requirements don't bear that out IMO).
> 
> thanks,
> -rohan
> 
> 
> > deduce from a SIP URL what the corresponding non-SIP URL 
> is. In many 
> > cases, you will have other means to establish the binding 
> (e.g., one 
> > could consider the various *-Info headers an example of such a 
> > binding), but these means tend to be within a dialog or for a 
> > particular request.
> >
> > Sean Olson wrote:
> >> I would also like to see some consideration
> >> of the impacts of binding SIP to HTTP. I'm not
> >> at all convinced that BIND is the way to go
> >> for this. Assuming we want an RPC mechanism
> >> for this task (a big assumption), what is the
> >> requirement for correlating the data manipulation
> >> mechanism with SIP? Is this not implied by the
> >> data being manipulated?
> >> /sean
> >
> 
>