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

From: Cullen Jennings <[email-masked]>
Date: Sat, 09 Aug 2003 12:02:26 -0700

I'm supportive of this direction.

I think this will also bring xcap server into the scope where it could be
implemented inside a typical web server framework. This would be a very
*good* thing because the practical issues of deploying secure servers that
allow document manipulation from the general internet has turned out to be
quite challenging. 

So, if the proposal turns out that XCAP 1.0 can be done in a typical web
server, and XCAP 2.0 can be done in a webdav server - I would see that as
nice from a getting it implemented point of view.

Cullen

On 7/21/03 13:34, "Jonathan Rosenberg" <[email-masked]> wrote:

> 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:
> 
> 
>>> 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.
> 
> 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.
>> 
>> 
>> I thought option 3 was the server computed data. What is different?
> 
> 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.

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

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 09 Aug 2003 12:02:26 -0700

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Aug 2003 23:46:06 -0400

> I'm supportive of this direction.

Thanks.

> allow document manipulation from the general internet has turned out to be

Agreed. That was the idea all along - its just a servlet or something 
within any web server, with some xpath code along with it.

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, 11 Aug 2003 23:46:06 -0400

Thanks.

Thanks,
Jonathan R.