Subject: [Simple] xcap issue 3: PUT v. POST

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 May 2004 01:50:29 -0400

Without a doubt, the biggest open issue in xcap today is PUT vs. POST. 
That is, when modifying a document, either by inserting a new element or 
attribute or modifying an existing element or attribute, do we use POST 
or PUT?

The current spec says PUT. However, a few stresses (as Ted has put it) 
have surfaced around this:

1. in some cases, the server needs to modify the document (for example, 
by adding a unique URI for somethign like a buddy list). I modeled this 
as, instead of having the server actually modify the document, there is 
a separate application that modifies it after the document is written. 
There is a lot of ugliness with that approach. The client has to poll to 
find out the URI that is assigned, and the etags will change. Its also 
hard to implement.

2. The place where the document is inserted is schema dependent; that 
is, there is a bit of magic going on in how the server determines where 
to place the content.

3. THe server can reject the PUT request if it doesnt like the content 
for some reason - it causes the document to be invalid, or uses a URI 
that exists in the system. As such, its not just a blind "write this 
here" operation.

So, we have two options. We can either address the above things, to make 
PUT an appropriate method here, else use POST. I am very hesitant to use 
POST because it really then means that we are really using HTTP as a 
tunnel for some other protocol, and that has a whole bunch of problems 
associated with it.

So, here are my proposals for addressing the above three concerns.

First, as I have proposed already on the list, I would remove, from 
xcap, any notion of the servers filling in the document or doing things 
like assigning URIs. If we need a URI assignment service, lets have that 
execute separately. THe client would issue some command (not xcap) to 
get a URI, and once it has it, it would do an XCAP opeartion to write 
the whole document, including the URI, to the server. With such a 
change, things operate much more cleanly. There is no need for polling 
to find out the assigned URI, it would be provided in the response to 
the assignment request. There is no phantom application that modifies 
data. The response to the PUT operation truly indicates whether the 
operation succeeded or failed.

Secondly, I have proposed in another thread that the server perform 
insertions without requiring it to understand the schema. That is, the 
insertion process is completely deterministic and there are no 
schema-specific behaviors. This change addresses the second problem above.

In regards to the third, we *could* have xcap skip any notion of 
validation at all - no XML well-formedness, no schema validation, no 
nothing. In such a case, its a clear "write this here" operation that 
maps to PUT. However, I believe this is not useful for us. Xcap is, at 
the end of the day, a means for user self-provisioning, and I believe 
that data validation is a key component of any provisioning process. 
Thus, I believe we need to be able to reject a request to modify a 
document if the result violates some kind of data constraint.

However, just because the server does such validation, does not mean 
that the operation is no longer a pure PUT. HTTP does envision that PUT 
requests can be validated before doing them. I point to section 10.4.10 
of HTTP 2616, which defines the 409 code:

10.4.10 409 Conflict

    The request could not be completed due to a conflict with the current
    state of the resource. This code is only allowed in situations where
    it is expected that the user might be able to resolve the conflict
    and resubmit the request. The response body SHOULD include enough

Fielding, et al.            Standards Track                    [Page 67]

RFC 2616                        HTTP/1.1                       June 1999

    information for the user to recognize the source of the conflict.
    Ideally, the response entity would include enough information for the
    user or user agent to fix the problem; however, that might not be
    possible and is not required.

    Conflicts are most likely to occur in response to a PUT request. For
    example, if versioning were being used and the entity being PUT
    included changes to a resource which conflict with those made by an
    earlier (third-party) request, the server might use the 409 response
    to indicate that it can't complete the request. In this case, the
    response entity would likely contain a list of the differences
    between the two versions in a format defined by the response 
Content-Type.

I think this clearly says that validation is just fine; almost by 
definition, a validation failure is because there is a conflict with the 
current set of data.

So, I would propose that we make the two changes I have suggested (using 
a separate method for allocating URI, and avoiding schema-specific 
insertion semantics), and retain PUT. In this way, the actual 
modification operation (through PUT) succeeds or doesn't, and what it 
does is well defined. However, the logic which determines whether it 
succeeds or not can be complex, including but not limited to schema 
validation.

Do folks agree?

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: Mon, 10 May 2004 12:54:20 +0300

Some comments inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 10.May.2004 08:50
> To: Simple WG
> Subject: [Simple] xcap issue 3: PUT v. POST
> 
> 

I'm fine with all that, but what would that command be? and what protocol for use? It would be great if we can utilise HTTP GET.

>From the top of my head, here is a proposal (it requires some more thinking):

The server would have a pool of URIs that it creates and places (as an xcap document if you wish) on the server. Something like:

<uris>
  <uri>sip:[email-masked]</uri>
  <uri>sip:[email-masked]</uri>
  <uri>sip:[email-masked]</uri>
  <uri>sip:[email-masked]</uri>
</uris>

We need to define a schema for this or reuse parts of the event list schema.

The client would then do a GET always asking for the first uri

GET http://server/xcap-root/document/uri[1]

Once the server has assigned that URI, it then removes it from the list of available URIs. The next client then would again ask for the first URI on the list. It is possible that the list of URIs is not physically on the server and the server creates them dynamically. But from the client point of view, it is just asking for the URI on the top of the list.

We also need to distinguish somehow between, for example, a GET for a list URI and a GET for a conference URI. This can be done using the request URI in the GET:

http://xcap.example.com/services/presence-lists/global/URIs for list URIs and

http://xcap.example.com/services/conferences/global/URIs for conference URIs.

> schema-specific behaviors. This change addresses the second 

ok.

> of HTTP 2616, which defines the 409 code:

Remember it is not just schema validation, but also validation for things like a URI. A server needs to check that a list URI, for example, suggested by a client does not conflict or not already in use. Does the 409 response for PUT cover this case?

Regards,
Hisham

> >

---

From: [email-masked]
Date: Mon, 10 May 2004 12:54:20 +0300

Some comments inline...

<uris>

ok.

Regards,
Hisham