Subject: [Simple] XCAP Issue 8: Etag Scope

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jun 2004 06:49:10 -0400

[resending, didnt seem to go through the first time]

Folks,

I've spent a bunch of time since the interim trying to work out details
on how etag handling in XCAP needs to work, and to address the question
asked by Aki, which is how the client keeps its etags synchronized with
the server. As you may recall, at the last IETF meeting, we had
consensus that etags could be scoped to various sub-trees in a document,
rather than the whole document.

In a separate note, I will send out the text that I created for the xcap
specification which  defines what this means. It concretely defines a
"scope" as a set of resources (each resource having a unique HTTP URI)
which all share the same value of an etag. Each resource can only be in
one scope. A change in one resource in a scope causes a change in the
etags for all other resources in that scope. A scope is structured as
either a subtree, or as the intersection of a sub-tree with sub-trees
beneath it.

Unfortunately, it got really complicated, as you can see from the text.
I think we need to simplify this a lot. I was able to come up with three
possible simplifications that made sense. They are:

1. Revert to whats currently documented in xcap - there is only one
scope, and its for the entire document. Thus, the document, and all
elements and attributes within it, would have the same etag. This would
make it very hard to have two people independently edit separate parts
of the same document. If you want that, you need to have multiple documents.

2. Redefine a scope as just a tree (never the intersection of a tree
with some of its sub-trees). Any elements outside of the defined scopes
have NO etag. Here's an example. Lets say I have a document that looks
like this:

<document>
   <lists>
      <list id="1">STUFF</list>
      <list id='2">OTHER STUFF</list>
   </lists>

   <users>
     <happy-users>
        <user id="joe"/>
        <user id="bob"/>
     </happy-users>
     <sad-users>
        <user id="mary"/>
        <user id="bill"/>
     </sad-users>
   </users>
</document>

The application usage would indicate that the scopes are defined by the
elements matching the expressions "/document/lists/list" and
"/document/users/happy-users/user" and "/document/users/sad-users/user".
  Any element that matches one of those expression is the root of a
scope, and that scope would include the sub-tree rooted in that element.
Any element outside of those scopes has no etag. This includes the
document itself.

The rationale for this is that it matches how things would work if each
scope was actually a document in a filesystem, and every  element above
it was a directory in that filesystem. Normally, those directories are
not directly referenceable as an HTTP resource, and don't inherently
have etags.

This appraoch vastly simplifies the procedure by which a client keeps
its etags up to date. It would also allow a single document to be edited
by multiple users, without stepping on each others toes. The drawback is
that, if you don't want to edit just pieces of the document, but rather
the document as a whole, you can't take advantage of etags to make sure
you don't clobber someone elses changes.

There are two variants for this approach:

Variant A: The definition of the scope boundaries are defined by the
application usage, and applied to all documents

Variant B: The definition of the scope boundaries are defiend by the
application usage. It can define a multiplicity of potential scope
boundaries, and each document uses one of them. We provide a way for the
client to dynamically determine which scope boundaries are in use. This
would allow some documents to have an etag for the whole document, and
others to have etags only for sub-trees within it.

3. Go with the approach documented by the text I sent in the other note.

So, which do we do? I think we should do option 1. Its really simple. I
dont think any of our current usages would really require multiple
editors on the same document; it seems like we should always be able to
split it into multiple documents.

Thoughts?

-- 
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, 28 Jun 2004 11:56:08 +0300

I don't believe option 1 is the right way to go. CPCP requires multiple users to edit the document. We thought we would leave this to later, but Alan Johnston indicated that we need this in the first version of CPCP.

I read very quickly through your text for option 3 and I like it.

Regards,
Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 24.June.2004 05:40
> To: Simple WG
> Subject: [Simple] XCAP Issue 8: Etag Scope
> 
> 
> Folks,
>

---

From: [email-masked]
Date: Wed, 30 Jun 2004 12:32:01 +0300

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 30.June.2004 12:13
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] XCAP Issue 8: Etag Scope
> 
> 
> 
> 
> [email-masked] wrote:
> 
> >>> There is a requirement where key participants, for example, get
> >>> the privilege to modify the Dial-out list, the security
> >>> parameters in a conference, or add a media stream to the
> >>> conference.
> >> 
> >> Sure. The question, however, is whether, in these cases, its 
> >> necessary to condition these operations on the current values?
> > 
> > 
> > I was answering the question on whether there are cases that require
> > multiple users to modify the same piece of XML document.
> > 
> > I think you are right that those cases don't need conditioning.
> 
> Does that mean that you are ok with document level scopes?

Yes.

/Hisham

> -Jonathan R.