RE: HOW_TO_IDENTIFY_LOCK_OWNER

I agree with Julian's expanded summary.  In particular, although 
a "server generated lock principal property" has been proposed, this
proposal has had strong opposition (for security and ACL related reasons
that are detailed in this email thread),
while the additional client-defined owner
field with a standard format was acceptable to everyone (at least,
nobody objected, and several people support it).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Saturday, January 26, 2002 5:57 AM
To: w3c-dist-auth@w3c.org
Cc: Daniel Brotsky
Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER


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:julian.reschke@greenbytes.de">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>




> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky
> Sent: Friday, January 25, 2002 5:55 PM
> To: Clemm, Geoff
> Cc: w3c-dist-auth@w3c.org
> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER
>
>
> (Sorry for the delay in this reply; I've been away from mail for a week.)
>
> At 2:28 PM -0500 1/18/02, Clemm, Geoff wrote:
> >I would describe our conclusion as:
>
> Yow.  Unfortunately I would describe it in almost opposite terms...
>
> >
> >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.
>
> 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).
>
> >
> >We should then deprecate the use of the DAV:owner field, as a field
> >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
>
> >
> >Cheers,
> >Geoff
> >
> >-----Original Message-----
> >From: Jason Crawford [mailto:ccjason@us.ibm.com]
> >Sent: Friday, January 18, 2002 1:35 PM
> >To: Daniel Brotsky; w3c-dist-auth@w3c.org; 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,   ccjason@us.ibm.com
>
>
> --
> Daniel Brotsky, Adobe Systems
> tel 408-536-4150, pager 877-704-4062
> 2-way pager email: <mailto:page-dbrotsky@adobe.com>
>

Received on Sunday, 27 January 2002 09:39:51 UTC