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

From: [email-masked]
Date: Thu, 17 Oct 2002 19:18:05 +0300

Hi,

I think one of the main questions about the data manipulation requirements is how to deal with lists. The choises made at this point may have a surprising impact on the usability aspects, as explained below.

In practice I think there are two scenarios:
1. Each application instance has its own dedicated list(s). For example presence lists and chat conference access lists are always separate entities in their respective servers. 
2. It is possible to share the same list stored somewhere in the "network" (i.e. represented by some URI) by multiple applications. If the list is changed, it is reflected in each application that the list is currently bound to.

These options don't change much the requirements for the list manipulation protocol. As seen in the current requirements draft, the list manipulation reqs for presence collection and presence authorization are basically identical.

From user's point of view there is a major difference. It would be nice to be able to use the same list for multiple purposes. In that case it would be better to have the list stored only once, so that there would be only one list to manipulate.

The biggest obstacle I see in this kind of generic list model is the application-specific URI schemes, in practice pres: and im:. If im: URI is added to some list and the user then wants to bind that list to a presence collection, there is a miss-match. On the other hand, lists comprising only sip: URIs would be usable accross different SIP services.  

I understand that some of this discusion is implementation related. I guess what I'm trying to say that I'd like the final solution be such that the general list concept would not be excluded. As technical requirement that should be quite easy to formulate, i.e. some form of indirection/binding between lists and SIP URIs is needed. If this is agreeable, I can propose some text to the draft.

Markus

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