W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Re: Issue #44: REPORT_OTHER_RESOURCE_LOCKED

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 23 Jun 2004 22:38:00 -0400
To: Webdav WG <w3c-dist-auth@w3c.org>
Message-ID: <OFC511F636.FAFB8B15-ON85256EBD.000E5AC4-85256EBD.000E8474@us.ibm.com>
This precondition sounds fine to me.

I wouldn't say it applies to all methods though; only methods that
modify state on the server (e.g., not PROPFIND or the various
REPORT's).

Cheers,
Geoff

Julian wrote on 06/18/2004 03:43:52 PM:

> So I'd recommend that we define a new precondition (applying to *all* 
> methods) specifically for use in this case, that also will contain the 
> URI of the resource causing the failure inside a <href> element, similar 

> to <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1> 
> (where the same situation occurs for missing privileges).
> 
> For instance:
> 
> (DAV:need-submitted-lock-token): 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.
> 
> <!ELEMENT need-submitted-lock-token (href)* >
> 
> (the text is taken from one of the GULP rules, see 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
> latest.html#rfc.section.C.6>).
> 
> Feedback appreciated,
Received on Wednesday, 23 June 2004 22:39:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT