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

From: [email-masked]
Date: Wed, 25 Sep 2002 16:49:56 +0300

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

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. Based on usage guidelines SIP does not seem to meet the requirements. The current PUBLISH proposal is too simplistic to be useful in many cases. Instead, some kind of more flexible RPC mechanism with some support to synchronization seems to be the best choise.

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.

In my opinion the framework doc. should define the terminology, have a few nice ascii-drawings and describe the model and the actors within points 1-3 above. Also, it should tell how to specify management interfaces for specific objects, and how to achieve the synchronization. In addition more specific documents would be needed for "list management", "authorization policy management" and "synchronization event package".

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. 

But before starting anything like this, I would like to get people's opinion about the technical part, and of course chairs' opinion about the process. I'm sure there are plenty of other approaches, but I haven't heard any proposals so far. In any case, some kind of design team around this matter might be a good idea.

Regards,
	Markus

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 30 Sep 2002 09:24:46 -0700

Hi Markus,

Not everyone is going to immediately have the same conclusion about 
SOAP.  In order to avoid the syntax wars, I suggest that we focus on 
the semantics of the kind of RPC mechanism we will need. Once we have 
debated the semantics, we can then have the syntax discussion.  Folks 
can then propose alternate SOAP and non-SOAP syntax that conveys the 
agreed-upon semantics.

Also, as I said at the mic in Yokohama, I'm not convinced that we need 
a SIP BIND method. Let's make sure we have a good semantic description 
of the binding relationship between SIP and data before we cast a 
mechanism on stone.

thanks,
-rohan

On Wednesday, September 25, 2002, at 06:49 AM, [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. 
> 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.
>
> 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. Based on usage guidelines SIP does 
> not seem to meet the requirements. The current PUBLISH proposal is too 
> simplistic to be useful in many cases. Instead, some kind of more 
> flexible RPC mechanism with some support to synchronization seems to 
> be the best choise.
>
> 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.
> In my opinion the framework doc. should define the terminology, have a 
> few nice ascii-drawings and describe the model and the actors within 
> points 1-3 above. Also, it should tell how to specify management 
> interfaces for specific objects, and how to achieve the 
> synchronization. In addition more specific documents would be needed 
> for "list management", "authorization policy management" and 
> "synchronization event package".
>
> 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.
>
> But before starting anything like this, I would like to get people's 
> opinion about the technical part, and of course chairs' opinion about 
> the process. I'm sure there are plenty of other approaches, but I 
> haven't heard any proposals so far. In any case, some kind of design 
> team around this matter might be a good idea.
>
> Regards,
> 	Markus
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Sean Olson <[email-masked]>
Date: Mon, 30 Sep 2002 10:43:12 -0700 (PDT)

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

--- Rohan Mahy <[email-masked]> wrote:
> > Requirements draft
> <draft-rosenberg-simple-data-req> focusing on two 
> > 3. Take SIP BIND as a default mechanism to make
> binding between sip: 
> > URIs and SOAP http: URIs.
> >

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Sep 2002 14:03:24 -0400

We have discussed this before, but I still fail to see how you can, in 
general, 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.

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 30 Sep 2002 12:31:58 -0700

On Monday, September 30, 2002, at 11:03 AM, Henning Schulzrinne wrote:

> 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:
>> for this. Assuming we want an RPC mechanism

---

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

inline.

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

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

  > 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