Re: Summary on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY

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:
> 
> - LOCK_BODY_SHOULD_BE_MUST
> - LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
> 
> 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.

OK,

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