Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER

From: "Jason Crawford" <[email-masked]>
Date: Tue, 8 Jan 2002 17:53:49 -0500

All,
   Dan and Lisa have suggested that we need to more clearly define either
the use of the lockowner field or that we need a way to identify the owner
of the lock.

  http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html
says...

> > (Especially because the spec provides
> > no way to reliably determine who owns a lock.)

> This is a good point -- and this is already a failing of WebDAV, with or
> without UNLOCK_BY_NON_LOCK_OWNER.  Clients that crash or miss the
response
> from the server need to make sure that the lock is theirs before grabbing
> the lock token using PROPFIND.  Can lockowner be used for this purpose?

> This should be a separate RFC2518 issue.  How about
> "HOW_TO_IDENTIFY_LOCK_OWNER".

Just as a point of information, I'd like to point out we have an issue on
the issues
list that is somewhat related: DEFINE_PRINCIPAL.
In that issue Mark D Anderson says:

  The term "principal" is never defined in the WebDAV
   specification, or the HTTP or Digest specifications.
   It should be defined.

Lisa and Dan,
  Could you define the requirement before we start the discussion?  For
example, is it for the server or the client that we need to make the
clarification below?  (I'll reference your clarfication from the issues
list.)

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: Daniel Brotsky <[email-masked]>
Date: Tue, 8 Jan 2002 22:18:23 -0800

I think there are a variety of client needs here.  These are probably 
a little too fuzzy to be called requirements :^), but it's the best I 
can do right now.

1. This came up at the first interop, and most servers seemed to be 
compliant by the second interop:

The <owner> part of a lock is to be completely controlled by the 
client.  The server MUST not alter it (i.e., lock discovery, if it 
returns the <owner> information, must return exactly equivalent XML 
to that in the LOCK request).

There's a lot of discussion of why this is needed in the archives; 
the gist is that it's the only client-controlled XML that's always 
associated with a LOCK, so clients of a given ilk can use it to 
exchange conventional information with each other about the lock.

2. There's some well-known specification of "principal" in the sense 
of "authenticated user ID whose authorization is being used for the 
current request."  Probably this is a string of some kind, and 
probably there are localization issues so we will want this string to 
be in a known encoding (e.g., UTF-8) or else all mechanisms that 
return this string must be able to return the encoding.

3. Clients need to know/be able to discover which "principal" they 
are.  I don't really know enough about the range of authentication 
schemes to understand whether clients can always know for sure what 
"principal" the server is associating with them based on the 
client-generated authentication header, or whether the client might 
simply have been given some set of opaque credentials and need the 
server to tell it which "principal" those credentials make it.

4. Clients need to know/be able to discover which "principal" owns a 
given lock, that is, which principal made the original lock request.

5. Clients need to know/be able to discover where the "root resource" 
of a lock is; that is, the resource on which the lock owner can do an 
UNLOCK of the right depth and get the lock released.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>