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


From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 09 Jun 2004 15:24:52 +0200
Message-ID: <40C70FA4.503@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Webdav WG <w3c-dist-auth@w3c.org>, Lisa Dusseault <lisa@osafoundation.org>, Jason Crawford <ccjason@us.ibm.com>

Julian Reschke wrote:
> OK,
> here's my attempt to summarize what Lisa and I discussed. I think this 
> should be used as resolution for the following issues:
> Note that the description below does *not* change the original 
> semantics; it's just a clarification that seems to be in sync with 
> current implementations (and that's what we should be looking for when 
> updating the protocol)...:
> 1) A LOCK request with message body is a LOCK create request. A LOCK 
> request without a message body is a LOCK refresh request.
> 2) A LOCK refresh request refreshes those locks on the request resource 
> whose lock tokens are submitted in the "If" header and whose lock-root 
> is the resource identified by the request URI. A server MAY support 
> using the Time-Out header to set a new timeout, but clients can not rely 
> on that behaviour.
> 2a) In the case of a shared lock it's technically feasable to submit 
> lock tokens for multiple locks to be refreshed in one "If" header. The 
> semantics for that seem to be clear from 2), but it's doubtful whether a 
> client will ever want to do that. IMHO it doesn't make any sense to put 
> in the additional wording to forbid it, though (that's where I disagreed 
> with Lisa...).
> Note that if we stick with this resolution, the LOCK refresh changes in 
> RFC2518bis-05 will need to be rolled back.


can we please make a decision?

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 9 June 2004 09:39:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:31 UTC