- From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Date: Thu, 1 Jan 2004 10:01:55 -0500
- To: w3c-dist-auth@w3.org
I agree with Julian that option 4 is probably best. Cheers, Geoff Julian wrote on 12/31/2003 08:32:11 AM: > Stanley Guan wrote: > > > Under the topic of "Refreshing Locks", it hints that > > Client may include a Timeout header. But, Depth header > > has not being mentioned. > > > > Under the topic of "Depth and Locking", it discussed > > what will happen if "Depth" header is specified for > > creating a new lock. But, nothing was mentioned on > > what's its implication on a lock refreshing command. > > > > Should "bis" document clarify this? > > Possibly. > > In general, methods should ignore unknown headers. In this particular > case of course, the Depth header *is* used for LOCK (just only when > creating new locks). > > So the options for LOCK refresh are: > > 1) server MUST respect Depth header, possibly changing the lock scope > 2) server MAY respect Depth header, possibly changing the lock scope > 3) server SHOULD ignore Depth header > 4) server MUST ignore Depth header > > As 4) is what currently everybody seems to implement, I'd propose to > choose that interpretration and clarify in RFC2518bis.
Received on Thursday, 1 January 2004 10:07:20 UTC