Re: [Simple] WGLC: XCAP Base

[Aki Niemi <aki.niemi at nokia.com>]

On Sun, 2004-08-01 at 18:25, ext Jonathan Rosenberg wrote:
> Thanks for your comments, Jari. Responses inline.
> 
> Jari Urpalainen wrote:
> 
> > A few comments/questions.
> > 
> > 8.5 Managing Etags
> > 
> > As Jonathan has interpreted (complying with rfc2616) that a node or even 
> > an attribute of an xml-document can be regarded as a resource is it 
> > allowable to send the document ETag after partial delete which is then 
> > actually an ETag of a different resource ?
> 
> I don't know. I fear that the answer is no; after a DELETE, the resource 
> is deleted, so by definition THAT resource doesn't have an etag anymore.

There is something with Etags here that keeps worrying me. Because of
the way that etags are distributed over an XCAP document (i.e., all
elements/resources share the same etag value), it seems that we lose
some important property for some XCAP applications.

Let's say we have an XML document that has two sub trees. In one subtree
(called <bar>) you have a flat list of properly indexed, simple
elements, like 

<foo name="x">TRUE</foo>

Naturally updating this list doesn't require safe updates at all. One
could simply PUT/GET/DELETE blindly using the name attribute as
selection key.

Now let's say that the other subtree (called <baz>) is a much more
elaborate object, where safe updates are required. SOmething akin to
common policy <rules> for example.

Because of the way we have currently defined etags usage, I believe any
blind update to the <bar> subtree automatically forces also getting the
<baz> subtree, because the etags have changed.

I think this is really suboptimal, and it would be great if it could be
somehow avoided. For example, having the possibility for an application
to define etag "ranges". In the above example, there would be three
ranges defined: One for the root element of the document, second for the
bar subtree and the third for the baz tree. A change would only
propagate within a single range.

The application could still GET the whole document by selecting the root
element, but it would need to do separate GETs for each of the subtrees
ot get their respective etags. A HEAD to each subtree might suffice as
well, at least to some extent.

Thoughts?

Cheers,
Aki

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple