RE: RFC2518 issue with lockdiscovery/activelock/owner

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:julian.reschke@gmx.de]
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: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]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:julian.reschke@gmx.de]
> 
> 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.
>

Received on Thursday, 27 September 2001 10:13:20 UTC