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

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

Hi Rohan,

I completely agree with you. My proposals about SOAP and BIND were there mainly to start the discussion and to show that in fact solutions already exist.

There seems to be agreement that initially we need some kind of simple list management protocol (ADD member, REMOVE member, MODIFY member), so that different lists associated to SIP services could be manipulated. I think the requirements for this are pretty well covered in the existing Data Manipulation Requirements draft. This could be built on top of whatever RPC mechanism.

Also, authorization management is chartered. In that case the scoping is more problematic. I think we could split the problem into two parts: general and service-specific. In the general part we should be able to define things like matching for list memberships or checking the day-of-time. These kind of IF-THEN-ELSE chains would lead to actual decisions, for which yes/no could be the general baseline. Services such as presence however need further service-specific semantics, for example the decision should describe what parts of the presence info to give to the requestor. Also, for conferences the decision may need to contain information about the granted rights. So, we should probably develop separate rules for presence and conferencing in addition to the general part.

Current Data Manipulation Requirements draft proposes to use a CPL-like scripting language for this, and the only manipulation operation would be a complete REWRITE. This is OK, but if possible I would like to see if it is possible to update only part of the information to save bandwidth.

So, what could we do before Atlanta? I guess the aim should be to finish the requirements draft and have a first version of "RPC-mechanism-independent" description of list management and authorization management protocols and their semantics. I understand this so that we define the commands/methods and their parameters, so that it is straightforward to map them to e.g. SOAP.

If this seems a reasonable idea, I can volunteer to write a first version of this kind of description for people to comment. 

Markus

> -----Original Message-----
> From: ext Rohan Mahy [mailto:[email-masked]]
> Sent: 30 September, 2002 19:25
> To: Isomaki Markus (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] The way forward in data manipulation work
> 
> 
> 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.
> > 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
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 1 Oct 2002 08:07:56 -0700

On Tuesday, October 1, 2002, at 02:21 AM, [email-masked] 
wrote:

> Hi Rohan,
>
> I completely agree with you. My proposals about SOAP and BIND were 
> there mainly to start the discussion and to show that in fact 
> solutions already exist.
>
> There seems to be agreement that initially we need some kind of simple 
> list management protocol (ADD member, REMOVE member, MODIFY member), 
> so that different lists associated to SIP services could be 
> manipulated. I think the requirements for this are pretty well covered 
> in the existing Data Manipulation Requirements draft. This could be 
> built on top of whatever RPC mechanism.
>
> Also, authorization management is chartered. In that case the scoping 
> is more problematic. I think we could split the problem into two 
> parts: general and service-specific. In the general part we should be 
> able to define things like matching for list memberships or checking 
> the day-of-time. These kind of IF-THEN-ELSE chains would lead to 
> actual decisions, for which yes/no could be the general baseline. 
> Services such as presence however need further service-specific 
> semantics, for example the decision should describe what parts of the 
> presence info to give to the requestor. Also, for conferences the 
> decision may need to contain information about the granted rights. So, 
> we should probably develop separate rules for presence and 
> conferencing in addition to the general part.
>
> Current Data Manipulation Requirements draft proposes to use a 
> CPL-like scripting language for this, and the only manipulation 
> operation would be a complete REWRITE. This is OK, but if possible I 
> would like to see if it is possible to update only part of the 
> information to save bandwidth.
>
> So, what could we do before Atlanta? I guess the aim should be to 
> finish the requirements draft and have a first version of 
> "RPC-mechanism-independent" description of list management and 
> authorization management protocols and their semantics. I understand 
> this so that we define the commands/methods and their parameters, so 
> that it is straightforward to map them to e.g. SOAP.

if you want to look at another document for an example of the 
semantics-only document, check out:

draft-taylor-midcom-semantics-00.txt

> If this seems a reasonable idea, I can volunteer to write a first 
> version of this kind of description for people to comment.

fantastic.  i look forward to reading it.

thanks,
-rohan