Summary on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY

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.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 3 June 2004 07:12:20 UTC