RE: RFC2518 issue with lockdiscovery/activelock/owner

Julian Reschke writes:
> 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 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

Received on Thursday, 27 September 2001 18:13:06 UTC