Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 27 Sep 2001 10:12:34 -0400

Having a server capture and make available principal information
of this kind is a privacy and security problem, which is why
it is defined to be client controlled.  If a server ignores what
the client has requested, and stores more information
(or even just a different format), this could violate the user's
privacy/security wishes.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Thursday, September 27, 2001 9:08 AM
To: Clemm, Geoff; Webdav WG
Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner

a) The principal that requested the LOCK (if known).
b) It might provide a user with contact information.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Thursday, September 27, 2001 3:00 PM
> To: Webdav WG
> Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner
> 
> 
> How do you define "the actual owner of a lock" in an interoperable way?
> What would a client do with that information?
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> 
> I would be interested to work on this definition. I think it's essential
> that a server can provide enough information to a client to discover the
> actual owner of a lock, no matter whether and what *his* client has
> submitted as DAV:owner. First tests show that extending 
> DAV:activelock with
> new child elements didn't have any negative impact of MS Office and Adobe
> GoLive.
>

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 27 Sep 2001 15:09:33 -0700

Julian Reschke writes:
> DAV:activelock with new child elements didn't have any negative impact on
> MS Office and Adobe GoLive.

To me, the answer to "what information should be available in the lock owner
field" depends on who or what you assume will consume this information.  If
the consumer is a person, then the contents of this field could be quite
minimal. In many collaboration scenarios, a simple string giving the
person's name (or alias they employ when using the system) would suffice to
let other collaborators know who has the lock. If there is a potentially
large number of collaborators, it might be nice to have some additional
contact information, like a phone number, email address, or a Web page, but
this isn't strictly necessary. People usually know who could potentially
take out a lock on a resource.  Knowing this set of people, it requires
little additional information to determine exactly who, from that set, has
the lock.

So, for a human consumer, the goals of the lock owner field are (a) to
identify the collaborator who took out the lock, and (b) to provide some
means of contacting them.  While the principal URLs used in the ACL
specification are certainly identifiers, they're not particulary
human-readable, unless the client knows to go grab the displayname property
off of the identified resource. In retrospect, the choice of placing URLs in
the lock owner field is not a great one, since popping a URL up in someone's
face isn't very helpful. What should they do with it? It's not clear.

If you're assuming the consumer of the information is a computational
process (either the client, or an agent), then the need for more structured
information in the lock owner field is necessary. For a computational
process, the principal URL from the ACL spec. makes more sense, since this
is a machine parseable identifier for the person.

What should we do here?  Well, certainly 2518 should be clarified to
indicate that the client controls this string, and the server must preserve
it exactly. This is the de-facto case today.  Additionally, We should move
away from the use of URLs in the lock owner, in favor of having a single
human-readable string that identifies the principal, and possibly also
provides some contact information.  It should be allowed to use an alias,
instead of your real name or username, to address privacy/security concerns.
If an alias is used, it is the responsibility of the person using the alias
to communicate this alias to other collaborators.

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 30 Sep 2001 14:46:19 +0200

> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Friday, September 28, 2001 12:10 AM
> To: Webdav WG
> ...

I think it makes sense to report a set of URLs (for instance phone number,
email address, homepage). Which URL is which could be flagged using the
xlink:role attribute
(<http://www.w3.org/TR/2001/REC-xlink-20010627/#link-semantics>). A user
agent can then  select the type of links it can process (for instance
offering to invoke the mail program or to issue a phone call).

> ...