Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 18 Jan 2002 14:28:17 -0500

I would describe our conclusion as:

We need to define a new field, say DAV:lockowner, that is specified
in a LOCK request, and that takes an XML value.  We will define
some standard elements for that value.

We should then deprecate the use of the DAV:owner field, as a field
that contains non-interoperable data about the lock owner.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Friday, January 18, 2002 1:35 PM
To: Daniel Brotsky; [email-masked]; Lisa Dusseault
Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER

It sounds like we've concluded that we can't reuse the lockowner field
because we've already specified that it's free text.

Do we still have the requirement mentioned at...

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

regarding identifying the owner of a lock?  If so, now that we've had some
discussion on this topic, can someone provide an improved definition of the
requirement?    And a proposal?  Dan?  Lisa? Geoff?  Julian?

J.

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

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 19 Jan 2002 21:38:33 +0100

Sounds good.

I think we should also consider defining standard LOCK privileges.

Here's a proposal for DAV:lockowner (I take the freedom to rename it):

<contact-URI-set xmlns="DAV:" xmlns:xlink="http://www.w3.org/1999/xlink">
  <contact-URI
xlink:href="mailto:[email-masked]">EMail</contact-URI>
  <contact-URI xlink:href="tel:+492512807760">Work Phone</contact-URI>
</contact-URI-set>

DTD fragment:

<!ELEMENT contact-URI-set (contact-URI*)>
<!ELEMENT contact-URI #PCDATA>
<!-- contains human-displayable information qualifying the link -->
<!ATTLIST contact-URI
	xlink:type      (simple)        #FIXED "simple"
  	xlink:href      CDATA           #IMPLIED
  	xlink:role      CDATA           #IMPLIED
  	xlink:title     CDATA           #IMPLIED>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Friday, January 18, 2002 8:28 PM
> To: [email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 21 Jan 2002 21:21:09 -0800

What I would find most useful would be a lock owner field with a value
defined by the server.  Since the server is likely to have authenticated the
user, they presumably know how to identify the user.  Existing support for
the ACLs spec would mean that a Principal URL could be available.  Allowing
the server to set this value means that the information is more reliable.

Lisa

> Sent: Friday, January 18, 2002 11:28 AM

---

From: Daniel Brotsky <[email-masked]>
Date: Fri, 25 Jan 2002 08:54:33 -0800

(Sorry for the delay in this reply; I've been away from mail for a week.)

>I would describe our conclusion as:

Yow.  Unfortunately I would describe it in almost opposite terms...

>some standard elements for that value.

I would have said our conclusion was:

We need to define a new XML-valued field, say DAV:lockowner, that is 
owned by the server and returned as part of lockdiscovery.  We will 
define some standard elements for that value which the server can use 
to reveal as much or as little as it wants about:

- the principal owning the lock (e.g., a "login name")
- the relationship between the owning principal and the requesting 
principal (e.g., requestor is/is not the owner)
- the capabilities of the requestor with respect to the lock (e.g., 
requestor has/has not the same capabilities as the owner; requestor 
has/has not the ability to use or unlock the lock).

>that contains non-interoperable data about the lock owner.

I would have said:

We then need to explicitly reserve the use of the DAV:owner field to 
be for clients to use at lock request time (in order to provide for 
client-to-client conventional communication).  We need to forbid 
servers from rewriting the client-specified value (other than 
clarifying that the DAV:owner field is XML-valued, and thus subject 
to parsing/regeneration by the server).

We then need to resolve the issue about whether the client can 
rewrite the lock:owner field as part of a lock refresh request.  (I 
believe this was an outstanding issue as to whether clients can 
change any aspect of a lock in a refresh request.)  I would recommend 
that clients be able to do this.

     dan

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

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 26 Jan 2002 11:56:58 +0100

Daniel,

I think you need to go back again through the mails that were exchanged.

My summary:

a) We agree that server-supplied information (if at allI) should be handled
by ACL locking privileges. I think we also have an agreement that locking
privileges should become part of the ACL draft/spec.

b) The current DAV:owner element is something that the client sets and MUST
not be touched by the server. However, it's contents is undefined and thus
can't be used for interoperability *between* clients. Q: do we want to
deprecate it because of this?

c) Because of b), we need a new client-supplied lock owner information
element, in which it reveals whatever the user of the client software wants
to reveal using a *standard* format (so that one client can actually
*process* the information a different client has set). My initital proposal
for this format is:

<contact-URI-set xmlns="DAV:" xmlns:xlink="http://www.w3.org/1999/xlink"
xml:lang="en">
  <contact-URI
xlink:href="mailto:[email-masked]">EMail</contact-URI>
  <contact-URI xlink:href="tel:+492512807760">Work Phone</contact-URI>
</contact-URI-set>

DTD fragment:

> [mailto:[email-masked]]On Behalf Of Daniel Brotsky
> Sent: Friday, January 25, 2002 5:55 PM
> To: Clemm, Geoff
> Cc: [email-masked]