RE: Notes from DAV meeting

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

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: 14 August 2001 21:21
> To: Webdav WG
> Cc: minutes@ietf.org
> 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

Received on Wednesday, 15 August 2001 04:54:14 UTC