Subject: RE: [Simple] A proposal for xcap direction

From: [email-masked]
Date: Wed, 16 Jul 2003 18:35:04 +0300

Hi,

I also think that this direction seems reasonable. Partial updates are important, but it is enough to be able to just divide the whole data into reasonably small chunks which could be individually updated. I also believe that the XML schema can be designed so that the typical updates that need to be atomic can be reasonably small.

Also the timing of this work is very important. It would be good to get the basic XCAP specs not too long after PUBLISH and MSRP, so that the first _standards based_ SIP IM & Presence solutions could also use standardized data manipulation. For instance I don't believe that it would make sense to put SIP IM & P in the wireless terminals (for "mass market") before XCAP gets to RFC.

Another comment I have is that we could still at least TRY to simplify the baseline solution for presence authorization. Hopefully the most complex rules could be left as optional extensions. 

Markus 

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: 16 July, 2003 12:05
> To: Jonathan Rosenberg
> Cc: Simple WG
> Subject: Re: [Simple] A proposal for xcap direction
> 
> 
> I'm all for minimal functionality and a single mechanism.
> 
> Since we only need a small subset of the functionality of XPath 
> functionality, it seems easier to just have atomic units as 
> part of the 
> path. This also avoids having to worry about micro-manipulation of 
> individual elements and simplifies server implementation. In 
> the simpler 
> implementation, you can simply have an XML parser for each unit and 
> store it internally as a database or some other more 
> appropriate format. 
> If you allow random element-level modification, you have to 
> keep the DOM 
> representation around and have to make sure that things that can't 
> easily be modified in one step are consistent and valid in 
> intermediate 
> steps.
> 
> Jonathan Rosenberg wrote:
> 
> > Folks,
> > 
> > During the IETF meeting, I put forward a strawman proposal on a 
> > direction for xcap. The strawman is motivated by some important 
> > observations:
> > 
> > 1. If xcap is anything except for an obvious http usage, it 
> will require 
> > broader ietf input. Such input, through a design team, for example, 
> > would probably add a year (plus or minus 6 months) to the work.
> > 
> > 2. Whats REALLY important to us is the schema - how we are 
> representing 
> > authorization policies and buddy lists. How such data is 
> transported 
> > from a client to the server is less important to us. Its 
> also not really 
> > our core competency.
> > 
> > Based on this, I would propose a substantial descoping of XCAP. In 
> > particular, I would propose that:
> > 
> > 1. We do not address batching or transactions. That is, you 
> won't be 
> > able to lock a list or auth policy, make a bunch of 
> modifications, and 
> > then unlock. Is this a fatal loss of functionality? No. It 
> turns out 
> > that if you are careful about how you design the schema, 
> you will be 
> > able to ensure that most of the things you want to do can 
> be done with a 
> > single GET/modify/PUT operation.
> > 
> > Here's an example.
> > 
> > One of the big concerns we had was moving a user from a 
> white list to a 
> > black list. That requires two steps - (1) remove the user 
> from the white 
> > list, and then (2) add the user to the black list. There is an 
> > intermediate state thats bad - the user is on neither list. 
> This concern 
> > is based on the assumption that the authorization policy is 
> structured 
> > as white and black lists. If you look at the xcap 
> authorization usage, 
> > you find thats not true. Its structured (basically) as a list of 
> > watchers, and for each one, permissions for that watcher. 
> To achieve the 
> > effect of moving the user from a while list to a black 
> list, you would 
> > delete the <accept> permission for that user. This 
> operation can be done 
> > in a single DELETE operation. Thus, no locking is needed.
> > 
> > In fact, I was careful in the construction of the 
> authorization schema 
> > to make sure that most of what I think we need to do is 
> doable in one 
> > shot operations. I accomplished this by making the 
> authorization policy 
> > structured as a list of statements, where each statement 
> applies to one 
> > or more watchers. Each statement is a list of permissions, 
> which grants 
> > the ability to get or receive something. Permissions are 
> positive - they 
> > always grant something, never deny something. Its the mix 
> of positive 
> > and negative things which requires two-step operations to ensure 
> > consistency, and I avoided them.
> > 
> > 2. Every operation is a PUT. No POST. The IETF has established 
> > guidelines for usage of HTTP as a substrate for other 
> protocols. One of 
> > the tell-tale signs of misuse is that you are using POST as 
> a way to 
> > tunnel operations. POST has a well defined semantic - you 
> are sending 
> > form data to a process that uses the data as input. In the 
> current xcap 
> > draft, the POST operation is used to insert a new element, 
> whereas PUT 
> > is used to modify an existing one. We need to only use PUT, 
> since there 
> > really is no form processing engine here. However, we still need an 
> > insert and a modify operation. How to do that?
> > 
> > Well, the proposed direction gives us the answer. How does 
> HTTP support 
> > it? Simple. If you PUT a document to a URI that represents 
> a resource 
> > that exists, the resource is replaced. If you PUT a 
> document to a URI 
> > that doesnt exist, the resource is created (i.e., 
> inserted). Now, our 
> > main problem is that there is no way to specify WHERE the 
> new resource 
> > gets inserted within the "directory". For regular 
> filesystems, it doesnt 
> > matter. For us, it does. So, we will have a constraint that 
> if you do an 
> > insert operation on an XML element, you have to do it in a 
> place where 
> > either (1) the positioning is implied by the schema, or (2) the 
> > positioning isnt important. Again, this just means careful schema 
> > design. You will note that in both the authorization usage 
> and buddy 
> > list usage, there are many key points in the schema where 
> you can insert 
> > things where either the ordering is dictated or not important.
> > 
> > 3. We remove the ability to have server computed data (not 
> possible with 
> > PUT). That means that creating a buddy list requires the client to 
> > either (1) select the URI so its unique, (2) obtain the URI 
> through some 
> > other means, (3) put the data without a URI, have the 
> server set the 
> > URI, and then have the client fetch the data with the URI 
> filled in. 
> > None of them are pretty. Its a limitation with the approach.
> > 
> > 3. We may be able to keep the ability to have servers enforce data 
> > constraints that the schema cannot represent. Not sure its useful.
> > 
> > 4. We pursue a longer term solution of working with webdav 
> by adding 
> > partial patches through some kind of webdav extension. This 
> would be 
> > xcap 2.0.
> > 
> > 
> > 
> > During the meeting, there was good support for this. Ted 
> gave some good 
> > input. His idea was to take it a step furhter and eliminate 
> xpath. The 
> > suggestion was to obtain partial updates by treating each 
> buddy or each 
> > watcher permission as a separate http resource. This amounts to 
> > declaring specific "breakpoints" in the current schemas 
> which represent 
> > the atomic units we will operate on. I need to mull that 
> over some more 
> > to see if it works. More on that when I have a concrete 
> opinion on it.
> > 
> > However, I did want to solicit input from the working group 
> on the list 
> > about this direction. So, please comment or ask questions.
> > 
> > Thanks,
> > Jonathan R.
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jul 2003 17:08:01 -0400

inline.

[email-masked] wrote:

> Also the timing of this work is very important. It would be good to
> get the basic XCAP specs not too long after PUBLISH and MSRP, so
> that the first _standards based_ SIP IM & Presence solutions could
> also use standardized data manipulation. For instance I don't
> believe that it would make sense to put SIP IM & P in the wireless
> terminals (for "mass market") before XCAP gets to RFC.

I agree. We have a pressing need to finish publish, xcap, xcap buddy 
list, xcap auth, rpids, and message sessions. I believe that 
xcap-package, filtering, and partial notifications are important but 
are not as critical. As such, I think we should seriously consider 
de-scoping and simplification wherever possible to accelerate stuff.

> 
> Another comment I have is that we could still at least TRY to
> simplify the baseline solution for presence authorization.
> Hopefully the most complex rules could be left as optional
> extensions.

I agree. I would suggest removing the following things:

* the accept-if conditions related to filters (requested-namespace, 
requested-element, requested-tuple).

* I could be convinced to remove accept-if altogether. I do think that 
accepting subscriptions based on durations (to allow only fetches), is 
pretty useful. Other opinions?

* we could remove the rule-permissions altogether. This would get 
around most of the complexities of naming and addressing of XML elements.

* I think we still need content-permissions. We could descope 
show-element so that you can only give permission by element name, not 
  by xpath expression. What do we lose if we do this? If a presence 
doc has two tuples, and you wanted to allow a watcher to see 
"placetype" in one, but not the other, you couldnt do it. you could 
only allow or disallow "placetype"  for any tuple. I think thats OK 
for the first version.

* We could remove show-values, as it also requires xpath.

* I think we still need transformational attributes. I would recommend 
that "set-element" and "change-value-from" would specify the element 
by element-name (i.e., "placetype"), and would impact all instances of 
that element within the presence document.

What do people think of this scope reduction?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jul 2003 17:08:01 -0400

inline.

Thanks,
Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Jul 2003 20:29:08 -0400

> pretty useful. Other opinions?

Unless you restrict the number of times that somebody can subscribe each 
hour, why wouldn't that just be encouraging polling instead of event 
delivery?

>  by xpath expression. What do we lose if we do this? If a presence doc 
> has two tuples, and you wanted to allow a watcher to see "placetype" in 
> one, but not the other, you couldnt do it. you could only allow or 
> disallow "placetype"  for any tuple. I think thats OK for the first 
> version.

Agreed. I'm having a hard time coming up with a use case where this is 
truly required. Dis-allowing certain values for certain subscribers is 
probably more useful, albeit marginally. ("Don't show boss if my body 
monitor registers me in sleeping state.") Your last item addresses that.

> that "set-element" and "change-value-from" would specify the element by 
> element-name (i.e., "placetype"), and would impact all instances of that 
> element within the presence document.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Jul 2003 20:29:08 -0400