Re: Depth header in a lock refreshing method

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.