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
> >
> 
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Oct 2002 16:13:08 -0400

inline.

[email-masked] wrote:
  > Hi,
  >
  > I think this would be a good time to see how to go forward with the
  > charter items related to data manipulation.
  >
  > I believe Jonathan is planning to update the Data Manipulation
  > Requirements draft <draft-rosenberg-simple-data-req> focusing on two
  > issues: 1. List management, and 2. Authrozation policy management. In
  > Yokohama the concensus was to take this draft as basis for WG
  > requirements, so maybe the next version could be taken as a WG draft.

Yes, that is the plan.

  > It is also a good proposal to limit that draft to purely
  > requirements, leaving the "model" in Chapter 4 out of scope. Maybe
  > then it would be easiear to agree on the draft.

Agreed.

  >
  > However, some kind of model/framework draft (similar to what is being
  > done in conferencing) is also needed, and eventually it is essential
  > to agree on what protocols to use.

Definitely. Requirements only make sense in the context of a framework.
The data manipulations draft has some frameworks in there. I have turned
it into a single framework, put up front, followed by a section for
requirements on each of the two components (buddy list manipulation and
authorization manipulation). I also added a terminology section.

  > My proposal is thus: 1. Use SOAP/WSDL for data manipulation. In the
  > first phase a definition is needed only for list and auth. policy
  > management, but the framework does not need to limit to this. 2. Use
  > SIP Events in a same fashion as "Message Waiting Indicator" draft to
  > convey notifications about state changes in the managed objects. A
  > collection package could be used for optimization purposes. This spec
  > could still leave the actual synchronization update mechanism open,
  > but I can imagine SyncML and others could potentially be usable
  > there. 3. Take SIP BIND as a default mechanism to make binding
  > between sip: URIs and SOAP http: URIs.

I agree completely on points 1 and 2, although as others have pointed
out, the scope of the document would not include making statements on
the specific protocol. Rather, it should defined the requiremetns for
the protocols.

  > I think we could have the first version of such framework draft could
  > be ready for the next IETF Atlanta meeting, and discussed there. Then
  > it could be updated and work on more specific drafts could start.

In fact, I have just submitted an updated version of the requirements 
document, as a SIMPLE work item. Until it appears in the archives, you 
can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-data-req-00.txt

there is now much more details on authorization requirements, based on 
comments and suggestions made on the list.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com