- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 18 Nov 2005 18:06:21 +0100
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: webdav WG <w3c-dist-auth@w3.org>
Lisa Dusseault wrote: > > This is great data Julian, very useful. > > On Nov 18, 2005, at 8:52 AM, Julian Reschke wrote: > >> >> Proposal: >> >> 1) Describe lock token discovery after successful LOCK in exactly one >> place in the spec, and make sure examples are correct >> >> 2) Remove the requirement to return the <lockdiscovery>, and mention >> that change in the "changes" section, including rational and suggest >> servers continue to return it when backward-compatibility with older >> clients is an issue. >> > What about clients learning the lock timeout? I know some clients use > the <lockdiscovery> in the response body to learn what timeout the > server chose, and use that to know when to refresh the lock. Good question, for which I don't have an answer. We *could* state that the <lockdiscovery> response indeed is *not* the same as a <lockdiscovery> property, and require servers to return complete information just for the newly created lock. That would require a change in the shared lock support in SAP KM and in Xythos, but I guess both parties could live with that. Geoff, any input about how a server concerned with the privacy of lock information would return the actual timeout value (as compared to the one sent by the client)? Best regards, Julian
Received on Friday, 18 November 2005 17:07:44 UTC