Subject: [Simple] XCAP and multiple edits by multiple users

From: Biot Olivier <[email-masked]>
Date: Wed, 7 Jul 2004 15:33:19 +0200

Hi list,

Although the SIMPLE WG strongly favours not inventing a new protocol for
implementing XCAP, I think some issues being regularly discussed suggest it
is time to think about adding an extension to the envisaged HTTP framework.
Consider the following issues:

1. Can multiple users safely edit the same application usage?

2. Can multiple edits be safely applied "atomically" by one user?

I think a simple solution for dealing with both issues is implementing a
time-based resource locking mechanism, similar to the what the SIP Expires
header provides. (Unfortunately HTTP states that the Expires header must
contain a HTTP-date so it is not suitable for this proposal. For this
reason, this header is named "expires" in this text.)

The idea I have in mind is that one XCAP client is allowed to LOCK or
RESERVE a resource for a specific time (seconds) as specified in the
request's "expires" header. The XCAP server can either accept or reject this
request, and may modify the amount of time the resource has a "write lock"
on it, by means of the "expires" response header. The locked resource is
unlocked after the specified time or after the client issued an UNLOCK or
RELEASE request on the resource. Note that this request does not need to be
implemented as an HTTP method, but could be communicated by means of a
"expires" header with value zero.

As long as the resource is locked, the validity of the lock must be
communicated and may be renegotiated between client and server, by means of
this "expires" header.

If another XCAP client wishes to edit the currently locked resource, the
XCAP server could issue a 503 response with a Retry-After response header
informing the XCAP client when it may reissue the same request.

If multiple edits have to be implemented as an atomic operation where each
operation must succeed, a final "commit" or "roll-back" must be possible. A
commit would happen at the same time a new Entity Tag is being computed for
the new resource, at the time the lock will either be released or will
expire. A "roll-back" should apply from the moment the first error
appreared. After a commit or a roll-back, the new ETag is computed and the
lock is released; this is communicated by sending the Etag and an "expires"
response header with 0 (zero) as value.

This approach renders the use of the ETag useless between subsequent XCAP
operations on the same locked entity. I am however not really opposed to
sending intermediate ETag values to the manipulating client.

In order to distinguish between singular XCAP operations and operations on a
locked resource, the XCAP server should respond with a 202 status instead of
a 200, which means that the client may continue with the next request.

I understand that this proposal adds at least one HTTP method (LOCK or
RESERVE) and one HTTP header (similar to the SIP Expires header), and that
(because of this) XCAP would not be 100% standard HTTP anymore.
Additionally, a "lock war" denial-of-service security breach can be seen in
this approach. However I'd like to know whether this apporach makes sense,
maybe as a future extension to "vanilla" XCAP. If I overlooked something,
please let me know.

Regards,

Olivier

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 07 Jul 2004 12:39:29 -0400

This functionality more or less already exists in Webdav, see 
http://www.ietf.org/rfc/rfc2518.txt. It provides a LOCK method that does 
exactly what you want. The lock extensions there do not support 
rollback, though I suspect there would be interest in adding it.

I think the subject of webdav usage with xcap is a good one, but one 
that should be part of follow-on activity. I think that many usages will 
not require this kind of functionality, and its important that the base 
specification be kept simple.

-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