From w3c-dist-auth-request@w3.org Sun Sep 2 17:24:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13931 for ; Sun, 2 Sep 2001 17:24:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA22013; Sun, 2 Sep 2001 17:23:11 -0400 (EDT) Resent-Date: Sun, 2 Sep 2001 17:23:11 -0400 (EDT) Resent-Message-Id: <200109022123.RAA22013@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA21976 for ; Sun, 2 Sep 2001 17:23:03 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA04802 for ; Sun, 2 Sep 2001 17:23:04 -0400 Received: from beaver ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f82LN0K44211; Sun, 2 Sep 2001 14:23:00 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "DeltaV" , "Webdav WG" Date: Sun, 2 Sep 2001 14:22:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: DeltaV and ACL supported on Sharemation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5335 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Xythos WFS 3.1 has DeltaV and ACL support, and we've upgraded Sharemation recently to this latest version. Test accounts are available free on www.sharemation.com, where some Web tools are available to examine access control and versioning information. You can also test client WebDAV applications against Sharemation accounts. From the DeltaV spec we support - basic versioning features - version-control - checkout in-place - version-history - working-resource WFS does not support forking. WFS allows versions to be deleted. From the ACL spec: - principal URL space - various ACL-related properties on resources - the ACL method WFS supports a custom set of privileges that map to the canonical list. Lisa Dusseault Xythos From w3c-dist-auth-request@w3.org Wed Sep 5 11:07:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06641 for ; Wed, 5 Sep 2001 11:07:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA18194; Wed, 5 Sep 2001 11:02:28 -0400 (EDT) Resent-Date: Wed, 5 Sep 2001 11:02:28 -0400 (EDT) Resent-Message-Id: <200109051502.LAA18194@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA18172 for ; Wed, 5 Sep 2001 11:02:10 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA19316 for ; Wed, 5 Sep 2001 11:02:11 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA302398 for ; Wed, 5 Sep 2001 10:59:22 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f85ErTj108854 for ; Wed, 5 Sep 2001 10:53:29 -0400 To: Webdav WG X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 5 Sep 2001 10:54:26 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 09/05/2001 11:01:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5336 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hey WebDAV'ers, A couple of the disagreeing parties (JimW, GeoffC, LisaD) put there heads together to come up with a compromise on the issue of allowing non-lock owners to UNLOCK a resouce. The compromise is that the following items should be said in the spec. - A server MAY allow principals other than a lock owner to unlock a resource - If a server supports the unlocking of a resource by someone other than the lock owner, this capability SHOULD be under access control. - There is a tradeoff in allowing non-owners of a lock to unlock a resource. It can be beneficial to allow non-lock owners to perform UNLOCK requests because it allows the adminstrator of the server to configure the server to grant longer lock timeouts because the administrator knows that there is a process in place to allow users to deal with forgotten locks left by other users. On the other hand, a disadvantage of unlocking someone else's lock is that can create a situation where two users are working on modifications to the same resource at the same time which can result in a client having to perform an merge that wasn't previously planned. If we have a consensus around this, the wording that we will use will be very close to this. If you have any comments on the position or wording, please speak up. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Sep 5 12:04:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09162 for ; Wed, 5 Sep 2001 12:04:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA21292; Wed, 5 Sep 2001 12:00:11 -0400 (EDT) Resent-Date: Wed, 5 Sep 2001 12:00:11 -0400 (EDT) Resent-Message-Id: <200109051600.MAA21292@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA21243 for ; Wed, 5 Sep 2001 11:59:52 -0400 (EDT) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA27359 for ; Wed, 5 Sep 2001 11:59:52 -0400 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id f85Fwr118182 for ; Wed, 5 Sep 2001 08:58:53 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f85Fwrb18103 for ; Wed, 5 Sep 2001 08:58:53 -0700 (PDT) Received: from [192.168.1.19] ([130.248.184.88]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GJ75QK00.R0L for ; Wed, 5 Sep 2001 08:59:08 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Wed, 5 Sep 2001 08:59:04 -0700 To: Webdav WG From: Daniel Brotsky Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5337 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Sorry not to weigh in sooner; I've been underwater. 1. While I agree with what Jason sent as a "position statement," it feels like it misses the issues that a protocol spec needs to address: a. Of course servers may allow principals other than a lock owner to unlock a resource: servers can do whatever they want with locks. The question for the spec is: *how* do they allow this? b. Of course if a server allows principals to do something, and the server supports access control, then the allowance should be under access control: it's only logical. The question for the spec is: *how* is it under access control? c. Of course there are tradeoffs around any authorization policy. The question for the spec is: are there any *requirements* on servers that choose one policy or the other? 2. As to a: I believe that using the exact same syntax for UNLOCK regardless of whether you own the lock (or just have permission to blow locks away) would be very error-prone. It would mean that clients that routinely do lock discovery (rather than remembering tokens) could easily blow away others' locks when they thought they were just unlocking their own. (Especially because the spec provides no way to reliably determine who owns a lock.) So I believe we need some mechanism for saying, in an UNLOCK call, that I expect the lock to be owned by someone else and I want to unlock it anyway. (And this form would fail if I owned the lock.) 3. As to b: Does the ACL spec talk specifically about a "remove someone else's lock" permission? Are there constraints about whether or not this is tied to having the permission to lock the resource? Or write it? Also, we have experimented with servers that, while they don't allow one user to unlock another's lock via DAV (because we interpreted the spec as forbidding that), will in fact honor a LOCK request from one (adminstrative) user by simply blowing another user's lock away. This not only is an entirely different mechanism for unlocking, it raises a host of ACL-related questions. 4. As to c: Are we going to require servers that allow unlocking to grant long timeouts? Are we going to require that servers which allow unlocks grant "implicit" unlocks (as described in the last paragraph)? I suspect not, but I don't think the spec is really the place for speculation about tradeoffs. We would need to rewrite any such talk to be design rationale for allowing unlocking by others. As you can see, I think we're a ways from an operable concensus around this issue. I think there are a raft of important questions that get opened by allowing explicit unlocking, and I'm not at all sure we have enough experience to actually move the spec this way at this point. It might be way better to simply confirm that servers MUST refuse a standard-form UNLOCK call from a non lock-owner (just as they MUST refuse a PUT by a non lock-owner). Servers that then wish to allow administrative unlocking could still do so via proprietary extensions (a non-standard form of UNLOCK, for example), but the spec wouldn't be in the position of trying to legislate administrative procedures that we don't yet have agreement about. dan At 10:54 AM -0400 9/5/01, Jason Crawford wrote: >Hey WebDAV'ers, > A couple of the disagreeing parties (JimW, GeoffC, LisaD) put there >heads together to come up with a compromise on the issue of allowing >non-lock owners to UNLOCK a resouce. The compromise is that the following >items should be said in the spec. > >- A server MAY allow principals other than a lock owner to unlock a >resource >- If a server supports the unlocking of a resource by someone other than >the lock owner, this capability SHOULD be under access control. >- There is a tradeoff in allowing non-owners of a lock to unlock a >resource. It can be beneficial to allow non-lock owners to perform UNLOCK >requests because it allows the adminstrator of the server to configure the >server to grant longer lock timeouts because the administrator knows that >there is a process in place to allow users to deal with forgotten locks >left by other users. On the other hand, a disadvantage of unlocking >someone else's lock is that can create a situation where two users are >working on modifications to the same resource at the same time which can >result in a client having to perform an merge that wasn't previously >planned. > >If we have a consensus around this, the wording that we will use will be >very close to this. If you have any comments on the position or wording, >please speak up. > >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: From w3c-dist-auth-request@w3.org Wed Sep 5 12:18:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09844 for ; Wed, 5 Sep 2001 12:18:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA21939; Wed, 5 Sep 2001 12:13:07 -0400 (EDT) Resent-Date: Wed, 5 Sep 2001 12:13:07 -0400 (EDT) Resent-Message-Id: <200109051613.MAA21939@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA21914 for ; Wed, 5 Sep 2001 12:13:01 -0400 (EDT) Received: from nike.mediafactory.de ([194.25.116.194]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA29218 for ; Wed, 5 Sep 2001 12:13:01 -0400 Message-Id: <200109051613.MAA29218@tux.w3.org> Received: FROM nike BY nike.mediafactory.de ; Wed Sep 05 18:12:26 2001 +0200 From: "Henrik Genssen" To: Date: Wed, 5 Sep 2001 18:12:53 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F7_01C13636.61A63160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Server Accept-Encoding Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5338 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_01F7_01C13636.61A63160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How does a client determine what kind of encodings the server supports? e.g. deflate/gzip for a PUT/POST statement hg ------=_NextPart_000_01F7_01C13636.61A63160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How does a client determine what kind of encodings = the server=20 supports?
e.g. deflate/gzip for a PUT/POST = statement
 
hg
------=_NextPart_000_01F7_01C13636.61A63160-- From w3c-dist-auth-request@w3.org Wed Sep 5 18:28:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23762 for ; Wed, 5 Sep 2001 18:28:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA12404; Wed, 5 Sep 2001 18:29:03 -0400 (EDT) Resent-Date: Wed, 5 Sep 2001 18:29:03 -0400 (EDT) Resent-Message-Id: <200109052229.SAA12404@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA12381 for ; Wed, 5 Sep 2001 18:28:57 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA05530 for ; Wed, 5 Sep 2001 18:28:57 -0400 Received: from beaver (guest217.lyra.org [198.144.203.217]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f85MSsb63015 for ; Wed, 5 Sep 2001 15:28:54 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Webdav WG" Date: Wed, 5 Sep 2001 15:28:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: PROPPATCH response with 201? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5339 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greg & I find 2518 a little confusing on this issue: "Status Codes for use with 207 (Multi-Status) The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. 200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate. " Why is 201 inappropriate inside a 207? Wouldn't it be potentially useful to a client to know when a property was created vs. modified? If there's some reason why 201 is inappropriate inside a 207 (which I can't see), then all properties mods will be reported with a 200 OK. Why not just use 200 OK for the overall message response, omitting the body? (remember PROPPATCH is atomic) If this just needs a mite of clarification, perhaps we can put it on the issues list for 2518. Lisa From w3c-dist-auth-request@w3.org Wed Sep 5 19:49:52 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25092 for ; Wed, 5 Sep 2001 19:49:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA14520; Wed, 5 Sep 2001 19:49:32 -0400 (EDT) Resent-Date: Wed, 5 Sep 2001 19:49:32 -0400 (EDT) Resent-Message-Id: <200109052349.TAA14520@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA14498 for ; Wed, 5 Sep 2001 19:49:26 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA11402 for ; Wed, 5 Sep 2001 19:49:25 -0400 Received: from beaver (guest217.lyra.org [198.144.203.217]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f85NnGb69645; Wed, 5 Sep 2001 16:49:16 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Daniel Brotsky" , "Webdav WG" Date: Wed, 5 Sep 2001 16:49:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5340 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > a. Of course servers may allow principals other than a lock owner to > unlock a resource: servers can do whatever they want with locks. The > question for the spec is: *how* do they allow this? I'd assumed this would be the same way any user does an UNLOCK. I don't think there's any need to define a new syntax (more on this later in the email). Xythos WFS supports UNLOCK by the resource owner as well as by the lock creator. The resource owner must do PROPFIND "DAV:lockdiscovery" first to find out what the lock token is, then remove it. > b. Of course if a server allows principals to do something, and the > server supports access control, then the allowance should be under > access control: it's only logical. The question for the spec is: > *how* is it under access control? Not everything that is allowed by WebDAV has its own privilege in DAV ACLs. Note particularly that the ability to LOCK the file isn't covered by its own privilege! A server might implement the privilege to blow away another's lock as part of the write-acl privilege. Of course, the ACL framework is flexible enough to allow servers to define sub-privileges. Eg 1: custom:lock, custom:delete and custom:write might be separate custom privileges that are covered under the framework of the DAV:write privilege. Eg 2: custom:unlock and custom:set-privilege might be custom privileges that are covered under the framework of the DAV:write-acl privilege. WFS has implemented unlock-by-non-lock-owners to be allowed only by the owner of the resource. I don't think this needs to be part of the ACL spec right now. An extension to the ACL spec might be useful, once ACL is done. > c. Of course there are tradeoffs around any authorization policy. > The question for the spec is: are there any *requirements* on servers > that choose one policy or the other? Yes. Xythos WFS requires the ability for a resource owner to remove a lock that was created by some other user. This must be accessible over WebDAV because resource owners don't have administrative access to the system. The primary reason this is a requirement is because resource owners have limited quotas. If they can't blow away a lock created by some other user, then they can't delete the resource and free up space when they reach their quota. Even on systems without quotas, the goal of minimizing administrative costs requires this feature. It's too costly for users to be phoning the support staff every time they need a lock removed for some "urgent" reason. > 2. As to a: I believe that using the exact same syntax for UNLOCK > regardless of whether you own the lock (or just have permission to > blow locks away) would be very error-prone. It would mean that > clients that routinely do lock discovery (rather than remembering > tokens) could easily blow away others' locks when they thought they > were just unlocking their own. Clients should NEVER EVER do this, regardless of whether the server supports this UNLOCK-by-non-lock-owner. That would mean that the client is relying on access control of the server to regulate whether or not it may blow away the lock. That fails in the simple case when the user has two software applications that both support DAV! If I'm using Windows Word with Web Folders to open and lock a file, then I start up Acrobat to see if I can view the same file I'm editing, it would be wrong for Acrobat to grab the lock and allow edits. That kind of unpredictability is unacceptable. > (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". > So I believe we need > some mechanism for saying, in an UNLOCK call, that I expect the lock > to be owned by someone else and I want to unlock it anyway. (And > this form would fail if I owned the lock.) If we solve the problem of telling what client created the lock, which I've pointed out we ought to solve anyway, we wouldn't have to add syntax to the UNLOCK call. > As you can see, I think we're a ways from an operable concensus > around this issue. I think there are a raft of important questions > that get opened by allowing explicit unlocking, I hope I've answered a few of those questions, although I agree a new RFC2518 issue must be raised (HOW_TO_IDENTIFY_LOCK_OWNER). If we solve that question, I don't see any further open issues that would prevent UNLOCK_BY_NON_LOCK_OWNER. Lisa From w3c-dist-auth-request@w3.org Thu Sep 6 01:05:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01462 for ; Thu, 6 Sep 2001 01:05:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA24076; Thu, 6 Sep 2001 01:04:02 -0400 (EDT) Resent-Date: Thu, 6 Sep 2001 01:04:02 -0400 (EDT) Resent-Message-Id: <200109060504.BAA24076@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA24056 for ; Thu, 6 Sep 2001 01:03:52 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37133.rational.com [192.229.37.133]) by tux.w3.org (8.9.3/8.9.3) with SMTP id BAA03976 for ; Thu, 6 Sep 2001 01:03:53 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 06 Sep 2001 01:14:48 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 01:14:48 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1042AB278@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Thu, 6 Sep 2001 01:14:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5341 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Lisa's response, especially the fact that a client should never grab a lock token just because it is visible, and try to use it (whether or not you are the "owner" of that lock token). The only use of a lock token that has been "discovered" should be for an UNLOCK, after an explicit dialog with the user confirming that overriding the lock is what is wanted. As for discovering who is the lock owner, that is what the DAV:owner element in the lock discovery property is for. This information is to be displayed to the user (e.g. to indicate that the write failed because "a lock is held by xxx", or to ask "do you want to override the lock held by xxx"). Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Wednesday, September 05, 2001 7:49 PM To: Daniel Brotsky; Webdav WG Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > a. Of course servers may allow principals other than a lock owner to > unlock a resource: servers can do whatever they want with locks. The > question for the spec is: *how* do they allow this? I'd assumed this would be the same way any user does an UNLOCK. I don't think there's any need to define a new syntax (more on this later in the email). Xythos WFS supports UNLOCK by the resource owner as well as by the lock creator. The resource owner must do PROPFIND "DAV:lockdiscovery" first to find out what the lock token is, then remove it. > b. Of course if a server allows principals to do something, and the > server supports access control, then the allowance should be under > access control: it's only logical. The question for the spec is: > *how* is it under access control? Not everything that is allowed by WebDAV has its own privilege in DAV ACLs. Note particularly that the ability to LOCK the file isn't covered by its own privilege! A server might implement the privilege to blow away another's lock as part of the write-acl privilege. Of course, the ACL framework is flexible enough to allow servers to define sub-privileges. Eg 1: custom:lock, custom:delete and custom:write might be separate custom privileges that are covered under the framework of the DAV:write privilege. Eg 2: custom:unlock and custom:set-privilege might be custom privileges that are covered under the framework of the DAV:write-acl privilege. WFS has implemented unlock-by-non-lock-owners to be allowed only by the owner of the resource. I don't think this needs to be part of the ACL spec right now. An extension to the ACL spec might be useful, once ACL is done. > c. Of course there are tradeoffs around any authorization policy. > The question for the spec is: are there any *requirements* on servers > that choose one policy or the other? Yes. Xythos WFS requires the ability for a resource owner to remove a lock that was created by some other user. This must be accessible over WebDAV because resource owners don't have administrative access to the system. The primary reason this is a requirement is because resource owners have limited quotas. If they can't blow away a lock created by some other user, then they can't delete the resource and free up space when they reach their quota. Even on systems without quotas, the goal of minimizing administrative costs requires this feature. It's too costly for users to be phoning the support staff every time they need a lock removed for some "urgent" reason. > 2. As to a: I believe that using the exact same syntax for UNLOCK > regardless of whether you own the lock (or just have permission to > blow locks away) would be very error-prone. It would mean that > clients that routinely do lock discovery (rather than remembering > tokens) could easily blow away others' locks when they thought they > were just unlocking their own. Clients should NEVER EVER do this, regardless of whether the server supports this UNLOCK-by-non-lock-owner. That would mean that the client is relying on access control of the server to regulate whether or not it may blow away the lock. That fails in the simple case when the user has two software applications that both support DAV! If I'm using Windows Word with Web Folders to open and lock a file, then I start up Acrobat to see if I can view the same file I'm editing, it would be wrong for Acrobat to grab the lock and allow edits. That kind of unpredictability is unacceptable. > (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". > So I believe we need > some mechanism for saying, in an UNLOCK call, that I expect the lock > to be owned by someone else and I want to unlock it anyway. (And > this form would fail if I owned the lock.) If we solve the problem of telling what client created the lock, which I've pointed out we ought to solve anyway, we wouldn't have to add syntax to the UNLOCK call. > As you can see, I think we're a ways from an operable concensus > around this issue. I think there are a raft of important questions > that get opened by allowing explicit unlocking, I hope I've answered a few of those questions, although I agree a new RFC2518 issue must be raised (HOW_TO_IDENTIFY_LOCK_OWNER). If we solve that question, I don't see any further open issues that would prevent UNLOCK_BY_NON_LOCK_OWNER. Lisa From w3c-dist-auth-request@w3.org Thu Sep 6 11:44:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00774 for ; Thu, 6 Sep 2001 11:44:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA21673; Thu, 6 Sep 2001 11:44:12 -0400 (EDT) Resent-Date: Thu, 6 Sep 2001 11:44:12 -0400 (EDT) Resent-Message-Id: <200109061544.LAA21673@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA21636 for ; Thu, 6 Sep 2001 11:43:59 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37133.rational.com [192.229.37.133]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA32020 for ; Thu, 6 Sep 2001 11:43:59 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 06 Sep 2001 11:54:53 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 11:54:53 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1042AB360@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Thu, 6 Sep 2001 11:54:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PROPPATCH response with 201? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5343 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Normally (according to 2616), a 201 indicates that a new resource has been created on the server. Unless you consider a property to itself be a resource, it would then be misleading to return a 201 for the addition of a property. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Wednesday, September 05, 2001 6:29 PM To: Webdav WG Subject: PROPPATCH response with 201? Greg & I find 2518 a little confusing on this issue: "Status Codes for use with 207 (Multi-Status) The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. 200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate. " Why is 201 inappropriate inside a 207? Wouldn't it be potentially useful to a client to know when a property was created vs. modified? If there's some reason why 201 is inappropriate inside a 207 (which I can't see), then all properties mods will be reported with a 200 OK. Why not just use 200 OK for the overall message response, omitting the body? (remember PROPPATCH is atomic) If this just needs a mite of clarification, perhaps we can put it on the issues list for 2518. Lisa From w3c-dist-auth-request@w3.org Thu Sep 6 11:44:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00785 for ; Thu, 6 Sep 2001 11:44:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA21652; Thu, 6 Sep 2001 11:44:02 -0400 (EDT) Resent-Date: Thu, 6 Sep 2001 11:44:02 -0400 (EDT) Resent-Message-Id: <200109061544.LAA21652@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA21616 for ; Thu, 6 Sep 2001 11:43:55 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA32018 for ; Thu, 6 Sep 2001 11:43:55 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA453256 for ; Thu, 6 Sep 2001 11:41:09 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f86FZGa226678 for ; Thu, 6 Sep 2001 11:35:16 -0400 To: "Webdav WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 6 Sep 2001 11:26:49 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 09/06/2001 11:43:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5342 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Do we need to clarify what status codes the UNLOCK can return now that we've added a new possibility? Right now I don't think rfc2518 documents any UNLOCK status codes. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Sep 6 18:22:52 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10221 for ; Thu, 6 Sep 2001 18:22:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA12140; Thu, 6 Sep 2001 18:22:30 -0400 (EDT) Resent-Date: Thu, 6 Sep 2001 18:22:30 -0400 (EDT) Resent-Message-Id: <200109062222.SAA12140@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA12100 for ; Thu, 6 Sep 2001 18:22:19 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA14819 for ; Thu, 6 Sep 2001 18:22:12 -0400 Received: from [216.36.75.111] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 6143929; Thu, 06 Sep 2001 15:15:04 -0700 From: "Lisa Dusseault" To: =?iso-8859-1?Q?J=F6sh_Cohen?= , , Cc: "Webdav WG" Date: Thu, 6 Sep 2001 15:21:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Subject: RE: WebDAV Invalidation (Was Re: Allow: header and supported methods) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5344 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'd definitely be interested in working on notifications. We'd like clients to be able to know about events like the ones you suggest, plus: - new resource in collection I'm subscribed to - Access control change in resource I'm subscribed to - New version in VCR (similar to your update/last-modified event, perhaps equivalent) How do we proceed? lisa > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jösh Cohen > Sent: Wednesday, August 29, 2001 12:26 PM > To: deltav@wegalink.de; ietf-dav-versioning@w3.org > Subject: Re: WebDAV Invalidation (Was Re: Allow: header and supported > methods) > > > While Im nervous about trying to boil the ocean > in the form of a 'general notifications protocol', Im > wondering what people think about including the ability > to subscribe to events on resources? > By this I mean, in short, being able to subscribe > to a resource, such that when things happen to it, > such as: > o property change > o update (last modified) > o invalidate > o lock expiration / lock override > o deleted > > a subscribed entity would receive a notification. > > There's been some relevant work here in the form of > an HTTP extension (SUBSCRIBE/NOTIFY methods) in the past > to deal with some of these issues. It was work that > was previously done in the context of using HTTP for IM > and it quite similar to the SIP subscription extensions. > > Does this sound at all like something the group > would be interested in taking a closer look at ? > > thanks, > > --- > Josh > > > > >From: "Eckhard Kantz" > >To: > >Subject: Re: WebDAV Invalidation (Was Re: Allow: header and supported > >methods) > >Date: Wed, 22 Aug 2001 21:40:39 +0200 > > > >The protocol described in the ESI document allows to invalidate > documents > >that have been downloaded > >to a local machine by applying a push technology. This could > solve already > >several conflict > >situations or even partly prevent problems. > > > >On the other hand there seems to be an increasing need for more > >fine-grained notification services > >that extend the traditional access control systems. Picture 1 in the > >following longer article tries > >to classify them: > > > >"Beyond 'Yes or No' - Extending Access Control in Groupware with > >Negotiation and Awareness" > >(http://www.informatik.uni-bonn.de/~os/Publications/COOP98a.ps) > > > >Maybe those needs are also worth discussing if they could be > supported in > >the spec in order to allow > >applications to build up on them. The invalidation protocol > seems to be a > >good basis also for this. > > > >Eckhard > > > > > >-----Ursprüngliche Nachricht----- > >Von: Eric Sedlar > >An: ietf-dav-versioning@w3.org > >Gesendet: Dienstag, 21. August 2001 19:00 > >Betreff: WebDAV Invalidation (Was Re: Allow: header and > supported methods) > > > > > >Check out > >http://www.esi.org/invalidation_protocol_1-0.html for some work > that looks > >pretty similar > >to what we are talking about. > > > >--Eric > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From w3c-dist-auth-request@w3.org Thu Sep 6 20:40:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12916 for ; Thu, 6 Sep 2001 20:40:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA18387; Thu, 6 Sep 2001 20:40:33 -0400 (EDT) Resent-Date: Thu, 6 Sep 2001 20:40:33 -0400 (EDT) Resent-Message-Id: <200109070040.UAA18387@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA18352 for ; Thu, 6 Sep 2001 20:40:26 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA26248 for ; Thu, 6 Sep 2001 20:40:26 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA39480 for ; Thu, 6 Sep 2001 19:38:11 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f870ePu200074 for ; Thu, 6 Sep 2001 20:40:25 -0400 To: w3c-dist-auth@w3c.org, ietf-dav-versioning@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jim Amsden" Date: Thu, 6 Sep 2001 20:34:07 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 09/06/2001 08:40:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id UAA18352 Subject: RE: WebDAV Invalidation (Was Re: Allow: header and supported methods) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5345 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'll schedule a BOF at the next IETF meeting. If there's enough interest, we can create a proposed charter and petition the area directors for a new working group. "Lisa Dusseault" To: =?iso-8859-1?Q?J=F6sh_Cohen?= , Sent by: , ietf-dav-versioning-requ cc: "Webdav WG" est@w3.org Subject: RE: WebDAV Invalidation (Was Re: Allow: header and supported methods) 09/06/2001 06:21 PM I'd definitely be interested in working on notifications. We'd like clients to be able to know about events like the ones you suggest, plus: - new resource in collection I'm subscribed to - Access control change in resource I'm subscribed to - New version in VCR (similar to your update/last-modified event, perhaps equivalent) How do we proceed? lisa > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jösh Cohen > Sent: Wednesday, August 29, 2001 12:26 PM > To: deltav@wegalink.de; ietf-dav-versioning@w3.org > Subject: Re: WebDAV Invalidation (Was Re: Allow: header and supported > methods) > > > While Im nervous about trying to boil the ocean > in the form of a 'general notifications protocol', Im > wondering what people think about including the ability > to subscribe to events on resources? > By this I mean, in short, being able to subscribe > to a resource, such that when things happen to it, > such as: > o property change > o update (last modified) > o invalidate > o lock expiration / lock override > o deleted > > a subscribed entity would receive a notification. > > There's been some relevant work here in the form of > an HTTP extension (SUBSCRIBE/NOTIFY methods) in the past > to deal with some of these issues. It was work that > was previously done in the context of using HTTP for IM > and it quite similar to the SIP subscription extensions. > > Does this sound at all like something the group > would be interested in taking a closer look at ? > > thanks, > > --- > Josh > > > > >From: "Eckhard Kantz" > >To: > >Subject: Re: WebDAV Invalidation (Was Re: Allow: header and supported > >methods) > >Date: Wed, 22 Aug 2001 21:40:39 +0200 > > > >The protocol described in the ESI document allows to invalidate > documents > >that have been downloaded > >to a local machine by applying a push technology. This could > solve already > >several conflict > >situations or even partly prevent problems. > > > >On the other hand there seems to be an increasing need for more > >fine-grained notification services > >that extend the traditional access control systems. Picture 1 in the > >following longer article tries > >to classify them: > > > >"Beyond 'Yes or No' - Extending Access Control in Groupware with > >Negotiation and Awareness" > >(http://www.informatik.uni-bonn.de/~os/Publications/COOP98a.ps) > > > >Maybe those needs are also worth discussing if they could be > supported in > >the spec in order to allow > >applications to build up on them. The invalidation protocol > seems to be a > >good basis also for this. > > > >Eckhard > > > > > >-----Ursprüngliche Nachricht----- > >Von: Eric Sedlar > >An: ietf-dav-versioning@w3.org > >Gesendet: Dienstag, 21. August 2001 19:00 > >Betreff: WebDAV Invalidation (Was Re: Allow: header and > supported methods) > > > > > >Check out > >http://www.esi.org/invalidation_protocol_1-0.html for some work > that looks > >pretty similar > >to what we are talking about. > > > >--Eric > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From w3c-dist-auth-request@w3.org Fri Sep 7 12:38:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19705 for ; Fri, 7 Sep 2001 12:38:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA25115; Fri, 7 Sep 2001 12:37:27 -0400 (EDT) Resent-Date: Fri, 7 Sep 2001 12:37:27 -0400 (EDT) Resent-Message-Id: <200109071637.MAA25115@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA25095 for ; Fri, 7 Sep 2001 12:37:09 -0400 (EDT) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA09225 for ; Fri, 7 Sep 2001 12:37:09 -0400 Received: from [216.36.75.111] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 6105263 for w3c-dist-auth@w3c.org; Fri, 07 Sep 2001 09:30:57 -0700 From: "Lisa Dusseault" To: "Webdav WG" Date: Fri, 7 Sep 2001 09:36:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Inconsistency in lock-token response requirements in 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5346 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit There's a minor inconsistency in 2518: the spec says that the successful response to a LOCK request creating a new lock MUST contain the "Lock-Token" header (Section 8.10.1). However, the example shortly after (section 8.10.8) does not contain that header -- instead, it shows the lock token in the body. Most clients seem to pull the lock token out of the body; does that mean the header isn't required? lisa From w3c-dist-auth-request@w3.org Fri Sep 7 12:46:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19984 for ; Fri, 7 Sep 2001 12:46:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA25638; Fri, 7 Sep 2001 12:46:27 -0400 (EDT) Resent-Date: Fri, 7 Sep 2001 12:46:27 -0400 (EDT) Resent-Message-Id: <200109071646.MAA25638@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA25587 for ; Fri, 7 Sep 2001 12:46:18 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA10184 for ; Fri, 7 Sep 2001 12:46:17 -0400 Received: from [216.36.75.111] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 6206327; Fri, 07 Sep 2001 09:39:05 -0700 From: "Lisa Dusseault" To: =?iso-8859-1?Q?J=F6sh_Cohen?= , , , Date: Fri, 7 Sep 2001 09:45:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Subject: RE: WebDAV Invalidation (Was Re: Allow: header and supported methods) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5347 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I agree that limiting the scope carefully is the best way to successfully navigate the BOF process. lisa > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jösh Cohen > Sent: Friday, September 07, 2001 5:05 AM > To: jamsden@us.ibm.com; w3c-dist-auth@w3c.org; > ietf-dav-versioning@w3.org > Subject: RE: WebDAV Invalidation (Was Re: Allow: header and supported > methods) > > > I think thats a good idea to have a BOF. > What Id like to see most importantly is a > focused, and narrow scope. In my mind, > this is a mechanism for subscribing to > and receiving specific change events on > web resources, within the existing web > infrastructure that integrates with DAV. > > > --- > Josh > > > > >From: "Jim Amsden" > >To: w3c-dist-auth@w3c.org, ietf-dav-versioning@w3.org > >Subject: RE: WebDAV Invalidation (Was Re: Allow: header and supported > >methods) > >Date: Thu, 6 Sep 2001 20:40:25 -0400 > > > >I'll schedule a BOF at the next IETF meeting. If there's enough interest, > >we can create a proposed charter and petition the area directors > for a new > >working group. > > > > > > > > > > > > > >"Lisa Dusseault" > >Sent by: ietf-dav-versioning-request@w3.org > >09/06/2001 06:21 PM > > > > > > To: =?iso-8859-1?Q?J=F6sh_Cohen?= , > >, > > cc: "Webdav WG" > > Subject: RE: WebDAV Invalidation (Was Re: Allow: > header and > >supported methods) > > > > > > > >I'd definitely be interested in working on notifications. We'd like > >clients > >to be able to know about events like the ones you suggest, plus: > > - new resource in collection I'm subscribed to > > - Access control change in resource I'm subscribed to > > - New version in VCR (similar to your update/last-modified > event, perhaps > >equivalent) > > > >How do we proceed? > > > >lisa > > > > > -----Original Message----- > > > From: ietf-dav-versioning-request@w3.org > > > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jösh Cohen > > > Sent: Wednesday, August 29, 2001 12:26 PM > > > To: deltav@wegalink.de; ietf-dav-versioning@w3.org > > > Subject: Re: WebDAV Invalidation (Was Re: Allow: header and supported > > > methods) > > > > > > > > > While Im nervous about trying to boil the ocean > > > in the form of a 'general notifications protocol', Im > > > wondering what people think about including the ability > > > to subscribe to events on resources? > > > By this I mean, in short, being able to subscribe > > > to a resource, such that when things happen to it, > > > such as: > > > o property change > > > o update (last modified) > > > o invalidate > > > o lock expiration / lock override > > > o deleted > > > > > > a subscribed entity would receive a notification. > > > > > > There's been some relevant work here in the form of > > > an HTTP extension (SUBSCRIBE/NOTIFY methods) in the past > > > to deal with some of these issues. It was work that > > > was previously done in the context of using HTTP for IM > > > and it quite similar to the SIP subscription extensions. > > > > > > Does this sound at all like something the group > > > would be interested in taking a closer look at ? > > > > > > thanks, > > > > > > --- > > > Josh > > > > > > > > > > > > >From: "Eckhard Kantz" > > > >To: > > > >Subject: Re: WebDAV Invalidation (Was Re: Allow: header and supported > > > >methods) > > > >Date: Wed, 22 Aug 2001 21:40:39 +0200 > > > > > > > >The protocol described in the ESI document allows to invalidate > > > documents > > > >that have been downloaded > > > >to a local machine by applying a push technology. This could > > > solve already > > > >several conflict > > > >situations or even partly prevent problems. > > > > > > > >On the other hand there seems to be an increasing need for more > > > >fine-grained notification services > > > >that extend the traditional access control systems. Picture 1 in the > > > >following longer article tries > > > >to classify them: > > > > > > > >"Beyond 'Yes or No' - Extending Access Control in Groupware with > > > >Negotiation and Awareness" > > > >(http://www.informatik.uni-bonn.de/~os/Publications/COOP98a.ps) > > > > > > > >Maybe those needs are also worth discussing if they could be > > > supported in > > > >the spec in order to allow > > > >applications to build up on them. The invalidation protocol > > > seems to be a > > > >good basis also for this. > > > > > > > >Eckhard > > > > > > > > > > > >-----Ursprüngliche Nachricht----- > > > >Von: Eric Sedlar > > > >An: ietf-dav-versioning@w3.org > > > >Gesendet: Dienstag, 21. August 2001 19:00 > > > >Betreff: WebDAV Invalidation (Was Re: Allow: header and > > > supported methods) > > > > > > > > > > > >Check out > > > >http://www.esi.org/invalidation_protocol_1-0.html for some work > > > that looks > > > >pretty similar > > > >to what we are talking about. > > > > > > > >--Eric > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > > > > > > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp From w3c-dist-auth-request@w3.org Fri Sep 7 12:55:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20370 for ; Fri, 7 Sep 2001 12:55:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26410; Fri, 7 Sep 2001 12:55:22 -0400 (EDT) Resent-Date: Fri, 7 Sep 2001 12:55:22 -0400 (EDT) Resent-Message-Id: <200109071655.MAA26410@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA26356 for ; Fri, 7 Sep 2001 12:55:11 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA11130 for ; Fri, 7 Sep 2001 12:55:11 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA12389; Fri, 7 Sep 2001 09:55:13 -0700 (PDT) From: "Jim Whitehead" To: , Date: Fri, 7 Sep 2001 09:51:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: Event Notification BOF (Was RE: WebDAV Invalidation) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5348 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I am very interested in holding a BOF on Web/WebDAV event notifications as well. I agree that the way to avoid the IMPP pit is to keep this effort tightly focused on Web notifications. Of course, if a General purpose Event Notification Architecture were to emerge from this effort, so much the better. However, this should not be the stated goal. A BOF on event notification was held at the Chicago IETF meeting in August, 1998, the result of which was complete paralysis on this topic, due to many factors. First, the effort was framed as a general-purpose EN facility, not limited to just Web events. Next, since it was considered general purpose, there was a lack of agreement on even where in the protocol stack this effort should sit. There was not universal agreement that it was an application layer protocol. Finally, we made the mistake of having too many presentations, and not enough time for discussion, and I think that prevented the formation of any form of consensus on the topic. Some slides and notes from that period can be found at: http://www.ics.uci.edu/pub/ietf/notify/ In particular, the agenda should be viewed as an example of what not to do, since there was not enough time for discussion (and all of the talks ran over their time slots). As well, the program from the WISEN workshop (also held in 1998) has many interesting EN slides. http://www.ics.uci.edu/IRUS/twist/wisen98/program.html - Jim Josh Cohen writes: > I think thats a good idea to have a BOF. > What Id like to see most importantly is a > focused, and narrow scope. In my mind, > this is a mechanism for subscribing to > and receiving specific change events on > web resources, within the existing web > infrastructure that integrates with DAV. Jim Amsden writes: > >I'll schedule a BOF at the next IETF meeting. If there's enough interest, > >we can create a proposed charter and petition the area directors > for a new working group. From w3c-dist-auth-request@w3.org Tue Sep 11 16:01:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17726 for ; Tue, 11 Sep 2001 16:01:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA11193; Tue, 11 Sep 2001 15:59:39 -0400 (EDT) Resent-Date: Tue, 11 Sep 2001 15:59:39 -0400 (EDT) Resent-Message-Id: <200109111959.PAA11193@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA11173 for ; Tue, 11 Sep 2001 15:59:34 -0400 (EDT) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA01004 for ; Tue, 11 Sep 2001 15:59:33 -0400 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id f8BJxbP00056 for ; Tue, 11 Sep 2001 12:59:37 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f8BJx6A11046 for ; Tue, 11 Sep 2001 12:59:06 -0700 (PDT) Received: from [192.168.1.101] ([130.248.184.92]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GJIKTY00.B7D for ; Tue, 11 Sep 2001 12:58:46 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 11 Sep 2001 12:54:16 -0700 To: "Webdav WG" From: Daniel Brotsky Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: Inconsistency in lock-token response requirements in 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5349 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 9:36 AM -0700 9/7/01, Lisa Dusseault wrote: >There's a minor inconsistency in 2518: the spec says that the successful >response to a LOCK request creating a new lock MUST contain the "Lock-Token" >header (Section 8.10.1). However, the example shortly after (section >8.10.8) does not contain that header -- instead, it shows the lock token in >the body. > >Most clients seem to pull the lock token out of the body; does that mean the >header isn't required? Actually I think it's just an erratum in the example (which was prepared before the lock-token: header requirement went into the spec). There has been ample prior discussion of this on the list (and I thought there was actually an issue about it): summary is that, in general (including non-exclusive locks), it's impossible for a client to determine from the body which lock token was granted. So the lock-token: header *is* required. Isn't there also an issue on the list saying that the lock-token should be required with UNLOCK? There's the same problem there with specifying which token to UNLOCK when a client owns multiple locks on a resource. I believe most clients currently look at the body to determine the token only because they have to :^). Many olders servers (such as IIS 5.0) didn't return lock-token: headers. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Sep 12 10:16:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22574 for ; Wed, 12 Sep 2001 10:16:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA05237; Wed, 12 Sep 2001 10:14:02 -0400 (EDT) Resent-Date: Wed, 12 Sep 2001 10:14:02 -0400 (EDT) Resent-Message-Id: <200109121414.KAA05237@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA05192 for ; Wed, 12 Sep 2001 10:13:40 -0400 (EDT) Received: from matrixmail.matrix-one.com (matrixone.com [4.17.165.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA19487 for ; Wed, 12 Sep 2001 10:13:41 -0400 Received: from msx2am.matrixone.net by matrixmail.matrix-one.com (8.10.1/8.10.1) with ESMTP id f8CECSK06519; Wed, 12 Sep 2001 10:12:29 -0400 (EDT) Received: by msx2am.matrixone.net with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Sep 2001 10:12:28 -0400 Message-ID: <9150DCE0CCB4D411A7DB00508BB0DBF2ED6C3A@msx1am.matrixone.net> From: "Dyer, Kevin" To: "'Lisa Dusseault'" , =?iso-8859-1?Q?J=F6sh_Cohen?= , jamsden@us.ibm.com, w3c-dist-auth@w3c.org, ietf-dav-versioning@w3.org Date: Wed, 12 Sep 2001 10:12:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id KAA05192 Subject: RE: WebDAV Invalidation (Was Re: Allow: header and supported meth ods) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5350 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit All on this thread, Let me boil this down to what I consider the essence of this thread. This entire discussion on publish-Subscribe to notification of events, or the automatic enrollment in a notification event because of the user, e.g. owner, is the genesis of a workflow/lifecycle module within the WebDAV server. Am I off base here? When you peel enough layers off of this discussion, isn't workflow/lifecycle at the heart of it? Except for the simple case where a single item is modified, but even that needs to have exceptions. Kevin > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Friday, September 07, 2001 12:46 PM > To: Jösh Cohen; jamsden@us.ibm.com; w3c-dist-auth@w3c.org; > ietf-dav-versioning@w3.org > Subject: RE: WebDAV Invalidation (Was Re: Allow: header and supported > methods) > > > I agree that limiting the scope carefully is the best way to > successfully > navigate the BOF process. > > lisa > > > -----Original Message----- > > From: ietf-dav-versioning-request@w3.org > > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jösh Cohen > > Sent: Friday, September 07, 2001 5:05 AM > > To: jamsden@us.ibm.com; w3c-dist-auth@w3c.org; > > ietf-dav-versioning@w3.org > > Subject: RE: WebDAV Invalidation (Was Re: Allow: header and > supported > > methods) > > > > > > I think thats a good idea to have a BOF. > > What Id like to see most importantly is a > > focused, and narrow scope. In my mind, > > this is a mechanism for subscribing to > > and receiving specific change events on > > web resources, within the existing web > > infrastructure that integrates with DAV. > > > > > > --- > > Josh > > > > > > > > >From: "Jim Amsden" > > >To: w3c-dist-auth@w3c.org, ietf-dav-versioning@w3.org > > >Subject: RE: WebDAV Invalidation (Was Re: Allow: header > and supported > > >methods) > > >Date: Thu, 6 Sep 2001 20:40:25 -0400 > > > > > >I'll schedule a BOF at the next IETF meeting. If there's > enough interest, > > >we can create a proposed charter and petition the area directors > > for a new > > >working group. > > > > > > > > > > > > > > > > > > > > >"Lisa Dusseault" > > >Sent by: ietf-dav-versioning-request@w3.org > > >09/06/2001 06:21 PM > > > > > > > > > To: =?iso-8859-1?Q?J=F6sh_Cohen?= > , > > >, > > > cc: "Webdav WG" > > > Subject: RE: WebDAV Invalidation (Was Re: Allow: > > header and > > >supported methods) > > > > > > > > > > > >I'd definitely be interested in working on notifications. > We'd like > > >clients > > >to be able to know about events like the ones you suggest, plus: > > > - new resource in collection I'm subscribed to > > > - Access control change in resource I'm subscribed to > > > - New version in VCR (similar to your update/last-modified > > event, perhaps > > >equivalent) > > > > > >How do we proceed? > > > > > >lisa > > > > > > > -----Original Message----- > > > > From: ietf-dav-versioning-request@w3.org > > > > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of > Jösh Cohen > > > > Sent: Wednesday, August 29, 2001 12:26 PM > > > > To: deltav@wegalink.de; ietf-dav-versioning@w3.org > > > > Subject: Re: WebDAV Invalidation (Was Re: Allow: header > and supported > > > > methods) > > > > > > > > > > > > While Im nervous about trying to boil the ocean > > > > in the form of a 'general notifications protocol', Im > > > > wondering what people think about including the ability > > > > to subscribe to events on resources? > > > > By this I mean, in short, being able to subscribe > > > > to a resource, such that when things happen to it, > > > > such as: > > > > o property change > > > > o update (last modified) > > > > o invalidate > > > > o lock expiration / lock override > > > > o deleted > > > > > > > > a subscribed entity would receive a notification. > > > > > > > > There's been some relevant work here in the form of > > > > an HTTP extension (SUBSCRIBE/NOTIFY methods) in the past > > > > to deal with some of these issues. It was work that > > > > was previously done in the context of using HTTP for IM > > > > and it quite similar to the SIP subscription extensions. > > > > > > > > Does this sound at all like something the group > > > > would be interested in taking a closer look at ? > > > > > > > > thanks, > > > > > > > > --- > > > > Josh > > > > > > > > > > > > > > > > >From: "Eckhard Kantz" > > > > >To: > > > > >Subject: Re: WebDAV Invalidation (Was Re: Allow: > header and supported > > > > >methods) > > > > >Date: Wed, 22 Aug 2001 21:40:39 +0200 > > > > > > > > > >The protocol described in the ESI document allows to invalidate > > > > documents > > > > >that have been downloaded > > > > >to a local machine by applying a push technology. This could > > > > solve already > > > > >several conflict > > > > >situations or even partly prevent problems. > > > > > > > > > >On the other hand there seems to be an increasing need for more > > > > >fine-grained notification services > > > > >that extend the traditional access control systems. > Picture 1 in the > > > > >following longer article tries > > > > >to classify them: > > > > > > > > > >"Beyond 'Yes or No' - Extending Access Control in > Groupware with > > > > >Negotiation and Awareness" > > > > >(http://www.informatik.uni-bonn.de/~os/Publications/COOP98a.ps) > > > > > > > > > >Maybe those needs are also worth discussing if they could be > > > > supported in > > > > >the spec in order to allow > > > > >applications to build up on them. The invalidation protocol > > > > seems to be a > > > > >good basis also for this. > > > > > > > > > >Eckhard > > > > > > > > > > > > > > >-----Ursprüngliche Nachricht----- > > > > >Von: Eric Sedlar > > > > >An: ietf-dav-versioning@w3.org > > > > >Gesendet: Dienstag, 21. August 2001 19:00 > > > > >Betreff: WebDAV Invalidation (Was Re: Allow: header and > > > > supported methods) > > > > > > > > > > > > > > >Check out > > > > >http://www.esi.org/invalidation_protocol_1-0.html for some work > > > > that looks > > > > >pretty similar > > > > >to what we are talking about. > > > > > > > > > >--Eric > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > From w3c-dist-auth-request@w3.org Wed Sep 12 17:37:02 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03612 for ; Wed, 12 Sep 2001 17:37:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA01060; Wed, 12 Sep 2001 17:25:35 -0400 (EDT) Resent-Date: Wed, 12 Sep 2001 17:25:35 -0400 (EDT) Resent-Message-Id: <200109122125.RAA01060@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA00941 for ; Wed, 12 Sep 2001 17:25:15 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA09739 for ; Wed, 12 Sep 2001 17:25:16 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA272500; Wed, 12 Sep 2001 17:22:28 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8CLGYN67894; Wed, 12 Sep 2001 17:16:34 -0400 To: Daniel Brotsky Cc: "Webdav WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 12 Sep 2001 17:06:08 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 09/12/2001 05:24:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Inconsistency in lock-token response requirements in 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5351 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This issue is in the issues list.... MISSING_LOCK_TOKEN Section 8.10.1 explicitly states that the response from a successful lock request MUST include the Lock-Token header, yet the examples in 8.10.8, 8.10.9, and 8.10.10 aren't compliant with this requirement, and should be updated. And my recollection is the same as yours. I think we established, in a discussion lead by Jim Amsden a few years ago, that the header must be included in the header for just the reason you stated. Unless someone speaks up in the next few days, I'll mark that as resolved as an obvious editing correction to the spec. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Sep 13 21:36:21 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21508 for ; Thu, 13 Sep 2001 21:36:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA06695; Thu, 13 Sep 2001 21:32:48 -0400 (EDT) Resent-Date: Thu, 13 Sep 2001 21:32:48 -0400 (EDT) Resent-Message-Id: <200109140132.VAA06695@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA06671 for ; Thu, 13 Sep 2001 21:32:28 -0400 (EDT) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA04764 for ; Thu, 13 Sep 2001 21:32:27 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA28070; Thu, 13 Sep 2001 18:34:59 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 13 Sep 2001 18:34:59 -0700 From: Greg Stein To: Jason Crawford Cc: Webdav WG Message-ID: <20010913183459.R27051@lyra.org> Mail-Followup-To: Jason Crawford , Webdav WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ccjason@us.ibm.com on Wed, Sep 05, 2001 at 10:54:26AM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5352 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I don't think it is right to allow somebody other than the lock owner to unlock the thing, but the position below does give me room to refuse to do so. Thus, I am comfortable with that position. Cheers, -g On Wed, Sep 05, 2001 at 10:54:26AM -0400, Jason Crawford wrote: > Hey WebDAV'ers, > A couple of the disagreeing parties (JimW, GeoffC, LisaD) put there > heads together to come up with a compromise on the issue of allowing > non-lock owners to UNLOCK a resouce. The compromise is that the following > items should be said in the spec. > > - A server MAY allow principals other than a lock owner to unlock a > resource > - If a server supports the unlocking of a resource by someone other than > the lock owner, this capability SHOULD be under access control. > - There is a tradeoff in allowing non-owners of a lock to unlock a > resource. It can be beneficial to allow non-lock owners to perform UNLOCK > requests because it allows the adminstrator of the server to configure the > server to grant longer lock timeouts because the administrator knows that > there is a process in place to allow users to deal with forgotten locks > left by other users. On the other hand, a disadvantage of unlocking > someone else's lock is that can create a situation where two users are > working on modifications to the same resource at the same time which can > result in a client having to perform an merge that wasn't previously > planned. > > If we have a consensus around this, the wording that we will use will be > very close to this. If you have any comments on the position or wording, > please speak up. > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Sep 14 17:11:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26587 for ; Fri, 14 Sep 2001 17:11:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA22350; Fri, 14 Sep 2001 17:09:43 -0400 (EDT) Resent-Date: Fri, 14 Sep 2001 17:09:43 -0400 (EDT) Resent-Message-Id: <200109142109.RAA22350@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA22195 for ; Fri, 14 Sep 2001 17:09:31 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.64.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA21553 for ; Fri, 14 Sep 2001 17:09:31 -0400 Received: from Tycho (dsl3-63-249-84-213.cruzio.com [63.249.84.213]) by mail.cruzio.com with SMTP id OAA20883 for ; Fri, 14 Sep 2001 14:09:30 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 14 Sep 2001 14:06:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Online Interop. Event Oct. 9-11 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5353 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit What: Online WebDAV Interoperability Event When: October 9-11, 2001 9-12am PDT, 12-3pm EDT, 4-7pm GMT, 6-9pm CET (Times when at least one person per implementation will be available to be contacted). Who: Anyone with a WebDAV implementation they wish to test As a follow-up to the very successful face-to-face interoperability testing event held in July at UC Santa Cruz, there will be an online WebDAV Interoperability Testing Event on October 9-11, 2001. All WebDAV implementations are welcome to participate, open source or commercial. You are welcome to participate even if you did not take part in the July event. Once we get closer to the event, I'll send out a message asking for information (contact names, phone numbers, email addresses, Web sites, implementations, IP addresses, etc.) from people planning on participating. I'll also be sending out my recommendations on features to focus upon. Right now, the most important thing is to ensure that on the days of the online interop. event you can communicate with other implementations. So, if you're a client implementor, you should ensure that you can get out through your corporate firewall (perhaps you need to add some proxy support to your code?) If you're a server implementor, you should ensure that either your server is available through your firewall, or the server is available on the open Internet. Since these issues can sometimes take awhile to resolve, I recommend doing some pathfinding in the next week to identify issues. In addition, while only three hours a day have been set aside as guaranteed times when someone can be contacted, ideally each server implementation will be available 24hrs/day for the days of the interop. event, to minimize the effect of the span of timezones. For example, this will allow Patrick Collins (PerlDAV) to participate from Australia. - Jim From w3c-dist-auth-request@w3.org Mon Sep 17 12:51:36 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16110 for ; Mon, 17 Sep 2001 12:51:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA03633; Mon, 17 Sep 2001 12:47:17 -0400 (EDT) Resent-Date: Mon, 17 Sep 2001 12:47:17 -0400 (EDT) Resent-Message-Id: <200109171647.MAA03633@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA03609 for ; Mon, 17 Sep 2001 12:46:56 -0400 (EDT) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA08122 for ; Mon, 17 Sep 2001 12:46:55 -0400 Received: from [216.36.75.111] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 6731789 for w3c-dist-auth@w3c.org; Mon, 17 Sep 2001 09:40:13 -0700 From: "Lisa Dusseault" To: "Webdav WG" Date: Mon, 17 Sep 2001 09:45:57 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RFC2518 errata in boolean logic applied to untagged-token-list production? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5354 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 9.4.1 states that untagged tokens in a token list are to be OR'ed together: "If multiple No-tag-list productions are used then one only needs to match the state of the resource for the method to be allowed to continue." However, section 9.4.3 throws "Not" into the mix and uses the word AND to describe the logic combining two untagged tokens: "If: (Not ) When submitted with a request, this If header requires that all operand resources must not be locked with locktoken:write1 and must be locked with locktoken:write2." I assume the last 'and' must be replaced with 'or'? lisa From w3c-dist-auth-request@w3.org Mon Sep 17 13:45:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17211 for ; Mon, 17 Sep 2001 13:45:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07132; Mon, 17 Sep 2001 13:43:04 -0400 (EDT) Resent-Date: Mon, 17 Sep 2001 13:43:04 -0400 (EDT) Resent-Message-Id: <200109171743.NAA07132@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA07112 for ; Mon, 17 Sep 2001 13:42:58 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37187.rational.com [192.229.37.187]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAB14842 for ; Mon, 17 Sep 2001 13:42:58 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 13:42:27 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Sep 2001 13:42:27 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8ABD4@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Mon, 17 Sep 2001 13:42:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC2518 errata in boolean logic applied to untagged-token-lis t production? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5355 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Lisa Dusseault [mailto:lisa@xythos.com] Section 9.4.1 states that untagged tokens in a token list are to be OR'ed together: "If multiple No-tag-list productions are used then one only needs to match the state of the resource for the method to be allowed to continue." This section states that multiple No-tag-list productions are ORed together. The individual tokens in a single No-tag-list production are ANDed together. Unfortunately, you can only infer this from the examples (2518 really should be fixed to make this explicit!). However, section 9.4.3 throws "Not" into the mix and uses the word AND to describe the logic combining two untagged tokens: "If: (Not ) Only a list can be tagged, not a token. When submitted with a request, this If header requires that all operand resources must not be locked with locktoken:write1 and must be locked with locktoken:write2." I assume the last 'and' must be replaced with 'or'? No, the "and" is correct. List's are ORed together and tokens are ANDed together. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Sep 18 22:28:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07436 for ; Tue, 18 Sep 2001 22:28:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA19522; Tue, 18 Sep 2001 22:08:08 -0400 (EDT) Resent-Date: Tue, 18 Sep 2001 22:08:08 -0400 (EDT) Resent-Message-Id: <200109190208.WAA19522@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA19485 for ; Tue, 18 Sep 2001 22:08:01 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA26036 for ; Tue, 18 Sep 2001 22:08:02 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA467204; Tue, 18 Sep 2001 22:05:13 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J1xH2179416; Tue, 18 Sep 2001 21:59:17 -0400 To: "Jason Crawford" Cc: Daniel Brotsky , "Webdav WG" , w3c-dist-auth-request@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Tue, 18 Sep 2001 18:55:15 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 09/18/2001 10:07:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Inconsistency in lock-token response requirements in 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5356 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I've updated the issues list to reflect the fact that we need to make some obvious editing changes to the examples. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com Jason Crawford/Watson/IB To: Daniel Brotsky M@IBMUS cc: "Webdav WG" Sent by: Subject: Re: Inconsistency in lock-token response w3c-dist-auth-requ requirements in 2518 est@w3.org 09/12/2001 05:06 PM This issue is in the issues list.... MISSING_LOCK_TOKEN Section 8.10.1 explicitly states that the response from a successful lock request MUST include the Lock-Token header, yet the examples in 8.10.8, 8.10.9, and 8.10.10 aren't compliant with this requirement, and should be updated. And my recollection is the same as yours. I think we established, in a discussion lead by Jim Amsden a few years ago, that the header must be included in the header for just the reason you stated. Unless someone speaks up in the next few days, I'll mark that as resolved as an obvious editing correction to the spec. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Sep 19 20:39:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13023 for ; Wed, 19 Sep 2001 20:39:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA01505; Wed, 19 Sep 2001 20:34:34 -0400 (EDT) Resent-Date: Wed, 19 Sep 2001 20:34:34 -0400 (EDT) Resent-Message-Id: <200109200034.UAA01505@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA01485 for ; Wed, 19 Sep 2001 20:34:28 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA08684 for ; Wed, 19 Sep 2001 20:34:27 -0400 Received: from beaver (guest217.lyra.org [198.144.203.217]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f8K0YAJ04328 for ; Wed, 19 Sep 2001 17:34:10 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Webdav WG" Date: Wed, 19 Sep 2001 17:33:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: More questions on the IF header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5357 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff answered my previous question on the IF header and I have to agree with him. In my words, if you see two IF header tokens in the same parens () you can OR them; otherwise you have to AND them. So: IF: ( [etag1]) --> if locktoken1 or etag1 matches the resourceURI IF: () ([etag1]) --> if locktoken1 AND etag1 matches the resourceURI When tagged tokens appear, it seems you can't combine two tokens with different tags in the same parens. So: IF: ( [etag1]) ( [etag2]) --> if (href1 has locktoken1 OR href1 has etag1) AND (href2 has locktoken2 OR href2 has etag2) Now I have a new question... We know that when a collection with URL 'C/' is locked with depth infinity, and a resource R is inside it or added to it, the resource R is somehow 'included' in the depth infinity lock. Does that mean that the locktoken created for the lock on C applies to R? Or must the locktoken always be associated with the exact URL for which it was created? The language from section 9.4 is "If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). " So my question can be reworded as, does a child resource "match" the lock token from a infinite-depth lock on a parent resource? We know this will work, because it applies the lock token to the exact resource for which it was created: PUT C/R If: () But must this succeed, or must it fail because the locktoken from C is tagged to the "wrong" resource? PUT C/R If: () And this? PUT C/R If: () lisa From w3c-dist-auth-request@w3.org Thu Sep 20 10:52:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12436 for ; Thu, 20 Sep 2001 10:52:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA12405; Thu, 20 Sep 2001 10:47:35 -0400 (EDT) Resent-Date: Thu, 20 Sep 2001 10:47:35 -0400 (EDT) Resent-Message-Id: <200109201447.KAA12405@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA12366 for ; Thu, 20 Sep 2001 10:47:27 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37196.rational.com [192.229.37.196]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA21441 for ; Thu, 20 Sep 2001 10:47:27 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 20 Sep 2001 10:46:23 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 10:46:23 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8ABEB@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Thu, 20 Sep 2001 10:46:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: More questions on the IF header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5358 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Lisa Dusseault [mailto:lisa@xythos.com] Geoff answered my previous question on the IF header and I have to agree with him. In my words, if you see two IF header tokens in the same parens () you can OR them; otherwise you have to AND them. So: IF: ( [etag1]) --> if locktoken1 or etag1 matches the resourceURI IF: () ([etag1]) --> if locktoken1 AND etag1 matches the resourceURI Actually, it's the other way round, i.e.: IF (token1 token2) (token3 token4) is if (token1 AND token2) OR (token3 AND token4) When tagged tokens appear, it seems you can't combine two tokens with different tags in the same parens. So: IF: ( [etag1]) ( [etag2]) --> if (href1 has locktoken1 OR href1 has etag1) AND (href2 has locktoken2 OR href2 has etag2) Yes, you tag lists, not tokens (but you need to swap AND and OR, i.e. --> if (href1 has locktoken1 AND href1 has etag1) OR (href2 has locktoken2 AND href2 has etag2) Now I have a new question... We know that when a collection with URL 'C/' is locked with depth infinity, and a resource R is inside it or added to it, the resource R is somehow 'included' in the depth infinity lock. Does that mean that the locktoken created for the lock on C applies to R? Or must the locktoken always be associated with the exact URL for which it was created? This has been debated in a thread a while back, and as I recall, there was weak consensus around saying that you can associate the locktoken in the IF header with any URL that identifies a resource that is affected by the lock, not just the URL to which the lock was applied. Which means that: PUT C/R If: () And this? PUT C/R If: () would succeed. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Sep 20 13:16:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16371 for ; Thu, 20 Sep 2001 13:16:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA23305; Thu, 20 Sep 2001 13:14:30 -0400 (EDT) Resent-Date: Thu, 20 Sep 2001 13:14:30 -0400 (EDT) Resent-Message-Id: <200109201714.NAA23305@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA23271 for ; Thu, 20 Sep 2001 13:14:22 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA05474 for ; Thu, 20 Sep 2001 13:14:22 -0400 Received: from [216.36.75.111] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 7174747 for w3c-dist-auth@w3c.org; Thu, 20 Sep 2001 10:06:12 -0700 From: "Lisa Dusseault" To: "Webdav WG" Date: Thu, 20 Sep 2001 10:13:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004C_01C141BC.E4F541A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: FW: I-D ACTION:draft-dusseault-dav-quota-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5359 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C141BC.E4F541A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Clark Warner & I discussed doing this simple little draft at the Interop event; well, now it's published. If there's interest from other implementors (besides Xythos and Apple), I'm happy to pursue standardizing this in some simple form. lisa -----Original Message----- From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, September 20, 2001 4:07 AM To: IETF-Announce: ; Subject: I-D ACTION:draft-dusseault-dav-quota-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Quota and Size Properties for DAV Collections Author(s) : L. Dusseault, C. Warner Filename : draft-dusseault-dav-quota-00.txt Pages : 4 Date : 19-Sep-01 WebDAV servers are frequently deployed with directory quota (size) limitations. This Internet-Draft discusses the two properties and minor behaviors needed to interoperably deal with quotas on WebDAV repositories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-dav-quota-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dusseault-dav-quota-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dusseault-dav-quota-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_004C_01C141BC.E4F541A0 Content-Type: Message/External-body; name="ATT00022.dat" Content-Disposition: attachment; filename="ATT00022.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010919121426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dusseault-dav-quota-00.txt ------=_NextPart_000_004C_01C141BC.E4F541A0 Content-Type: Message/External-body; name="draft-dusseault-dav-quota-00.txt" Content-Disposition: attachment; filename="draft-dusseault-dav-quota-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010919121426.I-D@ietf.org> ------=_NextPart_000_004C_01C141BC.E4F541A0-- From w3c-dist-auth-request@w3.org Mon Sep 24 09:07:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02385 for ; Mon, 24 Sep 2001 09:07:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA03989; Mon, 24 Sep 2001 08:26:35 -0400 (EDT) Resent-Date: Mon, 24 Sep 2001 08:26:35 -0400 (EDT) Resent-Message-Id: <200109241226.IAA03989@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA03969 for ; Mon, 24 Sep 2001 08:26:26 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA22015 for ; Mon, 24 Sep 2001 08:26:26 -0400 Received: (qmail 32025 invoked by uid 0); 24 Sep 2001 12:25:55 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 24 Sep 2001 12:25:55 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Mon, 24 Sep 2001 14:25:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5360 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, in WebDAV, the owner of a lock can be reported using the DAV:owner element (): The owner XML element provides information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who owns a lock. It is documented to have ANY content, while the examples (for instance, ) use an embedded DAV:href element: Infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 While this isn't a problem per se, it seems to have created a situation where implementors are unsure how to set and process the owner element. For instance, the WebDAV library used in Microsoft Office 2000 seems to compare the (text) contents of the owner element (as returned in the response) with the value it has sent. If they don't match, it assumes that the LOCK operation has failed and reports that the document was opened as "read only" (which I'd say is clearly a bug). I think to "fix" this, we whould collect more implementation data. Maybe this is a case where we could take advantage of XLink ()...: Jim Whitehead Jim Whitehead Jim Whitehead or a simpler version that probably wouldn't "break" Office: Jim Whitehead Julian From w3c-dist-auth-request@w3.org Mon Sep 24 14:22:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27032 for ; Mon, 24 Sep 2001 14:22:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA01125; Mon, 24 Sep 2001 14:19:02 -0400 (EDT) Resent-Date: Mon, 24 Sep 2001 14:19:02 -0400 (EDT) Resent-Message-Id: <200109241819.OAA01125@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA01096 for ; Mon, 24 Sep 2001 14:18:52 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA02387 for ; Mon, 24 Sep 2001 14:18:52 -0400 Received: from [216.36.75.111] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 7406807; Mon, 24 Sep 2001 11:10:24 -0700 From: "Lisa Dusseault" To: "Julian Reschke" , "Webdav WG" Date: Mon, 24 Sep 2001 11:17:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5361 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Actually, the DAV Interop showed that you just can't mess with the contents of lock owner as it is now. Adobe clients rely on setting the lock owner specifically to their own string. DAV:owner value must be set by the client. RFC2518 could extend lockdiscovery in a couple ways: - create a new element of some kind for clients to use, to contain a URI pointing to the owner. Make a clearer specification about what this element contains. - create a new element of some kind for servers to use to put their conception of who created the lock. Probably this is a PrincipalID from ACLs. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Monday, September 24, 2001 5:26 AM > To: Webdav WG > Subject: RFC2518 issue with lockdiscovery/activelock/owner > > > Hi, > > in WebDAV, the owner of a lock can be reported using the DAV:owner element > (): > > > > The owner XML element provides information sufficient for either directly > contacting a principal (such as a telephone number or Email URI), or for > discovering the principal (such as the URL of a homepage) who owns a lock. > > > > > > It is documented to have ANY content, while the examples (for instance, > 0.8>) use > an embedded DAV:href element: > > > > > > > > Infinity > > > http://www.ics.uci.edu/~ejw/contact.html > > > Second-604800 > > > opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 > > > > > > > > > While this isn't a problem per se, it seems to have created a situation > where implementors are unsure how to set and process the owner element. > > For instance, the WebDAV library used in Microsoft Office 2000 seems to > compare the (text) contents of the owner element (as returned in the > response) with the value it has sent. If they don't match, it assumes that > the LOCK operation has failed and reports that the document was opened as > "read only" (which I'd say is clearly a bug). > > I think to "fix" this, we whould collect more implementation data. Maybe > this is a case where we could take advantage of XLink > ()...: > > > DAV:href="http://www.ics.uci.edu/~ejw/contact.html"> > Jim Whitehead > > DAV:href="mailto:ejw@foobar.com"> > Jim Whitehead > > DAV:href="/users/ejw"> > Jim Whitehead > > > > or a simpler version that probably wouldn't "break" Office: > > DAV:href="/users/ejw"> > Jim Whitehead > > > > > > Julian > > > > > From w3c-dist-auth-request@w3.org Mon Sep 24 17:14:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01260 for ; Mon, 24 Sep 2001 17:14:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA15445; Mon, 24 Sep 2001 17:11:37 -0400 (EDT) Resent-Date: Mon, 24 Sep 2001 17:11:37 -0400 (EDT) Resent-Message-Id: <200109242111.RAA15445@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA15395 for ; Mon, 24 Sep 2001 17:11:29 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA23108 for ; Mon, 24 Sep 2001 17:11:29 -0400 Received: (qmail 11489 invoked by uid 0); 24 Sep 2001 21:11:25 -0000 Received: from p3ee247ba.dip.t-dialin.net (HELO lisa) (62.226.71.186) by mail.gmx.net (mp007-rz3) with SMTP; 24 Sep 2001 21:11:25 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Mon, 24 Sep 2001 23:11:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5362 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Interesting. So both Adobe clients and MS Webfolders assume that in a LOCK response, the DAV:owner will be identical with what they have submitted? I think this is a bug. Has it been reported? (I know that at least Adobe occasionally is following this list). Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, September 24, 2001 8:18 PM > To: Julian Reschke; Webdav WG > Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner > > > Actually, the DAV Interop showed that you just can't mess with > the contents > of lock owner as it is now. Adobe clients rely on setting the lock owner > specifically to their own string. DAV:owner value must be set by the > client. > > RFC2518 could extend lockdiscovery in a couple ways: > - create a new element of some kind for clients to use, to contain a URI > pointing to the owner. Make a clearer specification about what > this element > contains. > > - create a new element of some kind for servers to use to put their > conception of who created the lock. Probably this is a PrincipalID from > ACLs. > > lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > > Sent: Monday, September 24, 2001 5:26 AM > > To: Webdav WG > > Subject: RFC2518 issue with lockdiscovery/activelock/owner > > > > > > Hi, > > > > in WebDAV, the owner of a lock can be reported using the > DAV:owner element > > (): > > > > > > > > The owner XML element provides information sufficient for > either directly > > contacting a principal (such as a telephone number or Email URI), or for > > discovering the principal (such as the URL of a homepage) who > owns a lock. > > > > > > > > > > > > It is documented to have ANY content, while the examples (for instance, > > > 0.8>) use > > an embedded DAV:href element: > > > > > > > > > > > > > > > > Infinity > > > > > > http://www.ics.uci.edu/~ejw/contact.html > > > > > > Second-604800 > > > > > > opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 > > > > > > > > > > > > > > > > > > While this isn't a problem per se, it seems to have created a situation > > where implementors are unsure how to set and process the owner element. > > > > For instance, the WebDAV library used in Microsoft Office 2000 seems to > > compare the (text) contents of the owner element (as returned in the > > response) with the value it has sent. If they don't match, it > assumes that > > the LOCK operation has failed and reports that the document was > opened as > > "read only" (which I'd say is clearly a bug). > > > > I think to "fix" this, we whould collect more implementation data. Maybe > > this is a case where we could take advantage of XLink > > ()...: > > > > > > > DAV:href="http://www.ics.uci.edu/~ejw/contact.html"> > > Jim Whitehead > > > > > DAV:href="mailto:ejw@foobar.com"> > > Jim Whitehead > > > > > DAV:href="/users/ejw"> > > Jim Whitehead > > > > > > > > or a simpler version that probably wouldn't "break" Office: > > > > > DAV:href="/users/ejw"> > > Jim Whitehead > > > > > > > > > > > > Julian > > > > > > > > > > > From w3c-dist-auth-request@w3.org Tue Sep 25 12:55:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09373 for ; Tue, 25 Sep 2001 12:55:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA06601; Tue, 25 Sep 2001 12:49:19 -0400 (EDT) Resent-Date: Tue, 25 Sep 2001 12:49:19 -0400 (EDT) Resent-Message-Id: <200109251649.MAA06601@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA06581 for ; Tue, 25 Sep 2001 12:49:13 -0400 (EDT) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA11770 for ; Tue, 25 Sep 2001 12:49:12 -0400 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id f8PGnNK04455 for ; Tue, 25 Sep 2001 09:49:23 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f8PGmmS16231 for ; Tue, 25 Sep 2001 09:48:48 -0700 (PDT) Received: from [192.168.1.19] ([130.248.188.67]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GK89D000.CAJ; Tue, 25 Sep 2001 09:48:36 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 25 Sep 2001 09:48:03 -0700 To: "Julian Reschke" From: Daniel Brotsky Cc: "Webdav WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5363 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 11:11 PM +0200 9/24/01, Julian Reschke wrote: >Interesting. > >So both Adobe clients and MS Webfolders assume that in a LOCK response, the >DAV:owner will be identical with what they have submitted? As far as I know. This was discussed at the interop event and a spec clarification item was added about it. My memory of the item is roughly that "lock owner strings belong to clients, not servers, so servers should not mess with them." :^) > >I think this is a bug. Has it been reported? (I know that at least Adobe >occasionally is following this list). Adobe follows this list closely. We don't always have as much time to respond as we would like, but you can be sure we read everything. As far as the behavior of relying on owner strings to be "dead" being a bug, I don't think so, and even if I did it's quite unlikely to change. My interpretation of the current spec is that the owner string is intended for use by clients to allow for conventions around cooperating over locked resources. In the section you quoted, there is an unfortunate ambiguity in the passive voice about "information sufficient for contacting" because it doesn't say who is supposed to be doing the contacting - other clients or the server. Adobe's interpretation is that it was other clients who would be doing the contacting, and thus the owner string should be meaningful to (and under the control of) clients. Servers, after all, have the authenticated username of the agent who obtained the lock, so they have resources not available to the clients to know whom to contact. Another way of seeing the dilemma here is to ask: suppose clients wanted to store conventional information about lock owners with the locked resource, how would they do that? As we considered that question at Adobe, there seemed to be three fairly straightforward answers: 1. put it in the lock owner string, which the client sets anyway when obtaining the lock. 2. put it on another dead property. this has three disadvantages relative to (1): it requires another round trip (PROPPATCH) in addition to the LOCK; there's no way to guarantee that the server supports any other given property as a dead property (many have good reasons for making all properties live and that's completely allowed by the spec); and other clients have to know the convention *and* know which kind of client client obtained the lock in order to get this information [so you're back to (1) on the "who obtained it" anyway]. 3. put it in the resource content. I'm sure you can come up with just as many good reasons for not doing this as we did :^). It's the clear loser. Thus Adobe's bottom line was: clients need a dead property for storing conventional owner information, and the OWNER string is something you already set when locking (so no extra roundtrip) that seems in the spec to be under client control. So let's use that. What came out of the interop event was that (a) Adobe wasn't the only client doing this, and (b) clarifing the spec so that OWNER strings are definitely under client control would not break any servers. Hence the issue as I wrote it up above. By the way, servers are currently not required to return owner information on lock discovery. I think we need to fold this into the issue as well, and force them to return it. Clients who don't want it returned can simply not put sensitive things in the string (or leave it empty). dan P.S. I'm still trying to find time to respond at length to the UNLOCK-NOT-OWNER issue; which I believe is related because in my earlier response I raised this whole question of "clients can't know who has a resource locked." I'll see if I can get to that this week. But until then, I just want to point out that there's a security problem with requiring servers to tell clients who (as in the server-side uname) has locked a given resource: it provides a way for clients to discover unames through which the server can be attacked. This is one of the many considerations that cause administrative protocols to be structured quite differently from individual-contributor protocols, and one of the reasons that I resist pushing DAV in administrative directions (such as being able to unlock someone else's lock). -d. > >Julian > >> -----Original Message----- >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault >> Sent: Monday, September 24, 2001 8:18 PM >> To: Julian Reschke; Webdav WG >> Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner >> >> >> Actually, the DAV Interop showed that you just can't mess with >> the contents >> of lock owner as it is now. Adobe clients rely on setting the lock owner >> specifically to their own string. DAV:owner value must be set by the >> client. >> >> RFC2518 could extend lockdiscovery in a couple ways: >> - create a new element of some kind for clients to use, to contain a URI >> pointing to the owner. Make a clearer specification about what >> this element >> contains. >> >> - create a new element of some kind for servers to use to put their >> conception of who created the lock. Probably this is a PrincipalID from >> ACLs. >> >> lisa >> >> > -----Original Message----- >> > From: w3c-dist-auth-request@w3.org >> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke >> > Sent: Monday, September 24, 2001 5:26 AM >> > To: Webdav WG >> > Subject: RFC2518 issue with lockdiscovery/activelock/owner >> > >> > >> > Hi, >> > >> > in WebDAV, the owner of a lock can be reported using the >> DAV:owner element >> > (): >> > >> > >> > > > > The owner XML element provides information sufficient for >> either directly >> > contacting a principal (such as a telephone number or Email URI), or for >> > discovering the principal (such as the URL of a homepage) who > > owns a lock. >> > >> > >> > >> > >> > >> > It is documented to have ANY content, while the examples (for instance, >> > > > 0.8>) use >> > an embedded DAV:href element: >> > >> > >> > >> > >> > >> > >> > >> > Infinity >> > >> > >> > http://www.ics.uci.edu/~ejw/contact.html >> > >> > >> > Second-604800 >> > >> > >> > opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 >> > >> > >> > >> > >> > >> > >> > >> > >> > While this isn't a problem per se, it seems to have created a situation >> > where implementors are unsure how to set and process the owner element. >> > >> > For instance, the WebDAV library used in Microsoft Office 2000 seems to >> > compare the (text) contents of the owner element (as returned in the >> > response) with the value it has sent. If they don't match, it >> assumes that >> > the LOCK operation has failed and reports that the document was >> opened as >> > "read only" (which I'd say is clearly a bug). >> > >> > I think to "fix" this, we whould collect more implementation data. Maybe >> > this is a case where we could take advantage of XLink >> > ()...: >> > >> > >> > > > DAV:href="http://www.ics.uci.edu/~ejw/contact.html"> >> > Jim Whitehead >> > >> > > > DAV:href="mailto:ejw@foobar.com"> >> > Jim Whitehead >> > >> > > > DAV:href="/users/ejw"> >> > Jim Whitehead >> > >> > >> > >> > or a simpler version that probably wouldn't "break" Office: >> > >> > > > DAV:href="/users/ejw"> > > > Jim Whitehead >> > >> > >> > >> > >> > >> > Julian >> > >> > >> > >> > >> > >> -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Sep 26 04:37:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10789 for ; Wed, 26 Sep 2001 04:37:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA18778; Wed, 26 Sep 2001 04:36:03 -0400 (EDT) Resent-Date: Wed, 26 Sep 2001 04:36:03 -0400 (EDT) Resent-Message-Id: <200109260836.EAA18778@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA18754 for ; Wed, 26 Sep 2001 04:35:56 -0400 (EDT) Received: from www.pspl.co.in (www.pspl.co.in [202.54.11.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA30553 for ; Wed, 26 Sep 2001 04:35:54 -0400 Received: (from root@localhost) by www.pspl.co.in (8.11.0/8.11.0) id f8Q8aMn16121 for ; Wed, 26 Sep 2001 14:06:22 +0530 Received: from asterix (gateway.pspl.co.in [203.199.147.2]) by www.pspl.co.in (8.11.0/8.11.0) with SMTP id f8Q8aJl16108 for ; Wed, 26 Sep 2001 14:06:20 +0530 From: =?iso-8859-1?Q?Medha_Atr=E9?= To: "WebDAV" Date: Wed, 26 Sep 2001 14:09:33 +0530 Message-ID: MIME-Version: 1.0 X-Scanned: XAM7527 Scanned by XAMIME Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: ACL-draft for WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5364 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, I am going through the ACL draft for building a compliance test harness for a WebDAV server. I have some doubts in the same. The draft doesn't mention anything about the DEPTH of the ACEs granted to a principal on a particular collection-resource. E.g. User John has been granted DAV:write ACE to a collection /dav/tom/. If /dav/tom/ is containing 3 children namely /dav/tom/mike/, /dav/tom/johnson/ and /dav/tom/tom.txt, then what will the access right of John on these three children ? Does privilege on particular collection mean same privilege on all of its children to DEPTH INFINITY or the user should be granted ACEs separately on each and every child of the collection ? I did not understand the significance of ACL SEMANTICS. What is meant by DAV:first-match, DAV:all-grant-before-any-deny etc. There isn't any example of XML request and response given for the same. Medha Atré ~~~~~~~~~~~~~~~~~~~~ Associate Member of Tech. Staff Persistent Systems Pvt. Ltd. Pune, India Ph : +91-20-5678900 (Ext. 295) ~~~~~~~~~~~~~~~~~~~~ From w3c-dist-auth-request@w3.org Wed Sep 26 07:37:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13468 for ; Wed, 26 Sep 2001 07:37:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA25404; Wed, 26 Sep 2001 07:35:02 -0400 (EDT) Resent-Date: Wed, 26 Sep 2001 07:35:02 -0400 (EDT) Resent-Message-Id: <200109261135.HAA25404@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA25382 for ; Wed, 26 Sep 2001 07:34:50 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37168.rational.com [192.229.37.168]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA15535 for ; Wed, 26 Sep 2001 07:34:50 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 26 Sep 2001 07:22:39 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 07:22:39 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1045036A0@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Wed, 26 Sep 2001 07:23:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id HAA25382 Subject: RE: ACL-draft for WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5365 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit A "depth" ACE is represented as an inherited ACE in each of the resources that it affects. So if there is an ACE on /dav/tom that is inherited by its members, it will appear as an inherited ACE on /dav/tom/mike, /dav/tom/johnson, and /dav/tom/tom.txt. There is no interoperable way in the current ACL spec to *specify* that an ACE should be inherited, because techniques for ACE inheritance varies so widely. There only is an interoperable way to discover inherited ACE's. As for DAV:acl-semantics, that is just a way for a client (or for that matter, a user) to understand how ACE's are combined or restricted for a given resource. They are just a set of token's with predefined meanings that are returned by a server. You use PROPFIND on the DAV:acl-semantics property to get the values for a particular resource. Cheers, Geoff -----Original Message----- From: Medha Atré [mailto:medha_atre@persistent.co.in] Sent: Wednesday, September 26, 2001 4:40 AM To: WebDAV Subject: ACL-draft for WebDAV Hello, I am going through the ACL draft for building a compliance test harness for a WebDAV server. I have some doubts in the same. The draft doesn't mention anything about the DEPTH of the ACEs granted to a principal on a particular collection-resource. E.g. User John has been granted DAV:write ACE to a collection /dav/tom/. If /dav/tom/ is containing 3 children namely /dav/tom/mike/, /dav/tom/johnson/ and /dav/tom/tom.txt, then what will the access right of John on these three children ? Does privilege on particular collection mean same privilege on all of its children to DEPTH INFINITY or the user should be granted ACEs separately on each and every child of the collection ? I did not understand the significance of ACL SEMANTICS. What is meant by DAV:first-match, DAV:all-grant-before-any-deny etc. There isn't any example of XML request and response given for the same. Medha Atré ~~~~~~~~~~~~~~~~~~~~ Associate Member of Tech. Staff Persistent Systems Pvt. Ltd. Pune, India Ph : +91-20-5678900 (Ext. 295) ~~~~~~~~~~~~~~~~~~~~ From w3c-dist-auth-request@w3.org Wed Sep 26 19:12:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00866 for ; Wed, 26 Sep 2001 19:12:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA02579; Wed, 26 Sep 2001 19:03:58 -0400 (EDT) Resent-Date: Wed, 26 Sep 2001 19:03:58 -0400 (EDT) Resent-Message-Id: <200109262303.TAA02579@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA02559 for ; Wed, 26 Sep 2001 19:03:46 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA32110 for ; Wed, 26 Sep 2001 19:03:46 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA00904 for ; Wed, 26 Sep 2001 16:03:24 -0700 (PDT) From: "Jim Whitehead" To: "Webdav WG" Date: Wed, 26 Sep 2001 16:00:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: I-D ACTION:draft-dusseault-dav-quota-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5366 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Clark Warner & I discussed doing this simple little draft at the Interop > event; well, now it's published. > > If there's interest from other implementors (besides Xythos and > Apple), I'm happy to pursue standardizing this in some simple form. I think that if it provides value for Xythos and Apple, it undoubtedly will provide value for others in the future. I know that quota support is a frequently requested feature for mod_dav. The current draft is really not that far away from being able to be sent along for a working group last call. IMO, it needs the following changes: * Add a brief introduction which: - Provides a little bit of background on the operational scenario(s) that require this capability (i.e., setups like Sharemation, iDisk, etc.) - Describes the approach: provide two read-only properties that clients can use to discover quota information * Add the standard reference to RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels" and then change the text to use MUST/SHOULD/etc as appropriate. * Add a reference to the definition of a "protected" property. * Add a security considerations section. The only one I can think of is that a hacker might preferentially attack an account with large quota. * Change all places where "directory" or "directories" is used to refer to "collections" instead. DAV doesn't have directories, because we weren't developing a network file system protocol (oops, guess we did by accident). * Add a references section, and add the DAV and DeltaV specifications, along with RFC 2119. * Add an example PROPFIND request that shows these properties being retrieved. * Define each property in a similar manner to existing properties in DAV and DeltaV (i.e., have the XML DTD specification for each one -- should just be ANY). * Complete Clark Warner's address. Some thoughts on the specification: - Does it make sense to allow DAV:quota to be writeable? If so, then there should probably be an associated ACL privilege defined. It seems like a read-only quota standard offers a lot of value, so it probably doesn't make sense to allow DAV:quota to be writeable. - It might make sense to have DAV:quotaused be renamed DAV:spaceused. It seems to me this property has utility beyond just the quota case. - DAV:quotaused is listed as being optional. I didn't understand that. It seems to me that any quota enforcing server should know how much space is currently being used, according to their accounting policy, right? - Jim From w3c-dist-auth-request@w3.org Wed Sep 26 19:24:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00955 for ; Wed, 26 Sep 2001 19:24:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA03169; Wed, 26 Sep 2001 19:18:35 -0400 (EDT) Resent-Date: Wed, 26 Sep 2001 19:18:35 -0400 (EDT) Resent-Message-Id: <200109262318.TAA03169@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA03149 for ; Wed, 26 Sep 2001 19:18:25 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA00903 for ; Wed, 26 Sep 2001 19:18:25 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA04359 for ; Wed, 26 Sep 2001 16:18:03 -0700 (PDT) From: "Jim Whitehead" To: "Webdav WG" Date: Wed, 26 Sep 2001 16:14:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: I-D ACTION:draft-dusseault-dav-quota-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5367 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Oh, one other comment. What is the expectation on the relationship between the quota values for a given collection, and its subcollections. For example, if I have collection hierarchy, where A, B, & C are collections: A / \ B C Would DAV:quota be the same for every collection? If so, how should that be interpreted. If the value of DAV:quota is 20 meg on A, B, & C, then does this imply: a) I have a total of 60 meg of storage (20 meg for A + 20 meg for B + 20 meg for C) OR b) I have a total of 20 meg of storage, and the DAV:quota value is just replicated on all subcollections. Similarly, does DAV:quotaused include space used by sub-collections (Depth infinity), or is it just a Depth 1 space used measurement? - Jim From w3c-dist-auth-request@w3.org Thu Sep 27 03:26:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23073 for ; Thu, 27 Sep 2001 03:26:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA19087; Thu, 27 Sep 2001 03:24:13 -0400 (EDT) Resent-Date: Thu, 27 Sep 2001 03:24:13 -0400 (EDT) Resent-Message-Id: <200109270724.DAA19087@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA19056 for ; Thu, 27 Sep 2001 03:23:40 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA03058 for ; Thu, 27 Sep 2001 03:23:40 -0400 Received: (qmail 23984 invoked by uid 0); 27 Sep 2001 07:23:09 -0000 Received: from pd9535526.dip.t-dialin.net (HELO lisa) (217.83.85.38) by mail.gmx.net (mp003-rz3) with SMTP; 27 Sep 2001 07:23:09 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Thu, 27 Sep 2001 09:22:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5368 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky > Sent: Tuesday, September 25, 2001 6:48 PM > To: Julian Reschke > Cc: Webdav WG > Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner > > > At 11:11 PM +0200 9/24/01, Julian Reschke wrote: > >Interesting. > > > >So both Adobe clients and MS Webfolders assume that in a LOCK > response, the > >DAV:owner will be identical with what they have submitted? > > As far as I know. This was discussed at the interop event and a spec > clarification item was added about it. My memory of the item is > roughly that "lock owner strings belong to clients, not servers, so > servers should not mess with them." :^) OK, I read and forgot about that. I still don't understand why a client would compare the contents of the DAV:owner element contained in the response to the successful LOCK method call with what he sent. I would have hoped / assumed that the right thing to do is: a) attempt the LOCK b) if the LOCK method success, store the contents of DAV:owner *that was sent back by the server* for later comparisons. The behaviour seen in MS Office just doesn't make any sense... Regards, Julian From w3c-dist-auth-request@w3.org Thu Sep 27 03:32:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23229 for ; Thu, 27 Sep 2001 03:32:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA19330; Thu, 27 Sep 2001 03:31:08 -0400 (EDT) Resent-Date: Thu, 27 Sep 2001 03:31:08 -0400 (EDT) Resent-Message-Id: <200109270731.DAA19330@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA19278 for ; Thu, 27 Sep 2001 03:30:40 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA03523 for ; Thu, 27 Sep 2001 03:30:39 -0400 Received: (qmail 3650 invoked by uid 0); 27 Sep 2001 07:30:17 -0000 Received: from pd9535526.dip.t-dialin.net (HELO lisa) (217.83.85.38) by mail.gmx.net (mp020-rz3) with SMTP; 27 Sep 2001 07:30:17 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Thu, 27 Sep 2001 09:30:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5369 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, September 24, 2001 8:18 PM > To: Julian Reschke; Webdav WG > Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner > > > Actually, the DAV Interop showed that you just can't mess with > the contents > of lock owner as it is now. Adobe clients rely on setting the lock owner > specifically to their own string. DAV:owner value must be set by the > client. > > RFC2518 could extend lockdiscovery in a couple ways: First of all, the previous statement should appear somewhere in the RFC, and the examples should be adjusted to be compliant to this statement: for instance, in 8.10.8 [1] the whitespace inside the href child element is not preserved. > - create a new element of some kind for clients to use, to contain a URI > pointing to the owner. Make a clearer specification about what > this element > contains. > > - create a new element of some kind for servers to use to put their > conception of who created the lock. Probably this is a PrincipalID from > ACLs. 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. Julian [1] From w3c-dist-auth-request@w3.org Thu Sep 27 06:31:54 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25129 for ; Thu, 27 Sep 2001 06:31:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA27186; Thu, 27 Sep 2001 06:26:12 -0400 (EDT) Resent-Date: Thu, 27 Sep 2001 06:26:12 -0400 (EDT) Resent-Message-Id: <200109271026.GAA27186@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA27137 for ; Thu, 27 Sep 2001 06:26:02 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA18570 for ; Thu, 27 Sep 2001 06:26:02 -0400 Received: (qmail 7670 invoked by uid 0); 27 Sep 2001 10:25:31 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 27 Sep 2001 10:25:31 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Thu, 27 Sep 2001 12:25:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5370 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, if for some reason a server doesn't have one of these timestamps for a resource, what should it report on PROPFIND for these properties? a) Property not found (HTTP 404), b) Empty property (this seem to be backed by the wording in section 7.4 [1], but is reported as error by Adobe GoLive, c) Property silently suppressed (not reported at all) -- this seems to work with GoLive. In addition, how should the server behaviour upon a PROPFIND/propname on this resource? Julian [1] From w3c-dist-auth-request@w3.org Thu Sep 27 09:06:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29531 for ; Thu, 27 Sep 2001 09:06:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA06958; Thu, 27 Sep 2001 09:00:38 -0400 (EDT) Resent-Date: Thu, 27 Sep 2001 09:00:38 -0400 (EDT) Resent-Message-Id: <200109271300.JAA06958@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA06869 for ; Thu, 27 Sep 2001 09:00:18 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37016.rational.com [192.229.37.16]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA06238 for ; Thu, 27 Sep 2001 09:00:17 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 27 Sep 2001 08:59:46 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Sep 2001 08:59:46 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10465258F@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Thu, 27 Sep 2001 08:59:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5371 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: 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. From w3c-dist-auth-request@w3.org Thu Sep 27 09:12:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29727 for ; Thu, 27 Sep 2001 09:12:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA07211; Thu, 27 Sep 2001 09:09:09 -0400 (EDT) Resent-Date: Thu, 27 Sep 2001 09:09:09 -0400 (EDT) Resent-Message-Id: <200109271309.JAA07211@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA07183 for ; Thu, 27 Sep 2001 09:08:55 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA07081 for ; Thu, 27 Sep 2001 09:08:55 -0400 Received: (qmail 901 invoked by uid 0); 27 Sep 2001 13:08:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 27 Sep 2001 13:08:24 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "Webdav WG" Date: Thu, 27 Sep 2001 15:08:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3906C56A7BD1F54593344C05BD1374B10465258F@SUS-MA1IT01> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5372 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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. > From w3c-dist-auth-request@w3.org Thu Sep 27 10:15:54 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01426 for ; Thu, 27 Sep 2001 10:15:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA11003; Thu, 27 Sep 2001 10:13:41 -0400 (EDT) Resent-Date: Thu, 27 Sep 2001 10:13:41 -0400 (EDT) Resent-Message-Id: <200109271413.KAA11003@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA10966 for ; Thu, 27 Sep 2001 10:13:20 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37016.rational.com [192.229.37.16]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA14191 for ; Thu, 27 Sep 2001 10:13:20 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 27 Sep 2001 10:12:35 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Sep 2001 10:12:35 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1046525E2@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Thu, 27 Sep 2001 10:12:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5373 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: 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. > From w3c-dist-auth-request@w3.org Thu Sep 27 18:16:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14412 for ; Thu, 27 Sep 2001 18:16:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA14784; Thu, 27 Sep 2001 18:13:28 -0400 (EDT) Resent-Date: Thu, 27 Sep 2001 18:13:28 -0400 (EDT) Resent-Message-Id: <200109272213.SAA14784@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA14758 for ; Thu, 27 Sep 2001 18:13:06 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA05235 for ; Thu, 27 Sep 2001 18:13:06 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id PAA29271 for ; Thu, 27 Sep 2001 15:12:47 -0700 (PDT) From: "Jim Whitehead" To: "Webdav WG" Date: Thu, 27 Sep 2001 15:09:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1046525E2@SUS-MA1IT01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5374 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 From w3c-dist-auth-request@w3.org Fri Sep 28 14:17:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21607 for ; Fri, 28 Sep 2001 14:17:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA24249; Fri, 28 Sep 2001 14:14:35 -0400 (EDT) Resent-Date: Fri, 28 Sep 2001 14:14:35 -0400 (EDT) Resent-Message-Id: <200109281814.OAA24249@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA24229 for ; Fri, 28 Sep 2001 14:14:14 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA27667 for ; Fri, 28 Sep 2001 14:14:13 -0400 Received: from beaver ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f8SIDrA15688 for ; Fri, 28 Sep 2001 11:13:56 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Webdav WG" Date: Fri, 28 Sep 2001 11:13:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Locking, moving and deleting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5375 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit In general, I think WebDAV ties locks to resources. I think this is embodied in a few things we take for granted: - DELETE a resource, and its lock goes away. - LOCK a URI that doesn't have a resource, and DAV requires you to create one (a LNR). However, there's a statement in the spec that flies in the face of that: "A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. " You could justify that exception by saying yes, in general, locks are tied to resources but do not survive moves. But does that work?? What if you MOVE (or rename!) a collection that has locked or lock-null resources inside it? If you follow the logic that locks do not survive moves, then you must: - remove all the locks of all the children, including LNRs - remove the LNRs, now that their locks are gone Does any server follow that behaviour? Or are locks in practice preserved on some or all MOVE operations? lisa From w3c-dist-auth-request@w3.org Fri Sep 28 14:31:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21923 for ; Fri, 28 Sep 2001 14:31:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA24861; Fri, 28 Sep 2001 14:30:06 -0400 (EDT) Resent-Date: Fri, 28 Sep 2001 14:30:06 -0400 (EDT) Resent-Message-Id: <200109281830.OAA24861@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA24835 for ; Fri, 28 Sep 2001 14:29:44 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37016.rational.com [192.229.37.16]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA29596 for ; Fri, 28 Sep 2001 14:29:45 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 28 Sep 2001 14:29:08 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 14:29:08 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AC1E@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Fri, 28 Sep 2001 14:29:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Locking, moving and deleting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5376 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The best way to explain the defined MOVE semantics for a LOCK is to say that a LOCK is on a URL, but that it is deleted when the resource mapped to that URL is deleted. So a MOVE of a collection will delete all locks on URL's for that collection, but that doesn't necessarily remove all locks on the resources in that collection. For example, suppose the URL /x/foo.html and /y/bar.html are mapped to the same resource. If you LOCK /x/foo.html, and then MOVE /x/foo.html to /z/foo.html, the resource mapped to /z/foo.html is no longer locked. If on the other hand, you LOCK /z/bar.html and then do the same MOVE, the resource mapped to /z/foo.html remains locked. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Friday, September 28, 2001 2:13 PM To: Webdav WG Subject: Locking, moving and deleting In general, I think WebDAV ties locks to resources. I think this is embodied in a few things we take for granted: - DELETE a resource, and its lock goes away. - LOCK a URI that doesn't have a resource, and DAV requires you to create one (a LNR). However, there's a statement in the spec that flies in the face of that: "A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. " You could justify that exception by saying yes, in general, locks are tied to resources but do not survive moves. But does that work?? What if you MOVE (or rename!) a collection that has locked or lock-null resources inside it? If you follow the logic that locks do not survive moves, then you must: - remove all the locks of all the children, including LNRs - remove the LNRs, now that their locks are gone Does any server follow that behaviour? Or are locks in practice preserved on some or all MOVE operations? lisa From w3c-dist-auth-request@w3.org Sat Sep 29 18:13:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26594 for ; Sat, 29 Sep 2001 18:13:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA21446; Sat, 29 Sep 2001 18:10:21 -0400 (EDT) Resent-Date: Sat, 29 Sep 2001 18:10:21 -0400 (EDT) Resent-Message-Id: <200109292210.SAA21446@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA21426 for ; Sat, 29 Sep 2001 18:10:03 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA23033 for ; Sat, 29 Sep 2001 18:10:02 -0400 Received: from beaver ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f8TM9IA08854; Sat, 29 Sep 2001 15:09:18 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Clemm, Geoff" , "Webdav WG" Date: Sat, 29 Sep 2001 15:08:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AC1E@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: Locking, moving and deleting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5377 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Behalf Of Clemm, Geoff > > The best way to explain the defined MOVE semantics for a LOCK > is to say that a LOCK is on a URL, but that it is deleted > when the resource mapped to that URL is deleted. So far I can follow; it's not a bad model. I'd append "or moved" to the end; most people will consider this different than "deleted" because we have different methods for MOVE and DELETE. I don't follow your example as well (reproduced below) because WebDAV doesn't specifically allow for one resource to be mapped by several URLs. Let's keep it simple and assume that a WebDAV system only maps URLs to resources 1:1. That means that when a collection containing null resources is moved or is renamed, all the locks in the collection disappear, and the null resources must be cleaned up. That seems contrary to what the users would like to see happen; that's the scenario that made me rethink the way this works. Lisa --- Geoff's example: > > So a MOVE of a collection will delete all locks on URL's for that > collection, > but that doesn't necessarily remove all locks on the resources in that > collection. > For example, suppose the URL /x/foo.html and /y/bar.html are mapped to the > same resource. If you LOCK /x/foo.html, and then MOVE /x/foo.html to > /z/foo.html, > the resource mapped to /z/foo.html is no longer locked. If on the other > hand, > you LOCK /z/bar.html and then do the same MOVE, the resource mapped to > /z/foo.html > remains locked. > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Friday, September 28, 2001 2:13 PM > To: Webdav WG > Subject: Locking, moving and deleting > > > In general, I think WebDAV ties locks to resources. I think this is > embodied in a few things we take for granted: > > - DELETE a resource, and its lock goes away. > - LOCK a URI that doesn't have a resource, and DAV requires you to create > one (a LNR). > > However, there's a statement in the spec that flies in the face > of that: "A > successful MOVE request on a write locked resource MUST NOT move the write > lock with the resource. " > > You could justify that exception by saying yes, in general, locks are tied > to resources but do not survive moves. But does that work?? What if you > MOVE (or rename!) a collection that has locked or lock-null > resources inside > it? If you follow the logic that locks do not survive moves, > then you must: > - remove all the locks of all the children, including LNRs > - remove the LNRs, now that their locks are gone > > Does any server follow that behaviour? Or are locks in practice preserved > on some or all MOVE operations? > > lisa From w3c-dist-auth-request@w3.org Sun Sep 30 01:29:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04170 for ; Sun, 30 Sep 2001 01:29:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA00600; Sun, 30 Sep 2001 01:25:13 -0400 (EDT) Resent-Date: Sun, 30 Sep 2001 01:25:13 -0400 (EDT) Resent-Message-Id: <200109300525.BAA00600@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA00575 for ; Sun, 30 Sep 2001 01:25:00 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37016.rational.com [192.229.37.16]) by tux.w3.org (8.9.3/8.9.3) with SMTP id BAA15704 for ; Sun, 30 Sep 2001 01:25:01 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 30 Sep 2001 01:24:29 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 30 Sep 2001 01:24:29 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B104652BD7@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Sun, 30 Sep 2001 01:24:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Locking, moving and deleting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5378 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Lisa Dusseault [mailto:lisa@xythos.com] On Behalf Of Clemm, Geoff > The best way to explain the defined MOVE semantics for a LOCK > is to say that a LOCK is on a URL, but that it is deleted > when the resource mapped to that URL is deleted. So far I can follow; it's not a bad model. I'd append "or moved" to the end; most people will consider this different than "deleted" because we have different methods for MOVE and DELETE. I agree that is worth making explicit to avoid any confusion. I don't follow your example as well (reproduced below) because WebDAV doesn't specifically allow for one resource to be mapped by several URLs. WebDAV allows for one resource to be mapped to multiple URL's because HTTP specifically allows for one resource to be mapped to multiple URL's. In particular, section 9.6 of RFC 2616: "A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version." Therefore the locking protocol (and the rest of WebDAV) must have well defined behavior in those cases where multiple URL's do identify the same resource. Let's keep it simple and assume that a WebDAV system only maps URLs to resources 1:1. That's fine, but it is good to keep the multiple mapping scenario in mind for when someone suggests a "simpler" model that does not handle the multiple mapping scenario. That means that when a collection containing null resources is moved or is renamed, all the locks in the collection disappear, and the null resources must be cleaned up. That seems contrary to what the users would like to see happen; that's the scenario that made me rethink the way this works. The loss of the locks is inherent in a "lock is on the URL" model. The reason the "lock is on the URL" model is superior to the "lock is on the resource" model can be seen by looking at the two cases for moving a locked resource. - If the client holding the lock does the move, it can easily lock the destination collection with a new depth lock, and then perform the move (the resources will be captured by the new depth lock). - If some other client not holding that lock does the move (if it is a shared lock, for example), there often is no good way for for the client to "find" the resource after it has been moved (since all the client has is a URL and a lock token). While we were debating this a while back, several vendors objected to the proposal that we require a server to allow a client to easily find a locked resource by using the lock token (PROPFIND Depth:Infinity on "/" is not considered a good way :-). Also, note that the current proposal for LOCK'ing an unmapped resource (i.e. creating a real resource there) would leave those empty resources in place to be captured by the depth lock at the destination. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Sep 30 08:48:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22360 for ; Sun, 30 Sep 2001 08:48:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA09256; Sun, 30 Sep 2001 08:46:04 -0400 (EDT) Resent-Date: Sun, 30 Sep 2001 08:46:04 -0400 (EDT) Resent-Message-Id: <200109301246.IAA09256@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA09234 for ; Sun, 30 Sep 2001 08:45:55 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA16768 for ; Sun, 30 Sep 2001 08:45:54 -0400 Received: (qmail 17645 invoked by uid 0); 30 Sep 2001 12:45:23 -0000 Received: from pd9e51d04.dip.t-dialin.net (HELO lisa) (217.229.29.4) by mail.gmx.net (mp007-rz3) with SMTP; 30 Sep 2001 12:45:23 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Sun, 30 Sep 2001 14:46:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5379 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Friday, September 28, 2001 12:10 AM > To: Webdav WG > Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner > ... > > 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. I think it makes sense to report a set of URLs (for instance phone number, email address, homepage). Which URL is which could be flagged using the xlink:role attribute (). A user agent can then select the type of links it can process (for instance offering to invoke the mail program or to issue a phone call). > ...