Lock refresh (If header vs Lock-Token header)

Hi,

there's an open issue that we have using the current draft, and that we 
haven't been able to resolve before submitting draft 14 (which will be 
the WG last call draft).

Summary:

It's undisputed that RFC2518's concept of lock refresh is a mess. We 
have thrown away implicit lock refreshs (not used by clients, 
potentially expensive). This is good.

This issue is about whether explicit lock refresh requests should use 
the Lock-Token request header instead of the If header. I think 
everybody agrees that it would have been better to use Lock-Token in the 
first place, because

- using the If header for refresh adds yet another thing to something 
that is already too complex

- using the If header also means it's hard to specify what a server is 
supposed to do if the If header as multiple lock tokens, or lock tokens 
in tagged lists referring to other resources

On the other hand:

- none of the servers I regularly test with (SAP KM, Xythos, 
Apache/moddav, IIS) support the LOCK refresh with Lock-Token header as 
of today

- RFC2518bis thus "encourages" servers to support the old behaviour
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-14.html#rfc.section.9.10.2>)

- Clients as of today send the LOCK refresh with the If header

With the current wording, new servers (class 3) are not required to 
honor the If header for LOCK refresh, thus clients would need to be 
updated to either send both headers (hoping this doesn't break old 
servers), or to check the server version first. None of these options is 
really pleasant.

Summary: it seems that this change trades a bit of consistency with lots 
of potential interoperability problems. Thus, it may be wiser to back it 
out, and to clarify the old behavior instead.

(note: I came across this issue when working on class 3 conformance for 
our server, so this isn't a purely theoretical argument)


So at this point, the important question is...:

1) Server Implementors: do you plan to support both ways to specify the 
lock token?

2) Client Implementors: are you aware of this incompatible change, and 
are you prepared to change your code accordingly (either by sending both 
headers, or by checking the server compliance class first)?

Best regards, Julian

(see also <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143>)

Received on Monday, 20 February 2006 16:13:26 UTC