Comments on locking and auto-checkin...

Hi,

In section 3.2.2 when DAV:auto-checkout is DAV:locked-update and a lock
times out the specification
says a implicit CHECKIN operation will happen.  This just seems a little
odd.

For example imagine user Fred is sitting in his client application LOCKS
a document and starts work on
it, he takes his time working on the doc and his LOCK times out, so
suddenly his incomplete work will be
checked back in without him knowing.  I guess when he goes to unlock the
document (as he is not aware
that his lock was timed out) he would get an error saying something like
"You don't have a lock on this
document (invalid lock token)".

Other options for the behaviour of timed out locks would be:

1)  Just cancel his lock (but not auto checkin).
     This would avoid checking in Freds incomplete work but would leave
Fred equally confused when he
     tries to unlock and is told that he has not got the document
locked.

2)  Do not timeout locks for auto versioning clients.
     This would keep Fred happy since he keeps the lock but it totally
defeats the point of lock timeouts.
     Do any clients set lock timeouts to be anything other than
Infinity?  I have not seen any use of lock
     timeouts yet.

3)  Find some way to inform the client that the lock has timed-out.
     Since HTTP is request/response driven we can't just send a message
to Fred to inform him the lock
     has timed out (he needs to request something first).  So the only
implementation I can think of would
     be for the client to send some kinda lock keep-alives.

I guess my preference is for option 1 but when Fred unlocks we should
return some specific error so
at least the client knows that the unlock failed because the token
specified was timed-out (rather than
just an invalid token).

What do other people think? Do lock timeouts actually get used (if not
we should remove them from the spec).
We were talking in the WebDAV (RFC2518) meeting yesterday about allowing
some principal other than the
lock owner to unlock a resource so removing lock timeouts would not mean
the lock is unbreakable.

Regards,
Peter Raymond - MERANT.