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

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

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

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

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

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.

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

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

> 
> 3. We may be able to keep the ability to have servers enforce data 
> 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.

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

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

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jul 2003 16:34:42 -0400

It seems that people are supportive of this direction, so I am going 
to go ahead and start working on an xcap revision which works along 
these lines. I'll send a separate note on how to approach xpath.

some responses inline:

[email-masked] wrote:

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

PUT would allow you to put either a document or an XML element.

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

Whats different is that the POST request contained the XML elements 
without the server-provided URI, and the POST response contained the 
filled-in URI. In the proposed approach, the server is just a 
repository. If you PUT the document without the URI, there is no URI. 
A separate application (which could be implemented ontop of the xcap 
server) would watch for the PUT. When it sees it, it goes and does a 
PUT of its own, adding the URI. To find out the assigned uri, the 
client needs to either poll or use the xcap package once the change is 
made.

> 
> 
> 
>> 3. We may be able to keep the ability to have servers enforce
>> data 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.

Yeah, I dont think we can do that with schema. But, I'm not sure we 
have that case now.

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

Well, thats OK then. If the v1.0 solution solves everyones problems 
with minimal complexity, that sounds good in my book.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jul 2003 16:34:42 -0400

some responses inline:

-Jonathan R.