Subject: [Simple] Etags issue in XCAP

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Wed, 03 Mar 2004 03:03:12 +0200

Hi,

Currently etags are returned for all elements in the XCAP tree. Although
they may be scoped in an application specific manner, I think we need to
also allow for a case where for a particular element the XCAP server
never returns an etag. This is because there may be elements for which
it doesn't matter what the original content was when adding/deleting.

For example, in the CPCP application usage, the <conference-info>
element contains a <subject> element that describes the current topic of
the conference. There is really no need to care what the original topic
was if a user with appropriate rights wants to change it. So instead of
   having to first GET it, and receive an etag, the user would "blindly"
PUT a <subject> with a new value without using the If-Match precondition.

This would be especially useful for elements that may be relatively
large. Having to GET the content before any changes to it can be made
may result in starvation of a client behind a low speed link. I.e., the
etag that the client finally receives is already invalidated by 
concurrent updates from clients behind faster links.

For example, in the CPCP ACL element, again a client is only interested
in adding or expelling a particular user. It doesn't care what the
original contents of the ACL was. It would be OK just to blindly add or
delete a matching element.

So my proposal is that in addition to defining the scope of returned
etags, an XCAP application usage can also define for which elements no
etags are ever returned. A client that receives a document without the
ETag header field would know that this document (element) allows for
blind modifications.

How does this sound?

Cheers,
Aki

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