Subject: RE: [Simple] XCAP Issue 8: Etag Scope

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 28 Jun 2004 11:43:49 +0100

It certainly would be useful to see use cases if people think we need more complicated solutions.

Looking for example at conferencing, most of the use cases I can think of do not need anything like the complexity.

For example a conference creator may be privileged enough to modify the whole scope of the conference policy, but if he assigns privileges to others, then that is presumably because he does not wish to maintain the conference policy in those areas himself. Therefore in the majority of cases, I do not see both these users wishing to modify the document simultaneously, and if they do, a wait while one finishes is not precluded.

I can envisage the members list of a conference policy being modified by the conference creator, while the attributes of a particular user are being modified by the user himself.

Therefore while simultaneous modification of the conference policy may be attempted, either the compromise solution proposed by Jonathan below, or separate documents for different parts of conference policy, would cater for the majority of cases of simultaneous use.

Therefore I would avoid going for the full flexible solution.

regards

Keith

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 24 June 2004 03:40
> To: Simple WG
> Subject: [Simple] XCAP Issue 8: Etag Scope
> 
> 
> 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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Jun 2004 07:30:18 -0400

> more complicated solutions.

I'd also like to understand the use cases for this. Hisham, can you 
provide some more?

> 
> Looking for example at conferencing, most of the use cases I can
> think of do not need anything like the complexity.
> 
> For example a conference creator may be privileged enough to modify
> the whole scope of the conference policy, but if he assigns
> privileges to others, then that is presumably because he does not
> wish to maintain the conference policy in those areas himself.
> Therefore in the majority of cases, I do not see both these users
> wishing to modify the document simultaneously, and if they do, a wait
> while one finishes is not precluded.
> 
> I can envisage the members list of a conference policy being modified
> by the conference creator, while the attributes of a particular user
> are being modified by the user himself.

In such a case, one might want to split the policy up into several 
documents. For example, there might be one document for the overall 
policy, and then a document for each user that contains information that 
the user can modify about themself.

-Jonathan R.