Subject: Re: [Bug 23] lock discovery vs shared locks

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Nov 2005 21:09:59 +0100

For the record,

I don't think that the recent discussion has brought up any new points 
that need to be said here, so I'd like to again recommend to close the 
issue with the following change (as seen in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0242.html>).

Proposed resolution for 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23>: [...]

NEW:
    A lock token is a type of state token, represented as a URI, which
    identifies a particular lock.  Each lock has exactly one unique lock
    token, which is returned upon a successful LOCK creation operation in
    the "Lock-Token" response header defined in Section 9.6.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 15 Nov 2005 18:13:51 -0800

I'm still concerned about a possible inconsistency here.  Sorry if I'm  
being dense, but I thought that we had a previous consensus (a long  
time ago) that servers SHOULD provide lock tokens for all locks so that  
if there were a client bug, a crash, a LOCK reply "lost in the mail",  
or a need for an owner or administrator to remove somebody else's stale  
lock.  Some text currently in the draft to that extent:

   "Anyone can
    find out anyone else's lock token by performing lock discovery."

So given that implies that lock discovery can find out all lock tokens  
(given permission), and that the lockdiscovery property is returned in  
the LOCK response body, doesn't that mean that the lock token is  
returned both in the LOCK response headers (Lock-Token) and body?

Also, we had previously discussed at an interop which is the "right"  
place to put the lock token and concluded that servers ought to put the  
token in both places because we found during interoperability testing  
that we had clients that looked in one place, and other clients that  
looked in the other, so we might as well continue supporting both.

Lisa

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 15 Nov 2005 22:53:39 -0500

I can only repeat what I posted a few weeks ago ... a client should
never steal a lock taken out by an earlier client by re-using the
lock token of that earlier client ... it should do so by UNLOCK'ing
the resource and requesting its own lock.  That way if the original
lock owner is still alive or comes back to life, the earlier client's
attempt to use the original lock token to update the resource will fail, 
thus preventing the changes made by the later client from being 
overwritten.

So I object to the text in the current draft, because it encourages
clients to do the wrong thing, and encourages servers to support clients
doing the wrong thing.

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 15 Nov 2005 19:59:10 -0800

I agree with you, but isn't the client supposed to UNLOCK by using the 
lock token?  If so then how does it learn it... ?

Lisa

On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote:

>  > >    token, which is returned upon a successful LOCK creation 
> operation  
>  > > in

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 15 Nov 2005 23:40:30 -0500

Sorry, I misread your message.  The text that I was objecting to was
the clauses:

> if there were a client bug, a crash, a LOCK reply "lost in the mail"

in:

> servers SHOULD provide lock tokens for all locks so 
> that if there were a client bug, a crash, a LOCK reply "lost in the 
> mail", or a need for an owner or administrator to remove somebody else's 

> stale lock. 

>   find out anyone else's lock token by performing lock discovery."

which is fine.  I'd prefer making that explicit (e.g. "A lock token 
discovered by a client via lock discovery SHOULD NOT be used by that
client for anything other than an UNLOCK request, even if the user
is authenticated as owning that lock"), but I don't insist that this
be added (as long as the converse is not added :-).

Cheers,
Geoff

> >  > (given permission), and that the lockdiscovery property is returned 

> >  > place to put the lock token and concluded that servers ought to put 

> > the

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Nov 2005 09:28:13 +0100

Lisa Dusseault wrote:
> being dense, but I thought that we had a previous consensus (a long time 
> ago) that servers SHOULD provide lock tokens for all locks so that if 
> there were a client bug, a crash, a LOCK reply "lost in the mail", or a 
> need for an owner or administrator to remove somebody else's stale 

That's not guaranteed. Servers are currently not to required to reveal 
locks, and if they do, they aren't required to reveal the individual 
lock tokens. Note that <locktoken> is optional in <lockdiscovery> 
(<http://greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_activelock>).

> returned both in the LOCK response headers (Lock-Token) and body?

It may, but clients can not rely on it.

> looked in the other, so we might as well continue supporting both.

Again: the only *reliable* way to obtain the new lock token is to parse 
the Lock-Token response header. Anything else may not work because (a) 
the server may not be including it in the <lockdiscovery> and/or (b) 
because there may be multiple entries due to shared locks. Of course all 
  of this *could* be explained, but I absolutely do not understand why 
we would want to spend a paragraph describing a work flow that is not 
guaranteed to work, when there's another one which is.

Servers not returning the Lock-Token response header upon successful 
lock creation are buggy and need to be fixed. Is anybody ware of a 
server that currently shows this behaviour?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 16 Nov 2005 07:41:25 -0800

That's fine with me too.  So does this mean that lockdiscovery property 
(if readable) MUST contain all the locks and all their lock tokens?  
Does that mean that in reply to a LOCK request which successfully 
creates a new lock, the server MUST include the full lockdiscovery 
property including not just the new lock but also other locks?

Lisa

On Nov 15, 2005, at 8:40 PM, Geoffrey M Clemm wrote:

>  > >  >
>  > >  > I'm still concerned about a possible inconsistency here. 
>  Sorry if
>  > > I'm  
>  > >  > being dense, but I thought that we had a previous consensus (a 
> long
>  > >  
>  > >  > time ago) that servers SHOULD provide lock tokens for all 
> locks so
>  > > that  
>  > >  > if there were a client bug, a crash, a LOCK reply "lost in the
>  > > mail",  
>  > >  > or a need for an owner or administrator to remove somebody 
> else's
>  > > stale  
>  > >  > lock.  Some text currently in the draft to that extent:
>  > >  >
>  > >  >    "Anyone can
>  > >  >     find out anyone else's lock token by performing lock 
> discovery."
>  > >  >
>  > >  > So given that implies that lock discovery can find out all lock
>  > > tokens  
>  > >  > (given permission), and that the lockdiscovery property is 
> returned
>  > > in  
>  > >  > the LOCK response body, doesn't that mean that the lock token 
> is  
>  > >  > returned both in the LOCK response headers (Lock-Token) and 
> body?
>  > >  >
>  > >  > Also, we had previously discussed at an interop which is the
>  > > "right"  
>  > >  > place to put the lock token and concluded that servers ought 
> to put
>  > > the  
>  > >  > token in both places because we found during interoperability
>  > > testing  
>  > >  > that we had clients that looked in one place, and other clients
>  > > that  
>  > >  > looked in the other, so we might as well continue supporting 
> both.
>  > >  >
>  > >  > Lisa
>  > >  >
>  > >  > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote:
>  > >  >
>  > >  > >
>  > >  > > For the record,
>  > >  > >
>  > >  > > I don't think that the recent discussion has brought up any 
> new
>  > > points  
>  > >  > > that need to be said here, so I'd like to again recommend to
>  > > close the  
>  > >  > > issue with the following change (as seen in  
>  > >  > > 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/
>  > >  > > 0242.html>).
>  > >  > >
>  > >  > > Proposed resolution for  
>  > >  > > <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23>: 
> [...]
>  > >  > >
>  > >  > > NEW:
>  > >  > >    A lock token is a type of state token, represented as a 
> URI,
>  > > which
>  > >  > >    identifies a particular lock.  Each lock has exactly one
>  > > unique lock
>  > >  > >    token, which is returned upon a successful LOCK creation
>  > > operation  
>  > >  > > in
>  > >  > >    the "Lock-Token" response header defined in Section 9.6.
>  > >  > >
>  > >  > >
>  > >  > > Best regards, Julian
>  > >  > >
>  > >  >
>  > >  >

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Nov 2005 16:57:26 +0100

Lisa Dusseault wrote:
> (if readable) MUST contain all the locks and all their lock tokens? Does 

No: <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.13.8>:

"The server is free to withhold any or all of this information if the 
requesting principal does not have sufficient access rights to see the 
requested data."

> that mean that in reply to a LOCK request which successfully creates a 
> new lock, the server MUST include the full lockdiscovery property 
> including not just the new lock but also other locks?

I think RFC2518 is very clear about this.

Why are we discussing this? Upon lock creation, you get the lock token 
in the "lock-token" response header. I do not understand why you're 
trying to describe an alternate method, which may or may not work 
depending on how the server treats lock token privacy and shared locks.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 16 Nov 2005 11:11:07 -0500

Some of the reasons why a server does not include the lock-token:
- all locks time-out in a reasonable period of time, and so no explicit 
unlock is needed/supported
- only the owner/admin is allowed to do the unlock, so the lock-token is 
only exposed to a client that is authenticated as being either the owner 
or the admin

Cheers,
Geoff

Lisa Dusseault <[email-masked]> wrote on 11/16/2005 10:41:25 AM:

> >  > > attempt to use the original lock token to update the resource 
will
> >  > > fail,
> >  > >  > I'm still concerned about a possible inconsistency here. 
> >  Sorry if
> >  > > I'm  
> >  > >  > being dense, but I thought that we had a previous consensus (a 

> > long
> >  > >  
> >  > >  > time ago) that servers SHOULD provide lock tokens for all 
> > locks so
> >  > > that  
> >  > >  > or a need for an owner or administrator to remove somebody 
> > else's
> >  > > stale  
> >  > >  > So given that implies that lock discovery can find out all 
lock
> >  > >  > that we had clients that looked in one place, and other 
clients
> >  > >  > > I don't think that the recent discussion has brought up any 
> > new
> >  > > points  
> >  > >  > > 0242.html>).
> >  > >  > > <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23>: 

> > [...]
> >  > >  > >
> >  > >  > > NEW:
> >  > >  > >    A lock token is a type of state token, represented as a 
> > URI,
> >  > > which

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 16 Nov 2005 09:11:11 -0800

I agree there's a fair argument for allowing servers not to put lock 
tokens in lockdiscovery all the time.  I can clarify the text there 
because there certainly isn't a consensus to require servers to do 
that.

We could, however, treat the LOCK (create lock) response slightly 
differently, and require that the body contains the lockdiscovery 
property *including* the new lock token -- a special case to handle 
those clients that had problems at Interop tests.

Lisa

On Nov 16, 2005, at 8:11 AM, Geoffrey M Clemm wrote:

> - all locks time-out in a reasonable period of time, and so no 
> explicit unlock is needed/supported
> - only the owner/admin is allowed to do the unlock, so the lock-token 
> is only exposed to a client that is authenticated as being either the 
> owner or the admin
>
> Cheers,
> Geoff
>
>  > >  > that if there were a client bug, a crash, a LOCK reply "lost 
> in the
>  > >  > mail", or a need for an owner or administrator to remove 
> somebody
>  > > else's
>  > >  > stale lock.
>  > >
>  > > Lisa Dusseault <[email-masked]> wrote on 11/15/2005 
> 10:59:10
>  > > PM:
>  > >
>  > >  > I agree with you, but isn't the client supposed to UNLOCK by 
> using
>  > > the
>  > >  > lock token?  If so then how does it learn it... ?
>  > >  >
>  > >  > Lisa
>  > >  >
>  > >  > On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote:
>  > >  >
>  > >  > >
>  > >  > > I can only repeat what I posted a few weeks ago ... a client
>  > > should
>  > >  > > never steal a lock taken out by an earlier client by 
> re-using the
>  > >  > > lock token of that earlier client ... it should do so by
>  > > UNLOCK'ing
>  > >  > > the resource and requesting its own lock.  That way if the
>  > > original
>  > >  > > lock owner is still alive or comes back to life, the earlier
>  > > client's
>  > >  > > attempt to use the original lock token to update the 
> resource will
>  > >  > > fail,
>  > >  > > thus preventing the changes made by the later client from 
> being
>  > >  > > overwritten.
>  > >  > >
>  > >  > > So I object to the text in the current draft, because it
>  > > encourages
>  > >  > > clients to do the wrong thing, and encourages servers to 
> support
>  > >  > > clients
>  > >  > > doing the wrong thing.
>  > >  > >
>  > >  > > Cheers,
>  > >  > > Geoff
>  > >  > >
>  > >  > >
>  > >  > > [email-masked] wrote on 11/15/2005 09:13:51 PM:
>  > >  > >
>  > >  > >  >
>  > >  > >  > I'm still concerned about a possible inconsistency here.
>  > >  Sorry if
>  > >  > > I'm  
>  > >  > >  > being dense, but I thought that we had a previous 
> consensus (a
>  > > long
>  > >  > >  
>  > >  > >  > time ago) that servers SHOULD provide lock tokens for all
>  > > locks so
>  > >  > > that  
>  > >  > >  > if there were a client bug, a crash, a LOCK reply "lost 
> in the
>  > >  > > mail",  
>  > >  > >  > or a need for an owner or administrator to remove somebody
>  > > else's
>  > >  > > stale  
>  > >  > >  > lock.  Some text currently in the draft to that extent:
>  > >  > >  >
>  > >  > >  >    "Anyone can
>  > >  > >  >     find out anyone else's lock token by performing lock
>  > > discovery."
>  > >  > >  >
>  > >  > >  > So given that implies that lock discovery can find out 
> all lock
>  > >  > > tokens  
>  > >  > >  > (given permission), and that the lockdiscovery property is
>  > > returned
>  > >  > > in  
>  > >  > >  > the LOCK response body, doesn't that mean that the lock 
> token
>  > > is  
>  > >  > >  > returned both in the LOCK response headers (Lock-Token) 
> and
>  > > body?
>  > >  > >  >
>  > >  > >  > Also, we had previously discussed at an interop which is 
> the
>  > >  > > "right"  
>  > >  > >  > place to put the lock token and concluded that servers 
> ought
>  > > to put
>  > >  > > the  
>  > >  > >  > token in both places because we found during 
> interoperability
>  > >  > > testing  
>  > >  > >  > that we had clients that looked in one place, and other 
> clients
>  > >  > > that  
>  > >  > >  > looked in the other, so we might as well continue 
> supporting
>  > > both.
>  > >  > >  >
>  > >  > >  > Lisa
>  > >  > >  >
>  > >  > >  > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote:
>  > >  > >  >
>  > >  > >  > >
>  > >  > >  > > For the record,
>  > >  > >  > >
>  > >  > >  > > I don't think that the recent discussion has brought up 
> any
>  > > new
>  > >  > > points  
>  > >  > >  > > that need to be said here, so I'd like to again 
> recommend to
>  > >  > > close the  
>  > >  > >  > > issue with the following change (as seen in  
>  > >  > >  > >
>  > >  > >  > > 0242.html>).
>  > >  > >  > >
>  > >  > >  > > Proposed resolution for  
>  > >  > >  > > 
>  > >  > >  > >
>  > >  > >  > > NEW:
>  > >  > >  > >    A lock token is a type of state token, represented 
> as a
>  > > URI,
>  > >  > > which
>  > >  > >  > >    identifies a particular lock.  Each lock has exactly 
> one
>  > >  > > unique lock
>  > >  > >  > >    token, which is returned upon a successful LOCK 
> creation
>  > >  > > operation  
>  > >  > >  > > in
>  > >  > >  > >    the "Lock-Token" response header defined in Section 
> 9.6.
>  > >  > >  > >
>  > >  > >  > >
>  > >  > >  > > Best regards, Julian
>  > >  > >  > >
>  > >  > >  >
>  > >  > >  >

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Nov 2005 18:16:15 +0100

Lisa Dusseault wrote:
> because there certainly isn't a consensus to require servers to do that.
> 

This does not make any sense. Sorry.

It's the "Lock-Token" response header that *always* contains the result. 
Why do you insist on changing the spec so that there's a second mechanism?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 16 Nov 2005 09:23:50 -0800

On Nov 16, 2005, at 9:16 AM, Julian Reschke wrote:

> It's the "Lock-Token" response header that *always* contains the 
> result. Why do you insist on changing the spec so that there's a 
> second mechanism?
>
Because that was the rough consensus at the Interop that year, amongst 
the people there, and I don't want to overthrow that too lightly.  As 
soon as Cullen declares that there's a consensus for a single 
mechanism, I'll edit the spec according to the consensus.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Nov 2005 18:27:09 +0100

Lisa Dusseault wrote:
> soon as Cullen declares that there's a consensus for a single mechanism, 
> I'll edit the spec according to the consensus.

Ultimately, consensus needs to be found in the WG (== the mailing list), 
not at a meeting. I don't recall any discussion over here about 
requiring the response body. Did I miss something?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 16 Nov 2005 11:58:01 -0800

On Nov 16, 2005, at 9:27 AM, Julian Reschke wrote:

>>>> I agree there's a fair argument for allowing servers not to put 
>>>> lock tokens in lockdiscovery all the time. I can clarify the text 
>>>> there because there certainly isn't a consensus to require servers 
>>>> to do that.
>> Because that was the rough consensus at the Interop that year, 
>> amongst the people there, and I don't want to overthrow that too 
>> lightly.  As soon as Cullen declares that there's a consensus for a 
>> single mechanism, I'll edit the spec according to the consensus.
>
> Ultimately, consensus needs to be found in the WG (== the mailing 
> list), not at a meeting. I don't recall any discussion over here about 

I checked back in the email archives, and it looks like there was a 
very closely related discussion which I thought covered it but it 
didn't get into this specific issue.  Naturally consensus needs to be 
found in the WG and I'm sure we can accomplish this.  So are there any 
other opinions on whether the server MUST return the lock token in the 
body as well as the header of a response when a new lock is created -- 
even though we all agree the server doesn't need to normally put that 
info in the lockdiscovery property?

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Nov 2005 21:23:06 +0100

Lisa Dusseault wrote:
> I checked back in the email archives, and it looks like there was a very 
> closely related discussion which I thought covered it but it didn't get 
> into this specific issue.  Naturally consensus needs to be found in the 
> WG and I'm sure we can accomplish this.  So are there any other opinions 

(nod)

> on whether the server MUST return the lock token in the body as well as 
> the header of a response when a new lock is created -- even though we 
> all agree the server doesn't need to normally put that info in the 
> lockdiscovery property?

Making a normative change to the spec because of specific broken clients 
IMHO is as bad as the other way round. Just because we say so will not 
resolve the interop issue, if it still exists. Does anybody know whether 
this is still the case?

To me, this seems to a a perfect example, for an interop guide, not a 
change to the spec.

Such as:

1) What to do if the LOCK request suceeds, but no Lock-Token respnse 
header is there (answer: complain to the server vendor, and then in the 
worst case check the response body).

2) What to do if a PROPFIND response contains *multipple* 
<lockdiscovery> properties? (answer: complain to the server vendor, 
and/or assume that this is this server's idea how to return info about 
shared locks).

We've talked about a document like that several times. Should I start one?

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Nov 2005 12:37:34 -0800

On the call this morning, I thought that Geoff outlined 3 proposals

1) change nothing (assuming says MUST put in header)
2) don't change how anything works today but add the clarifying statement
that servers MAY NOT put it in a body
3) change to say that servers MUST put in both body and header

Now I might have the descriptions of these three all wrong but I am pretty
sure that I heard that 1 or 2 worked for someone and 2 or 3 worked for
someone else and that 2 worked for everyone. I thought we decided to put 2
in the next rev of the *draft* and then ask the WG (folks on the list
including people on this thread) had a problem with that draft.

What part of this did I not get? What are we still discussing?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Nov 2005 22:41:21 +0100

> 3) change to say that servers MUST put in both body and header

Right.

> What part of this did I not get? What are we still discussing?

No, you are right. These options were discussed, and 2) was something 
everybody seemed to be able to agree upon.

Sorry if I added to the confusion. So I'll rephrase that: when in the 
future we come across things that could *also* go into an implementation 
guide instead of the spec, we may want to actually consider to start a 
document like that; and I'm volunteering to work on that. That would be 
separate from RFC2518bis, and potentially not even an IETF document 
(unless the WG would want it to be that way).

Best regards, Julian

---

From: Jim Luther <[email-masked]>
Date: Wed, 16 Nov 2005 14:05:42 -0800

> It may, but clients can not rely on it.

The Mac OS X WebDAV file system client gets the locktoken out of the  
response body when it creates a new lock. My guess (since this code  
was written before I started working on anything WebDAV related) is  
that it was done because:

* rcf2518 section 8.10.1 <http://greenbytes.de/tech/webdav/ 
rfc2518.html#rfc.section.8.10.1> says, "The response MUST contain the  
value of the lockdiscovery property in a prop XML element."

* the example given in rcf2518 section 8.10.8 <http://greenbytes.de/ 
tech/webdav/rfc2518.html#rfc.section.8.10.8> does not show a Lock- 
Token response header in the response.

Of course, the Mac OS X WebDAV file system client can be changed in  
some future release to use the Lock-Token response header (and I just  
wrote up a bug report to make sure that happens). However, if a  
server wants to interoperate with existing versions of the Mac OS X  
WebDAV file system client, they'll need to return the the locktoken  
in the body.

- Jim

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 16 Nov 2005 16:43:12 -0800

Julian, do these data points affect your conclusion?

thanks,
Lisa

On Nov 16, 2005, at 2:05 PM, Jim Luther wrote:

> * rcf2518 section 8.10.1 
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.1> 
> says, "The response MUST contain the value of the lockdiscovery 
> property in a prop XML element."
>
> * the example given in rcf2518 section 8.10.8 
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.8> 
> does not show a Lock-Token response header in the response.
>
> wrote up a bug report to make sure that happens). However, if a server 
> wants to interoperate with existing versions of the Mac OS X WebDAV 
> file system client, they'll need to return the the locktoken in the 
> body.
>
> - Jim
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 17 Nov 2005 20:52:41 -0800

On 11/16/05 1:41 PM, "Julian Reschke" <[email-masked]> wrote:

> an implementation

My measure of a successful protocol is that people find it useful and that
means it needs to get implemented. A "hints to implementers" document seems
all good and could be IETF document or not - I don't care as long as it
helped the adoption of the protocol by making it easier to implement.
Example flow documents have helped other groups make it easier to get
interoperable implementations.

That said, a skilled programmer still needs to be able to correctly
implement and understand the protocol by just reading the spec and things it
normatively references. The spec should help make this easy not hard. And if
there is something that in the specification that a significant percentage
of competent implementers might get wrong on the wire, the specification was
probably not clear enough.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Nov 2005 06:59:26 +0100

Cullen Jennings wrote:
> ...

Yes, and this is certainly the case here. As far as I can tell, there 
are two major problems (and possibly one minor problem) with RFC2518, 
and these should be fixed no matter what. In particular:

1) Normative text and examples are inconsistent. As almost all readers 
look at examples first and only read the rest when things do *not* work, 
making sure that examples are correct is extremely important.

2) The specification introduces two different ways to do things, where 
one would have been absolutely sufficient. To make things worse, one of 
the two things is flawed (it doesn't always work, so clients should not 
rely on in in the first place).

3) The given example at a minimum should have illustrated the potential 
problems with the second approach (for instance, by showing the result 
for the case that a second shared lock was created).

I wasn't part of the WG when this was written, but it certainly looks 
like the "Lock-Token" response header was introduced very late because 
somebody realized that the other approach simply doesn't work. 
Unfortunately, the spec wasn't checked properly for other changes to be 
made.

How to proceed?

a) Make the *fixes* to the spec we obviously need (fix the example to 
use the Lock-Token header and modify the response body so that it 
becomes clear why parsing it will be a bad idea)

b) Collect information what implementations do today (JimL, thanks for 
the feedback in this and all the other cases!).

c) Then decide about what else needs to be done.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Nov 2005 17:52:19 +0100

> Julian, do these data points affect your conclusion?

This kind of proves how important it is to first clearly understand the 
problem, and to document it, and only then to think about spec changes.

So I've gone back to the good old approach to actually run tests on 
existing servers (test script attached) and clients.

Things I've been looking for:

1) Is the Lock-Token header returned upon LOCK?

2) Is the lockdiscovery property returned?

3) If the lockdiscovery property is returned, does it only contain the 
new lock token, or also other tokens (of shared locks)?

And, while testing, I came across some more issues:

4) Are lock tokens correct?

5) Does PROPFIND/lockdiscovery work as expected on resources with 
multiple shared locks?

Results:

SAP Netweaver KM: 1) yes, 2) yes, 3) contains all, 4) yes, 5) yes

Apache/moddav: 1) yes, 2) yes, 3) only the newly created, 4) yes, 5) yes

IIS6: 1) yes, 2) yes, 3) only the newly created, 4) yes, 5) no (returns 
multiple property instances)

Xythos: 1) yes, 2) yes, 3) contains all, 4) no (uses opaquelocktoken, 
but not the correct syntax), 5) yes

Summary:

S1) all servers tested return the Lock-Token header

S2) all return the <lockdiscovery> property, but with differences when 
there were multiple locks (naturally I claim that "contains all" is the 
right answer)

S3) one server still does not get lock tokens right

S4) one server doesn't get lock discovery in presence of multiple locks 
right

Next steps:

re S2) decide what's right; noting that it really doesn't matter if we 
tell clients just to use the Lock-Token response header; so why not 
remove the stuff about <lockdiscovery> response bodies?

re S3) I hope the developers are reading this :-)

re S4) I'll open a bug report.

On the client side I only tested what happens if Microsoft Office tries 
a lock, but doesn't get the <lockdiscovery> response body. This led to 
Office thinking the lock did not succeed, opening the document 
read-only. I'll open a bug report for that one as well.

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.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 18 Nov 2005 08:59:44 -0800

This is great data Julian, very useful.

> servers continue to return it when backward-compatibility with older 
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.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Nov 2005 18:06:21 +0100

> 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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 18 Nov 2005 12:31:02 -0500

>From a lock privacy perspective, putting all information about the
newly created lock in the lockdiscovery response to a LOCK
request is (of course) no problem, so requiring that is fine with me.

Perhaps the new text could require that full information about a LOCK
be returned in the lockdiscovery response to a LOCK, while information
about other locks is optional in the lockdiscovery response to a LOCK.

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 18 Nov 2005 09:37:25 -0800

That works for me.  If others agree I can try to write up text.

Lisa

---

From: Jim Luther <[email-masked]>
Date: Fri, 18 Nov 2005 10:24:16 -0800

Our existing code only uses LOCK to (1) get a new exclusive lock and  
(2) to refresh the exclusive locks we own. We parse the lockdiscovery  
response for a lock-token in both cases. I looked through the various  
versions of our code and I *think* that it wouldn't matter if the  
lockdiscovery response were not returned in the LOCK refresh  
response, but without a server to test against, I cannot be sure.

So I agree with Geoff, but would add the requirement of returning the  
lockdiscovery response for a LOCK refresh because it would be useful  
for the same reasons you'd want the lockdiscovery response when a  
lock is created (to get the locktoken, timeout value, etc). This  
should not be a lock privacy problem because the client has proved it  
knows about the lock via the If header in the request.

- Jim

---

From: Elias Sinderson <[email-masked]>
Date: Fri, 18 Nov 2005 11:31:05 -0800

> That works for me. If others agree I can try to write up text.

+1, this looks like a very workable solution.

Best,
Elias

---

From: Julian Reschke <[email-masked]>
Date: Sat, 19 Nov 2005 11:10:55 +0100

Jim Luther wrote:
> 
> Our existing code only uses LOCK to (1) get a new exclusive lock and (2) 
> to refresh the exclusive locks we own. We parse the lockdiscovery 
> lockdiscovery response were not returned in the LOCK refresh response, 
> but without a server to test against, I cannot be sure.
> 
> lockdiscovery response for a LOCK refresh because it would be useful for 
> the same reasons you'd want the lockdiscovery response when a lock is 
> created (to get the locktoken, timeout value, etc). This should not be a 
> lock privacy problem because the client has proved it knows about the 
> lock via the If header in the request.

...via the "Lock-Token" header in the request...

Best regards, Julian