Subject: RE: Notes from DAV meeting

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 14 Aug 2001 17:48:18 -0400

Everthing here looks fine to me, except for:

    - Trailing slash -
   Consensus:
   (a) Servers SHOULD put trailing slash after collection names when
producing
   them.
   (b) Servers SHOULD allow requests to collections even if trailing slash
is
   missing
   (c) Servers can use the Content-Location header to clarify the proper URL
   for a collection, in the response to any request that did not include the
   proper trailing slash.
   (d) The trailing slash convention is good.  Possibly strengthen language
so
   that it's more than just a convention.

I vigorously oppose this approach.  All these "SHOULDs" and "cans" 
are unnecessary.  A simple statement of the form:

Trailing slashes MUST be ignored, e.g. the URL "http://xxx/yyy/" MUST 
identify the same resource as "http://xxx/yyy".

is sufficient and will avoid the confusion and interoperability
problems that will result from the alternative approach.  This
was discussed at length on the mailing list about a year ago,
and no implementation was identified that depended on /yyy being
a different resource from /yyy/.

Cheers,
Geoff

---

From: "Hall, Shaun" <[email-masked]>
Date: Wed, 15 Aug 2001 09:53:31 +0100

Bits snipped. Lets kill these things before they go any further IMHO...

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: 14 August 2001 21:21
> To: Webdav WG
> Cc: [email-masked]
> Subject: Notes from DAV meeting
> 
> 
> 
> I haven't received the actual notes yet from the notetaker 
> (hint, nudge) but
> here's what I wrote down from the WebDAV meeting last week in 
> London.  Note
> these are incomplete.  Lots of progress made; various threads 
> to pick up and
> continue on the list.

[Bits snipped]

> RFC 2518 Issues list
> --------------------
> 
> - Lock Permissions -
> 
> Consensus around:  Users other than lock creators MAY be able 
> to UNLOCK a
> resource by discovering and using the correct lock token.  

Assuming your are referring to "ordinary" users i.e. not say when an
Administrator removes a lock because an employee has left the company sort
of thing:

I strongly disagree with this. It should not be allowed at all.

I know locks can disappear at any time, but it could cause problems for
example - the original lock creator has a document locked and has made
changes but not PUT them back. Supposing the new lock creator UNLOCKs the
document, LOCKs it and keeps the lock for days, weeks etc. The new lock
creator makes changes to the document, re-PUTs it and UNLOCKs it. The
original lock creator still has their copy of the document with their
changes, but cannot re-PUT them for all this time (weeks?). What are they
suppose to do? They could discard their changes or after the new lock
creator has UNLOCKed the document, the original lock creator may then be
able to PUT their changes in (after weeks?). But then, there could be merge
type problems or lost update type problems if they discarded their changes
because they get fed up waiting, had to switch their client machine off etc.

> Servers should
> never allow users other than lock creaters to update a locked 
> resource, even
> if they use the correct lock token.

I know what this statement is meant to mean, but one could say this 2nd
statement contradicts the 1st because the new lock creator is not the
original lock creator. After all, look at the confusion "null resource"
caused.

>  - Lock Owner -
> 
> Consensus:
> (a) WHen client provides value for lock owner, server should 
> preserve this
> value and not modify or overwrite it.  When client does not 
> provide a value,
> Server MAY provide a helpful value.

Not sure what the server could provide here or how helpful it would be.
What were people thinking of e.g. IP address of the client ?
Agree with the first sentence though.

> Idea: RFC2518 maybe should add "lock creator" value to lock 
> information, in
> order to reduce confusion, and specify that lock creator is
> server-calculated (protected)

Disagree with this. There is no need to introduce a new property.

Also, this is an implementation detail and may give sensitive information
away e.g. an OS account name, which might be retrieved say with PROPFIND or
returned in a (failed) LOCK request.

The lock owner property is sufficient as it can contain contact information
e.g. tel no, email addy etc. Clients should be using this when issuing LOCK
requests. Fix the clients, don't change the RFC.

> Lisa

Regards

Shaun Hall
Xerox Europe

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 15 Aug 2001 09:56:18 -0400

From: Hall, Shaun [mailto:[email-masked]]

I agree with all of Shaun's comments, except for:

   > - Lock Permissions -
   > Consensus around: Users other than lock creators MAY be able to
   > UNLOCK a resource by discovering and using the correct lock
   > token.

   Assuming your are referring to "ordinary" users i.e. not say when
   an Administrator removes a lock because an employee has left the
   company sort of thing:

I strongly agree with the consensus opinion.

A client holding a lock already has to deal with locks being lost
through timeouts.  Allowing another client to effectively force the
timeout is a valuable feature that does not increase the complexity of
the locking client.  A server can use access control to control what
users have permission to force the timeout.

   I know locks can disappear at any time, but it could cause problems
   for example ...

Any such problem already occurs because of timeouts, so clients have to
deal with all these situations anyway.  Allowing a client to force
a timeout decreases the need to have an automatic server timeout,
and therefore this capability will actually decrease the number of
unnecessary timeouts (since the server can be written to assume that
timeouts will be forced by clients that need them).

   > Servers should never allow users other than lock creaters to
   > update a locked resource, even if they use the correct lock
   > token.

   original lock creator.

The "update" here means "update the content or dead properties".
An UNLOCK does not update the content or dead properties, and therefore
these two statements are consistent.  The term "update" could be
clarified, to make sure there is no misunderstanding.

   After all, look at the confusion "null resource" caused.

I don't see the relationship between forced lock timeouts and null
resources.

Cheers,
Geoff

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 15 Aug 2001 13:16:05 -0400

> From: Clemm, Geoff [mailto:[email-masked]]

   Supposing the server only supported infinite timed locks (which is
   allowed) and therefore lost locks through timeouts are not an
   issue. You've just bypassed the lock mechanism as we know it. In my
   crude example, what is the original lock creator suppose to do ?

I would strongly advise all client writer to expect timeouts
(assuming you want to interoperate with existing implementations,
such as those provided by Microsoft).  If your lock no longer
exists (either because of a timeout or an explicit unlock by
another client), then your client is responsible for letting the
user know that a write will possibly overwrite subsequent changes.
If the resource is locked by another client, your client should
give the user the option to "save as" at a different URL.  The user
can then look at the two resources (perhaps with the aid of a merge
tool, but often not) to decide whether to merge or just overwrite
the current resource.  In order to update the original resource,
the user can wait until it is unlocked, or if it has sufficient
privileges, it can "steal" the resource back (by unlocking and
then taking out its own lock).

The bottom line is that clients die and leave locks in place on
critical resources.  A server that allows no form of automatic
intervention in this case (either with automatic timeouts, or
with explicit unlock overrides) is unlikely to become very popular.

Cheers,
Geoff