Subject: [Simple] A proposal for xcap direction

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 20:02:05 -0400

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

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

---

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

---

From: [email-masked]
Date: Wed, 16 Jul 2003 21:55:22 +0300

We need a solution for data manipulation soon, if this is what it takes to do it, then I say go for it.

I have some comments/questions inline...

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2003 3:02 AM
> To: Simple WG
> Subject: [Simple] A proposal for xcap direction
> 
> 
> Folks,
> 

This is a good point to remember even with XCAP 2.0. Designers and reviewers of schemas should keep that in mind.

> dictated or not important.

I'm confused. Are you talking about PUTting a document or an XML element? I thought the XML element is inserted in the location pointed to bu the XPATH expression.

> in. None of them are pretty. Its a limitation with the approach.

I thought option 3 was the server computed data. What is different?

> constraints that the schema cannot represent. Not sure its useful.

It might be useful. Cases are that you have 2 elements, both are optional, but at least one MUST exist. I don't think you can do that with schema.

> partial patches through some kind of webdav extension. This would be 

I fear that this might take longer than 1 year, maily due to the fact that we will have version 1.0 that everyone is deploying and are not interested in v2.0 for a while to come.

Regards,
Hisham