Subject: Question on GULP - properties defined as lockable, and content of a resource

From: Lisa Dusseault <[email-masked]>
Date: Thu, 29 Dec 2005 15:35:36 -0800

Looking carefully at the text of GULP from  
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
0177.html>:

- If a request would modify the content for a locked resource, a dead
    property of a locked resource, a live property that is defined to be
    lockable for a locked resource, or an internal member URI of a
    locked collection, the request MUST fail unless the lock-token for
    that lock is submitted in the request.  An internal member URI
    of a collection is considered to be modified if it is added,
    removed, or identifies a different resource.

I see two problems with this paragraph
  - The content of a resource is not defined anywhere.  Should this be  
rewritten as "any variant" in order to consistently use RFC2616  
terminology?
  - The phrase "a live property that is defined to be lockable" implies  
that we define properties to be lockable, but we don't.  Any  
suggestions for fixing this?

One simplifying possibility is that if the request would modify *any*  
live property, the lock token is required.  However I'm concerned that  
there are some calculated live properties for which that would be  
undesirable.  For example, if a resource had a live property called  
"last-copied-to", and a COPY of that locked resource to some other  
location caused the server to change the value of that live property to  
the copy destination, then we wouldn't want to require the lock-token  
of the source just because of that live property.

As a strawman, here's a proposed rewrite of the para, including minor  
rewording/rearrangement for readability:

    "A lock-token must be submitted in a request if that request would
    modify any of the following aspects of a locked resource:
  	- any variant,
	- any dead property,
	- any live property (unless otherwise specified for that property),
	- for a collection, an internal member URI.
    An internal member URI of a collection is considered to be modified
    if it is added, removed, or identifies a different resource."

Lisa

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 29 Dec 2005 20:08:36 -0500

This rewording is fine with me.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sat, 31 Dec 2005 13:08:51 +0100

Lisa Dusseault wrote:
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0177.html>:
> 
> that we define properties to be lockable, but we don't.  Any suggestions 
> for fixing this?
> 
> the copy destination, then we wouldn't want to require the lock-token of 
> the source just because of that live property.
> 

That's ok, except for

a) we lost the MUST here (and this is a place where it's really needed), and

b) we then also have to think about which live properties defined in 
RFC2518bis are not lockable (note that it's probably wise to keep that 
terminology); DAV:lockdiscovery comes to mind.

Best regards, Julian