From w3c-dist-auth-request@w3.org Sat Jul 3 15:10:55 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12113 for ; Sat, 3 Jul 2004 15:10:55 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id EEBDCA120E; Sat, 3 Jul 2004 15:10:51 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 80AB8A120E for ; Sat, 3 Jul 2004 15:10:46 -0400 (EDT) Received: from mail.gmx.net ([213.165.64.20]) by dr-nick.w3.org with smtp (Exim 4.32) id 1BgpsU-0005R2-Hk for w3c-dist-auth@w3.org; Sat, 03 Jul 2004 15:08:46 -0400 Received: (qmail 5947 invoked by uid 65534); 3 Jul 2004 19:08:14 -0000 Received: from pD9FF02EB.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.2.235) by mail.gmx.net (mp006) with SMTP; 03 Jul 2004 21:08:14 +0200 X-Authenticated: #1915285 Message-ID: <40E70416.7050701@gmx.de> Date: Sat, 03 Jul 2004 21:08:06 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: lockroot description in rfc2518bis-05 X-Archived-At: http://www.w3.org/mid/40E70416.7050701@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8663 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: Resent-Message-Id: <20040703191051.EEBDCA120E@frink.w3.org> Resent-Date: Sat, 3 Jul 2004 15:10:51 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, it currently says: "13.4 lockroot XML Element Name: lockroot Namespace: DAV: Purpose: Contains the root URL of the lock, which is the URL of the resource that was addressed in the LOCK request. Description: The href contains a URL with the address of the root of the lock. The server SHOULD include this in all lockdiscovery property values and the response to LOCK requests. Extensibility: MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized. " That doesn't ensure that in the case of multiple URIs mapped to the same resource, the property does indeed contain the URL that was addressed by the LOCK request. Thus, I'd propose the following change: Purpose: Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Jul 3 17:58:17 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23922 for ; Sat, 3 Jul 2004 17:58:16 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7334EA12CB; Sat, 3 Jul 2004 17:58:18 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id D18BEA06E7 for ; Sat, 3 Jul 2004 17:58:16 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.103]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BgsWW-00006c-N8 for w3c-dist-auth@w3.org; Sat, 03 Jul 2004 17:58:16 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i63Lvhws705092 for ; Sat, 3 Jul 2004 17:57:43 -0400 Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i63LwqUC112364 for ; Sat, 3 Jul 2004 17:58:52 -0400 In-Reply-To: <40E70416.7050701@gmx.de> To: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Sat, 3 Jul 2004 17:58:03 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/03/2004 17:56:59, Serialize complete at 07/03/2004 17:56:59 Content-Type: multipart/alternative; boundary="=_alternative 0078A40485256EC6_=" Subject: Re: lockroot description in rfc2518bis-05 X-Archived-At: http://www.w3.org/mid/OF4E8C51C1.1EDA7A6E-ON85256EC6.00787D40-85256EC6.0078A405@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8664 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: Resent-Message-Id: <20040703215818.7334EA12CB@frink.w3.org> Resent-Date: Sat, 3 Jul 2004 17:58:18 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 0078A40485256EC6_= Content-Type: text/plain; charset="US-ASCII" I agree with this change. Cheers, Geoff Julian wrote on 07/03/2004 03:08:06 PM: > it currently says: > > "13.4 lockroot XML Element > > Name: lockroot > Namespace: DAV: > Purpose: Contains the root URL of the lock, which is the URL of the > resource that was addressed in the LOCK request. > Description: The href contains a URL with the address of the root of > the lock. The server SHOULD include this in all > lockdiscovery property values and the response to LOCK > requests. > Extensibility: MAY be extended with additional child elements or > attributes which SHOULD be ignored if not recognized. > > " > > That doesn't ensure that in the case of multiple URIs mapped to the same > resource, the property does indeed contain the URL that was addressed by > the LOCK request. Thus, I'd propose the following change: > > Purpose: Contains the root URL of the lock, which is the URL through > which the resource was addressed in the LOCK request. --=_alternative 0078A40485256EC6_= Content-Type: text/html; charset="US-ASCII"
I agree with this change.

Cheers,
Geoff

Julian wrote on 07/03/2004 03:08:06 PM: > it currently says: > > "13.4 lockroot XML Element > > Name: lockroot > Namespace: DAV: > Purpose: Contains the root URL of the lock, which is the URL of the > resource that was addressed in the LOCK request. > Description: The href contains a URL with the address of the root of > the lock. The server SHOULD include this in all > lockdiscovery property values and the response to LOCK > requests. > Extensibility: MAY be extended with additional child elements or > attributes which SHOULD be ignored if not recognized. > > <!ELEMENT lockroot (href) >" > > That doesn't ensure that in the case of multiple URIs mapped to the same > resource, the property does indeed contain the URL that was addressed by > the LOCK request. Thus, I'd propose the following change: > > Purpose: Contains the root URL of the lock, which is the URL through > which the resource was addressed in the LOCK request. --=_alternative 0078A40485256EC6_=-- From w3c-dist-auth-request@w3.org Sat Jul 3 19:15:25 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27608 for ; Sat, 3 Jul 2004 19:15:25 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id D6E2EA0C89; Sat, 3 Jul 2004 19:15:25 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BC576A0C89 for ; Sat, 3 Jul 2004 19:15:24 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BgtjA-00061I-KJ for w3c-dist-auth@w3.org; Sat, 03 Jul 2004 19:15:24 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i63NFNfL032098 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Sat, 3 Jul 2004 16:15:23 -0700 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by bandage.seagull.net (8.12.10) with ESMTP id i63NFBZS031855 sender ccjason@us.ibm.com; Sat, 3 Jul 2004 16:15:12 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i63NEivR638316; Sat, 3 Jul 2004 19:14:48 -0400 Received: from d01ml604.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i63NFa25117348; Sat, 3 Jul 2004 19:15:36 -0400 To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Sat, 3 Jul 2004 19:14:43 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/03/2004 19:14:44, Serialize complete at 07/03/2004 19:14:44 Content-Type: multipart/alternative; boundary="=_alternative 007F326285256EC6_=" Subject: Re: lockroot description in rfc2518bis-05 X-Archived-At: http://www.w3.org/mid/OF398AA79C.D10DA29B-ON85256EC6.007F162B-85256EC6.007FB220@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8665 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: Resent-Message-Id: <20040703231525.D6E2EA0C89@frink.w3.org> Resent-Date: Sat, 3 Jul 2004 19:15:25 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 007F326285256EC6_= Content-Type: text/plain; charset="us-ascii" On Saturday, 07/03/2004 at 05:58 AST, Geoffrey M Clemm/Lexington/IBM@IBMUS wrote: > I agree with this change. I also agree. --=_alternative 007F326285256EC6_= Content-Type: text/html; charset="us-ascii"
On Saturday, 07/03/2004 at 05:58 AST, Geoffrey M Clemm/Lexington/IBM@IBMUS wrote:
> I agree with this change.

I also agree.
--=_alternative 007F326285256EC6_=-- From w3c-dist-auth-request@w3.org Sun Jul 4 05:46:06 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03429 for ; Sun, 4 Jul 2004 05:46:06 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 505A2A1862; Sun, 4 Jul 2004 05:46:07 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EB180A18A9 for ; Sun, 4 Jul 2004 05:46:05 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1Bh3ZV-0000Tp-Kc for w3c-dist-auth@w3.org; Sun, 04 Jul 2004 05:46:05 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i649k3fb000327 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Sun, 4 Jul 2004 02:46:03 -0700 Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i649jv8N032681 sender julian.reschke@gmx.de for ; Sun, 4 Jul 2004 02:45:58 -0700 Received: (qmail 6641 invoked by uid 65534); 4 Jul 2004 09:45:42 -0000 Received: from pD9535E0F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.15) by mail.gmx.net (mp005) with SMTP; 04 Jul 2004 11:45:42 +0200 Message-ID: <40E7D1B9.7040701@gmx.de> Date: Sun, 04 Jul 2004 11:45:29 +0200 From: Julian Reschke MIME-Version: 1.0 To: WebDAV Cc: Jason Crawford , Lisa Dusseault Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: Call for consensus on UNLOCK Request-URI being lock root X-Archived-At: http://www.w3.org/mid/40E7D1B9.7040701@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8666 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: Resent-Message-Id: <20040704094607.505A2A1862@frink.w3.org> Resent-Date: Sun, 4 Jul 2004 05:46:07 -0400 (EDT) Julian Reschke wrote: >> On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault wrote: >> > This would overturn a consensus that had previously been determined at >> > a WG meeting that happened together with an interoperability meeting, >> > and the consensus was not challenged on the mailing list at that time. >> > >> > However, given that we have new information -- actual research! >> > (thanks) -- it does make sense to reconsider. >> > >> > WG members please indicate your old, new, and/ or current preference, >> > with reasons if they've not already been stated here: >> > 1. Should servers accept an UNLOCK request where the Request-URI names >> > any resource covered by the lock named in the lock token? >> > 2. Or, should servers redirect that UNLOCK request to the root of the >> > lock? >> > 3. If something else, please explain. >> >> >> No strong preference so just go with what existing servers do. > > > What do you mean by "redirect"? Please be more specific. > ... Lisa, could you please define what you mean by "redirect"? Otherwise it won't be possible to say something about that option. The other option we have is... 3. Server should reject the UNLOCK request if it doesn't address the directly locked resource. As stated before, my preference is 1) for the simple reasons that - this is what RFC2518 seems to say, - this is what the issues list says as resolution, - this is what GULP says after having it synced with the issues list and - last but not least this is what servers indeed implement. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Jul 4 17:23:26 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02135 for ; Sun, 4 Jul 2004 17:23:26 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7AF92A0E3F; Sun, 4 Jul 2004 17:23:26 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 685D0A0E30 for ; Sun, 4 Jul 2004 17:23:24 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhESK-0003AH-Ab for w3c-dist-auth@w3.org; Sun, 04 Jul 2004 17:23:24 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i64LNMxg020521 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Sun, 4 Jul 2004 14:23:22 -0700 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by bandage.seagull.net (8.12.10) with ESMTP id i64LNFi5020449 sender ccjason@us.ibm.com; Sun, 4 Jul 2004 14:23:15 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i64LMqvR849880; Sun, 4 Jul 2004 17:22:52 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i64LO01p086442; Sun, 4 Jul 2004 17:24:01 -0400 To: Julian Reschke Cc: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Sun, 4 Jul 2004 17:22:50 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/04/2004 17:22:51, Serialize complete at 07/04/2004 17:22:51 Content-Type: multipart/alternative; boundary="=_alternative 0074FFAA85256EC7_=" Subject: Re: Call for consensus on UNLOCK Request-URI being lock root X-Archived-At: http://www.w3.org/mid/OF4E8CD666.4FA761EB-ON85256EC7.0074C44E-85256EC7.007573DB@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8667 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: Resent-Message-Id: <20040704212326.7AF92A0E3F@frink.w3.org> Resent-Date: Sun, 4 Jul 2004 17:23:26 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 0074FFAA85256EC7_= Content-Type: text/plain; charset="us-ascii" On Wednesday, 06/30/2004 at 08:37 ZE2, Julian Reschke wrote: > Lisa Dusseault wrote: > > > Yes, I read these today, but it was my interpretation that this testing > > applied to the UNLOCK request. What about LOCK request to refresh a > > lock? Does that also work on resources other than the lock root? I > > think servers would probably implement them the same way, but I was > > curious whether you'd tested it explicitly. > > Sorry. Related to this is > , > but that is about URLs in tagged "If" headers (where I found that > servers do not seem to care). > > Right now I'm saying... > > "4.2.3.1 DAV:locks-refreshed postcondition > > Timers associated with the those locks submitted in the "If" request > header whose lock root is the resource identified by the Request-URI > MUST be reset to their original value (or alternatively to the new value > given in the "Timeout" request header)." > > .basically because it seems nobody asked that question before. > Assuming we'd find out that servers do not care for LOCK/refresh either, > would we want to relax the spec text? I'd relax the server side to accept refresh requests at any resource in the scope of the lock. Unless given a reason though, I'd still encourage servers to send the refresh requests to the root of the lock. J. --=_alternative 0074FFAA85256EC7_= Content-Type: text/html; charset="us-ascii"
On Wednesday, 06/30/2004 at 08:37 ZE2, Julian Reschke wrote:
> Lisa Dusseault wrote:
>
> > Yes, I read these today, but it was my interpretation that this testing
> > applied to the UNLOCK request. What about LOCK request to refresh a
> > lock? Does that also work on resources other than the lock root? I
> > think servers would probably implement them the same way, but I was
> > curious whether you'd tested it explicitly.
>
> Sorry. Related to this is
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0191.html>,
> but that is about URLs in tagged "If" headers (where I found that
> servers do not seem to care).
>
> Right now I'm saying...
>
> "4.2.3.1 DAV:locks-refreshed postcondition
>
> Timers associated with the those locks submitted in the "If" request
> header whose lock root is the resource identified by the Request-URI
> MUST be reset to their original value (or alternatively to the new value
> given in the "Timeout" request header)."
>
> .basically because it seems nobody asked that question before.
> Assuming we'd find out that servers do not care for LOCK/refresh either,
> would we want to relax the spec text?

I'd relax the server side to accept refresh requests at any resource in the scope of the lock. Unless given a reason though, I'd still encourage servers to send the refresh requests to the root of the lock.

J.
--=_alternative 0074FFAA85256EC7_=-- From w3c-dist-auth-request@w3.org Sun Jul 4 19:17:13 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07549 for ; Sun, 4 Jul 2004 19:17:12 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 5A75BA05E9; Sun, 4 Jul 2004 19:17:13 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0CEABA05E9 for ; Sun, 4 Jul 2004 19:17:12 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhGER-0004ga-Ty for w3c-dist-auth@w3.org; Sun, 04 Jul 2004 19:17:12 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i64NHA9G028684 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Sun, 4 Jul 2004 16:17:10 -0700 Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i64NH70u028626 sender julian.reschke@gmx.de for ; Sun, 4 Jul 2004 16:17:08 -0700 Received: (qmail 25665 invoked by uid 65534); 4 Jul 2004 23:16:55 -0000 Received: from pD9E51F96.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.31.150) by mail.gmx.net (mp017) with SMTP; 05 Jul 2004 01:16:55 +0200 Message-ID: <40E88FE1.20508@gmx.de> Date: Mon, 05 Jul 2004 01:16:49 +0200 From: Julian Reschke MIME-Version: 1.0 To: Jason Crawford Cc: Julian Reschke , nnw3c-dist-auth___at___w3.org@smallcue.com Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: Call for consensus on UNLOCK Request-URI being lock root X-Archived-At: http://www.w3.org/mid/40E88FE1.20508@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8668 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: Resent-Message-Id: <20040704231713.5A75BA05E9@frink.w3.org> Resent-Date: Sun, 4 Jul 2004 19:17:13 -0400 (EDT) Jason Crawford wrote: > I'd relax the server side to accept refresh requests at any resource in > the scope of the lock. Unless given a reason though, I'd still > encourage servers to send the refresh requests to the root of the lock. I guess you mean "clients" in the second sentence. The problem with this approach is that it makes little sense in a specification. If we say that servers SHOULD allow refresh against indirectly locked resources, it doesn't make sense to tell clients not to use it. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Jul 5 11:42:23 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03884 for ; Mon, 5 Jul 2004 11:42:23 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 2B915A1392; Mon, 5 Jul 2004 11:42:22 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 1703AA0B42 for ; Mon, 5 Jul 2004 11:42:21 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhVbo-00087b-Pi for w3c-dist-auth@w3.org; Mon, 05 Jul 2004 11:42:21 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i65FgIbu000780 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Mon, 5 Jul 2004 08:42:18 -0700 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by bandage.seagull.net (8.12.10) with ESMTP id i65Feg0B032709 sender ccjason@us.ibm.com; Mon, 5 Jul 2004 08:40:43 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i65FeKvR785064; Mon, 5 Jul 2004 11:40:20 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i65FfTaH116270; Mon, 5 Jul 2004 11:41:29 -0400 To: Julian Reschke Cc: nnw3c-dist-auth___at___w3.org@smallcue.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Mon, 5 Jul 2004 11:40:15 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/05/2004 11:40:20, Serialize complete at 07/05/2004 11:40:20 Content-Type: multipart/alternative; boundary="=_alternative 00560F3C85256EC8_=" Subject: Re: Call for consensus on UNLOCK Request-URI being lock root X-Archived-At: http://www.w3.org/mid/OF3D60E98C.F6035EA5-ON85256EC8.00552D86-85256EC8.00561722@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8669 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: Resent-Message-Id: <20040705154222.2B915A1392@frink.w3.org> Resent-Date: Mon, 5 Jul 2004 11:42:22 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 00560F3C85256EC8_= Content-Type: text/plain; charset="us-ascii" On Monday, 07/05/2004 at 01:16 ZE2, Julian Reschke wrote: > Jason Crawford wrote: > > > I'd relax the server side to accept refresh requests at any resource in > > the scope of the lock. Unless given a reason though, I'd still > > encourage servers to send the refresh requests to the root of the lock. > > I guess you mean "clients" in the second sentence. Correct. > The problem with this approach is that it makes little sense in a > specification. If we say that servers SHOULD allow refresh against > indirectly locked resources, it doesn't make sense to tell clients not > to use it. I think it does make sense from the perspective of flexibility, and we've done it before, but I don't have a strong preference. My stronger preference is that we move forward. J. --=_alternative 00560F3C85256EC8_= Content-Type: text/html; charset="us-ascii"
On Monday, 07/05/2004 at 01:16 ZE2, Julian Reschke wrote:
> Jason Crawford wrote:
>
> > I'd relax the server side to accept refresh requests at any resource in
> > the scope of the lock. Unless given a reason though, I'd still
> > encourage servers to send the refresh requests to the root of the lock.
>
> I guess you mean "clients" in the second sentence.
Correct.

> The problem with this approach is that it makes little sense in a
> specification. If we say that servers SHOULD allow refresh against
> indirectly locked resources, it doesn't make sense to tell clients not
> to use it.
I think it does make sense from the perspective of flexibility, and we've done it before, but I don't have a strong preference. My stronger preference is that we move forward.

J.

--=_alternative 00560F3C85256EC8_=-- From w3c-dist-auth-request@w3.org Tue Jul 6 09:08:35 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12346 for ; Tue, 6 Jul 2004 09:08:34 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 0344EA0887; Tue, 6 Jul 2004 09:08:35 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from websh1.gcsu.edu (mn.gcsu.edu [168.16.211.63]) by frink.w3.org (Postfix) with ESMTP id 179B2A0887 for ; Tue, 6 Jul 2004 09:08:31 -0400 (EDT) Received: from mn.gcsu.edu(168.16.211.63) by websh1.gcsu.edu via csmap id ab9e939e_cf4d_11d8_982a_00304811f47f_22489; Tue, 06 Jul 2004 09:09:12 -0400 (EDT) Received: from websh1.gcsu.edu (sleepy.gcsu.edu [168.16.213.98]) by mn.gcsu.edu (Switch-3.1.0/Switch-3.1.0) with ESMTP id i66D8RG5029936; Tue, 6 Jul 2004 09:08:28 -0400 Received: from sleepy.gcsu.edu(168.16.213.98) by websh1.gcsu.edu via csmap id a97809ba_cf4d_11d8_8f92_00304811f47f_14313; Tue, 06 Jul 2004 09:09:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: frank.lowney@gcsu.edu@mail.gcsu.edu Message-Id: Date: Tue, 6 Jul 2004 09:08:26 -0400 To: w3c-dist-auth@frink.w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" Subject: WindowsXP and double login challenges X-Archived-At: http://www.w3.org/mid/p06110403bd10512fc23a@%5B168.16.213.98%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8670 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: Resent-Message-Id: <20040706130835.0344EA0887@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 09:08:35 -0400 (EDT) We are currently working with three WebDAV-enabled servers as follows: WebSTAR V v.5.3.2 on MacOS X 10.3.4 Apache on MacOS X Server 10.3.4 BEA Weblogic (supporting WebCT Vista) on Solaris. Using WindowsXP & 'My Network Places,' we and our various clients and other constituencies are consistently seeing a "double login challenge" in all three cases. We don't see this issue on Win2K Pro or MacOS X. First, can anyone confirm that this is a "Microsoft not following standards again" issue? Second, can anyone suggest a work around that will unburden WinXP WebDAV users from the necessity of meeting this challenge twice? Thanks for any light shed on this issue. -- ===================================================================== Dr. Frank Lowney frank.lowney@gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 NOTICE: Please be advised that I am hearing impaired and communicate most effectively via e-mail. Follow-up summaries of telephone conversations by e-mail are most appreciated. ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Tue Jul 6 10:13:05 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17769 for ; Tue, 6 Jul 2004 10:13:05 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 37A72A2112; Tue, 6 Jul 2004 10:13:03 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id AF05CA0801 for ; Tue, 6 Jul 2004 10:12:57 -0400 (EDT) Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhqfY-00011a-5k for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 10:11:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17505; Tue, 6 Jul 2004 10:11:31 -0400 (EDT) Message-Id: <200407061411.KAA17505@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Date: Tue, 06 Jul 2004 10:11:31 -0400 Subject: I-D ACTION:draft-ietf-webdav-bind-06.txt X-Archived-At: http://www.w3.org/mid/200407061411.KAA17505@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8671 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: Resent-Message-Id: <20040706141303.37A72A2112@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 10:13:03 -0400 (EDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) Author(s) : G. Clemm, et al. Filename : draft-ietf-webdav-bind-06.txt Pages : 33 Date : 2004-7-2 This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-webdav-bind-06.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-ietf-webdav-bind-06.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 Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-2121630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-bind-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-bind-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-2121630.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Jul 6 10:54:44 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21236 for ; Tue, 6 Jul 2004 10:54:44 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 2D020A0870; Tue, 6 Jul 2004 10:54:46 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9DD11A0870 for ; Tue, 6 Jul 2004 10:54:44 -0400 (EDT) Received: from cats-mx1.ucsc.edu ([128.114.125.34] helo=ucsc.edu) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhrLI-0000rN-DG for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 10:54:44 -0400 Received: from Tycho (dhcp-63-146.cse.ucsc.edu [128.114.63.146]) by ucsc.edu (8.10.1/8.10.1) with SMTP id i66Eq8d22112 for ; Tue, 6 Jul 2004 07:52:09 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 6 Jul 2004 07:56:17 -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.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: WindowsXP and double login challenges X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIEEMDLCAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8672 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: Resent-Message-Id: <20040706145446.2D020A0870@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 10:54:46 -0400 (EDT) Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. -Jim -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Frank Lowney Sent: Tuesday, July 06, 2004 6:08 AM To: w3c-dist-auth@frink.w3.org Subject: WindowsXP and double login challenges We are currently working with three WebDAV-enabled servers as follows: WebSTAR V v.5.3.2 on MacOS X 10.3.4 Apache on MacOS X Server 10.3.4 BEA Weblogic (supporting WebCT Vista) on Solaris. Using WindowsXP & 'My Network Places,' we and our various clients and other constituencies are consistently seeing a "double login challenge" in all three cases. We don't see this issue on Win2K Pro or MacOS X. First, can anyone confirm that this is a "Microsoft not following standards again" issue? Second, can anyone suggest a work around that will unburden WinXP WebDAV users from the necessity of meeting this challenge twice? Thanks for any light shed on this issue. -- ===================================================================== Dr. Frank Lowney frank.lowney@gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 NOTICE: Please be advised that I am hearing impaired and communicate most effectively via e-mail. Follow-up summaries of telephone conversations by e-mail are most appreciated. ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Tue Jul 6 11:38:35 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23968 for ; Tue, 6 Jul 2004 11:38:35 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id F32B1A2230; Tue, 6 Jul 2004 11:38:33 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8D55EA21F8 for ; Tue, 6 Jul 2004 11:38:29 -0400 (EDT) Received: from betlik.darwin.nasa.gov ([198.123.160.11] helo=dream.darwin.nasa.gov) by dr-nick.w3.org with esmtp (Exim 4.32) id 1Bhs1d-0000VW-7g for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 11:38:29 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i66FcRL06672 for ; Tue, 6 Jul 2004 08:38:27 -0700 (PDT) Message-ID: <40EAC773.3080607@cse.ucsc.edu> Date: Tue, 06 Jul 2004 08:38:27 -0700 From: Elias Sinderson User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV References: <40E70416.7050701@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: lockroot description in rfc2518bis-05 X-Archived-At: http://www.w3.org/mid/40EAC773.3080607@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8673 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: Resent-Message-Id: <20040706153833.F32B1A2230@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 11:38:33 -0400 (EDT) Content-Transfer-Encoding: 7bit The proposed change makes sense to me as well. Cheers, Elias Julian Reschke wrote: > > Hi, > > it currently says: > > "13.4 lockroot XML Element > > Name: lockroot > Namespace: DAV: > Purpose: Contains the root URL of the lock, which is the URL of the > resource that was addressed in the LOCK request. > Description: The href contains a URL with the address of the root of > the lock. The server SHOULD include this in all > lockdiscovery property values and the response to LOCK > requests. > Extensibility: MAY be extended with additional child elements or > attributes which SHOULD be ignored if not recognized. > > " > > That doesn't ensure that in the case of multiple URIs mapped to the > same resource, the property does indeed contain the URL that was > addressed by the LOCK request. Thus, I'd propose the following change: > > Purpose: Contains the root URL of the lock, which is the URL through > which the resource was addressed in the LOCK request. > > Best regards, Julian > > From w3c-dist-auth-request@w3.org Tue Jul 6 11:45:05 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24610 for ; Tue, 6 Jul 2004 11:45:05 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 9D354A2245; Tue, 6 Jul 2004 11:45:07 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E53C9A2245 for ; Tue, 6 Jul 2004 11:45:05 -0400 (EDT) Received: from betlik.darwin.nasa.gov ([198.123.160.11] helo=dream.darwin.nasa.gov) by dr-nick.w3.org with esmtp (Exim 4.32) id 1Bhs81-00028Q-47 for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 11:45:05 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i66Fj4L06699 for ; Tue, 6 Jul 2004 08:45:04 -0700 (PDT) Message-ID: <40EAC900.3080809@cse.ucsc.edu> Date: Tue, 06 Jul 2004 08:45:04 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: multipart/alternative; boundary="------------020402080705050606010607" Subject: Re: Call for consensus on UNLOCK Request-URI being lock root X-Archived-At: http://www.w3.org/mid/40EAC900.3080809@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8674 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: Resent-Message-Id: <20040706154507.9D354A2245@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 11:45:07 -0400 (EDT) --------------020402080705050606010607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jason Crawford wrote: > On Monday, 07/05/2004 at 01:16 ZE2, Julian Reschke wrote: > > The problem with this approach is that it makes little sense in a > > specification. If we say that servers SHOULD allow refresh against > > indirectly locked resources, it doesn't make sense to tell clients not > > to use it. > I think it does make sense from the perspective of flexibility, and > we've done it before, but I don't have a strong preference. My > stronger preference is that we move forward. I agree with Jason: servers SHOULD allow refresh against indirectly locked resources, thereby allowing for clients the option to refresh the lock on a single resource while letting the lock expire on other resources. Without supporting this, the client would have to unlock and the lock the resource, thereby making it possible for another client to lock the resource in the interim. Cheers, Elias --------------020402080705050606010607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jason Crawford wrote:

On Monday, 07/05/2004 at 01:16 ZE2, Julian Reschke wrote:
> The problem with this approach is that it makes little sense in a
> specification. If we say that servers SHOULD allow refresh against
> indirectly locked resources, it doesn't make sense to tell clients not
> to use it.
I think it does make sense from the perspective of flexibility, and we've done it before, but I don't have a strong preference. My stronger preference is that we move forward.

I agree with Jason: servers SHOULD allow refresh against indirectly locked resources, thereby allowing for clients the option to refresh the lock on a single resource while letting the lock expire on other resources. Without supporting this, the client would have to unlock and the lock the resource, thereby making it possible for another client to lock the resource in the interim.

Cheers,
Elias
--------------020402080705050606010607-- From w3c-dist-auth-request@w3.org Tue Jul 6 12:09:31 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27401 for ; Tue, 6 Jul 2004 12:09:31 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C4F8BA22C1; Tue, 6 Jul 2004 12:09:32 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9B307A22BC for ; Tue, 6 Jul 2004 12:09:31 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhsVf-0006qN-Il for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 12:09:31 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i66G90Cc425128 for ; Tue, 6 Jul 2004 12:09:00 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i66G9o4A111612 for ; Tue, 6 Jul 2004 12:09:51 -0400 In-Reply-To: <40EAC900.3080809@cse.ucsc.edu> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 6 Jul 2004 12:09:18 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/06/2004 12:08:11, Serialize complete at 07/06/2004 12:08:11 Content-Type: multipart/alternative; boundary="=_alternative 0058B66085256EC9_=" Subject: Re: Call for consensus on UNLOCK Request-URI being lock root X-Archived-At: http://www.w3.org/mid/OF69FE9935.8787C0DE-ON85256EC9.00582049-85256EC9.0058B664@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8675 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: Resent-Message-Id: <20040706160932.C4F8BA22C1@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 12:09:32 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 0058B66085256EC9_= Content-Type: text/plain; charset="US-ASCII" You cannot create a new exclusive write lock rooted at the indirectly locked resource, because that would violate the requirement that a resource can only be locked by one exclusive lock. So the issue being discussed is just whether or not the refresh of the lock has to be applied to the URL of the root of the lock, or whether it can be applied to the URL of an indirectly locked resource and then be automatically redirected by the server to the URL of the root of the lock. Cheers, Geoff Elias wrote on 07/06/2004 11:45:04 AM: > Jason Crawford wrote: > On Monday, 07/05/2004 at 01:16 ZE2, Julian Reschke wrote: > > The problem with this approach is that it makes little sense in a > > specification. If we say that servers SHOULD allow refresh against > > indirectly locked resources, it doesn't make sense to tell clients not > > to use it. > I think it does make sense from the perspective of flexibility, and > we've done it before, but I don't have a strong preference. My > stronger preference is that we move forward. > I agree with Jason: servers SHOULD allow refresh against indirectly > locked resources, thereby allowing for clients the option to refresh > the lock on a single resource while letting the lock expire on other > resources. Without supporting this, the client would have to unlock > and the lock the resource, thereby making it possible for another > client to lock the resource in the interim. --=_alternative 0058B66085256EC9_= Content-Type: text/html; charset="US-ASCII"
You cannot create a new exclusive write lock rooted at the indirectly
locked resource, because that would violate the requirement that a
resource can only be locked by one exclusive lock. So the issue being
discussed is just whether or not the refresh of the lock has to be
applied to the URL of the root of the lock, or whether it can be applied
to the URL of an indirectly locked resource and then be automatically
redirected by the server to the URL of the root of the lock.

Cheers,
Geoff

Elias wrote on 07/06/2004 11:45:04 AM: > Jason Crawford wrote:
> On Monday, 07/05/2004 at 01:16 ZE2, Julian Reschke wrote: > > The problem with this approach is that it makes little sense in a > > specification. If we say that servers SHOULD allow refresh against > > indirectly locked resources, it doesn't make sense to tell clients not > > to use it.
> I think it does make sense from the perspective of flexibility, and > we've done it before, but I don't have a strong preference. My > stronger preference is that we move forward.
> I agree with Jason: servers SHOULD allow refresh against indirectly > locked resources, thereby allowing for clients the option to refresh > the lock on a single resource while letting the lock expire on other > resources. Without supporting this, the client would have to unlock > and the lock the resource, thereby making it possible for another > client to lock the resource in the interim. --=_alternative 0058B66085256EC9_=-- From w3c-dist-auth-request@w3.org Tue Jul 6 12:49:11 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01737 for ; Tue, 6 Jul 2004 12:49:11 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 4E0D0A0B36; Tue, 6 Jul 2004 12:49:13 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 33F1BA0B36 for ; Tue, 6 Jul 2004 12:49:12 -0400 (EDT) Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1Bht83-0005mj-Vt for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 12:49:12 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i66GnAJL008333 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 6 Jul 2004 09:49:10 -0700 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63444AA3-CF6C-11D8-8333-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Tue, 6 Jul 2004 09:49:03 -0700 To: WebDAV X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: Re: lockroot description in rfc2518bis-05 X-Archived-At: http://www.w3.org/mid/63444AA3-CF6C-11D8-8333-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8676 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: Resent-Message-Id: <20040706164913.4E0D0A0B36@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 12:49:13 -0400 (EDT) Content-Transfer-Encoding: 7bit OK, will do, this clearly makes it less ambiguous. Lisa On Jul 3, 2004, at 2:58 PM, Geoffrey M Clemm wrote: > I agree with this change. > > Cheers, > Geoff > > Julian wrote on 07/03/2004 03:08:06 PM: > >> it currently says: >> >> "13.4 lockroot XML Element >> >> Name: lockroot >> Namespace: DAV: >> Purpose: Contains the root URL of the lock, which is the URL of >> the >> resource that was addressed in the LOCK request. >> Description: The href contains a URL with the address of the root >> of >> the lock. The server SHOULD include this in all >> lockdiscovery property values and the response to LOCK >> requests. >> Extensibility: MAY be extended with additional child elements or >> attributes which SHOULD be ignored if not recognized. >> >> " >> >> That doesn't ensure that in the case of multiple URIs mapped to the >> same > >> resource, the property does indeed contain the URL that was addressed >> by > >> the LOCK request. Thus, I'd propose the following change: >> >> Purpose: Contains the root URL of the lock, which is the URL >> through >> which the resource was addressed in the LOCK request. > From w3c-dist-auth-request@w3.org Tue Jul 6 13:47:15 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06368 for ; Tue, 6 Jul 2004 13:47:14 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 95CB4A059B; Tue, 6 Jul 2004 13:47:13 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 55921A2345 for ; Tue, 6 Jul 2004 13:46:23 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1Bhtso-0005Ur-IR for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 13:37:30 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i66HbTvu027941 sender lisa@osafoundation.org for w3c-dist-auth@w3.org; Tue, 6 Jul 2004 10:37:29 -0700 Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by bandage.seagull.net (8.12.10) with ESMTP id i66HbSZP027916 sender lisa@osafoundation.org for ; Tue, 6 Jul 2004 10:37:28 -0700 Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i66HbOJL014537 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 6 Jul 2004 10:37:24 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <202D1728-CF73-11D8-8333-000A95B2BB72@osafoundation.org> Cc: WebDAV From: Lisa Dusseault Date: Tue, 6 Jul 2004 10:37:17 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) Subject: Re: Call for consensus on UNLOCK Request-URI being lock root X-Archived-At: http://www.w3.org/mid/202D1728-CF73-11D8-8333-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8677 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: Resent-Message-Id: <20040706174713.95CB4A059B@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 13:47:13 -0400 (EDT) I thought a little more about exactly how the redirect would work and there's a number of options, none of them very good. I think this is moot since we seem to prefer #1 accepting the UNLOCK request even on the "wrong" URL, but a little discussion anyhow... The basic idea is that the client gave the wrong URL in the UNLOCK, and the server can tell which is the right URL to UNLOCK because of the presence of the lock token. So the server is helpful in telling the client which URL to UNLOCK in a 3xx response with the lockroot URL in the Location header, and this response helps the client understand which resource(s) have been unlocked once the UNLOCK request is successful. But how, exactly, would a redirect work? According to RFC2616: - 301 Moved Permanently would imply that the new URL (the lock root) should be used for "any future references". That's not what we want; the original Request-URI could still exist and be used in certain circumstances -- it's only this one request the server suggests should be redirected. - 302 Found would technically work the right way but RFC2616 says that "the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user". I'm not sure user agents would follow that requirement or wish to. - 303 See Other would result in the client sending a GET to the lookroot URL, not a UNLOCK request. - 307 Temporary Redirect would work for HTTP 1.1 user agents, but like 302 "the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user". Lisa On Jul 4, 2004, at 2:45 AM, Julian Reschke wrote: > Julian Reschke wrote: > >>> On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault wrote: >>> > This would overturn a consensus that had previously been >>> determined at >>> > a WG meeting that happened together with an interoperability >>> meeting, >>> > and the consensus was not challenged on the mailing list at that >>> time. >>> > >>> > However, given that we have new information -- actual research! >>> > (thanks) -- it does make sense to reconsider. >>> > >>> > WG members please indicate your old, new, and/ or current >>> preference, >>> > with reasons if they've not already been stated here: >>> > 1. Should servers accept an UNLOCK request where the Request-URI >>> names >>> > any resource covered by the lock named in the lock token? >>> > 2. Or, should servers redirect that UNLOCK request to the root of >>> the >>> > lock? >>> > 3. If something else, please explain. >>> >>> >>> No strong preference so just go with what existing servers do. >> What do you mean by "redirect"? Please be more specific. >> ... > > Lisa, > > could you please define what you mean by "redirect"? Otherwise it > won't be possible to say something about that option. > > The other option we have is... > > 3. Server should reject the UNLOCK request if it doesn't address the > directly locked resource. > > As stated before, my preference is 1) for the simple reasons that > > - this is what RFC2518 seems to say, > - this is what the issues list says as resolution, > - this is what GULP says after having it synced with the issues list > and > - last but not least this is what servers indeed implement. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jul 6 14:26:27 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09899 for ; Tue, 6 Jul 2004 14:26:26 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 75715A2312; Tue, 6 Jul 2004 14:26:26 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id CD81FA2329 for ; Tue, 6 Jul 2004 14:25:48 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhuOt-000403-KO for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 14:10:39 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i66IAcmV026060 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Tue, 6 Jul 2004 11:10:38 -0700 Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i66IAbvW025927 sender julian.reschke@gmx.de for ; Tue, 6 Jul 2004 11:10:37 -0700 Received: (qmail 21536 invoked by uid 65534); 6 Jul 2004 18:10:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.17]) (217.5.201.10) by mail.gmx.net (mp001) with SMTP; 06 Jul 2004 20:10:26 +0200 Message-ID: <40EAEB0F.8070409@gmx.de> Date: Tue, 06 Jul 2004 20:10:23 +0200 From: Julian Reschke MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Subject: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/40EAEB0F.8070409@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8678 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: Resent-Message-Id: <20040706182626.75715A2312@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 14:26:26 -0400 (EDT) Hi, I noticed that RFC2518 historically says little about what a lock actually *is*, instead just describes it's behaviour (which of course needs to be done is well). The result is that essential information if spread across the document; instead of being in a single place. A good example for this is if you look at the various places in RFC2518 that say something about what a timeout is, what it means to refresh it, when the server needs to respect it and so on... Here's what I wrote for (which continues to progress nicely)...: -- 2.5 Status of a lock Having a URI (the lock token URI) on it's own, a lock is a resource in the sense defined by [RFC2396]. In general, this resource does not have a HTTP URL, and thus can not be directly manipulated using HTTP methods. Instead, this specification defines the new methods LOCK (creating and refreshing locks, see Section 4) and UNLOCK (removing locks, see Section 5) that act indirectly on locks. A lock has state that can be indirectly observed by using the DAV:lockdiscovery property defined in Section 3.2. At a minimum, the state of a lock consists of the items defined in the sections below. After lock creation, all parts of the state with the exception of the timeout value are immutable. 2.5.1 Lock Access Type At present, this specification only defines one lock access type, the "write" lock defined in Section xx. 2.5.2 Lock Scope A lock has either exclusive or shared scope (see Section 2.1). 2.5.3 Lock Root A lock is created as effect of a LOCK (creation) method request. The lock root is the URL to which this request was adressed. 2.5.4 Lock Depth A "depth 0" lock only affects the resource to which the LOCK request was adressed to (the lock root). This resource is said to be "directly locked" by the lock. On the other hand, a "depth infinity" lock on a collection additionally affects all members of that collection. These resources are said to be "indirectly locked" by the lock. A "depth infinity" lock on a non-collection resource behaves exactly the same way as a "depth 0" lock. 2.5.5 Lock Owner Clients can submit information about the lock owner when creating a lock. This information should be 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). Owner information is kept with the lock so that it can be returned in the DAV:lockdiscovery property upon request. Note that this information is entirely client-controlled, thus a server MUST store the information faithfully just like if it appeared in a WebDAV dead property (see [RFC2518], section 4). 2.5.6 Lock Timeout In general, a lock expires after a certain amount of time. This time can be specified in the LOCK creation request (however servers are not required to honor this request). If the timeout expires then the lock may be lost. Specifically, if the server wishes to harvest the lock upon time-out, the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with its override authority. Thus logs should be updated with the disposition of the lock, notifications should be sent, etc., just as they would be for an UNLOCK request. The timers used for timeout expiry can be reset by the client by submitting a LOCK refresh request. Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going off-line. A client MUST NOT assume that just because the time-out has expired the lock has been lost. Clients MUST assume that locks may arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if "extraordinary" circumstances do not occur. For example, an administrator may remove a lock at any time or the system may crash in such a way that it loses the record of the lock's existence. -- Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jul 6 14:27:00 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09933 for ; Tue, 6 Jul 2004 14:27:00 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 16EE8A207C; Tue, 6 Jul 2004 14:27:00 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E23D7A2352 for ; Tue, 6 Jul 2004 14:25:53 -0400 (EDT) Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by dr-nick.w3.org with smtp (Exim 4.32) id 1BhudE-0005oM-7E for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 14:25:28 -0400 Received: (qmail 5948 invoked by uid 65534); 6 Jul 2004 18:24:56 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.17]) (217.5.201.10) by mail.gmx.net (mp001) with SMTP; 06 Jul 2004 20:24:56 +0200 X-Authenticated: #1915285 Message-ID: <40EAEE70.3030201@gmx.de> Date: Tue, 06 Jul 2004 20:24:48 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/40EAEE70.3030201@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8679 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: Resent-Message-Id: <20040706182700.16EE8A207C@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 14:27:00 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, I noticed that RFC2518 historically says little about what a lock actually *is*, instead just describes it's behaviour (which of course needs to be done is well). The result is that essential information if spread across the document; instead of being in a single place. A good example for this is if you look at the various places in RFC2518 that say something about what a timeout is, what it means to refresh it, when the server needs to respect it and so on... Here's what I wrote for (which continues to progress nicely)...: -- 2.5 Status of a lock Having a URI (the lock token URI) on it's own, a lock is a resource in the sense defined by [RFC2396]. In general, this resource does not have a HTTP URL, and thus can not be directly manipulated using HTTP methods. Instead, this specification defines the new methods LOCK (creating and refreshing locks, see Section 4) and UNLOCK (removing locks, see Section 5) that act indirectly on locks. A lock has state that can be indirectly observed by using the DAV:lockdiscovery property defined in Section 3.2. At a minimum, the state of a lock consists of the items defined in the sections below. After lock creation, all parts of the state with the exception of the timeout value are immutable. 2.5.1 Lock Access Type At present, this specification only defines one lock access type, the "write" lock defined in Section xx. 2.5.2 Lock Scope A lock has either exclusive or shared scope (see Section 2.1). 2.5.3 Lock Root A lock is created as effect of a LOCK (creation) method request. The lock root is the URL to which this request was adressed. 2.5.4 Lock Depth A "depth 0" lock only affects the resource to which the LOCK request was adressed to (the lock root). This resource is said to be "directly locked" by the lock. On the other hand, a "depth infinity" lock on a collection additionally affects all members of that collection. These resources are said to be "indirectly locked" by the lock. A "depth infinity" lock on a non-collection resource behaves exactly the same way as a "depth 0" lock. 2.5.5 Lock Owner Clients can submit information about the lock owner when creating a lock. This information should be 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). Owner information is kept with the lock so that it can be returned in the DAV:lockdiscovery property upon request. Note that this information is entirely client-controlled, thus a server MUST store the information faithfully just like if it appeared in a WebDAV dead property (see [RFC2518], section 4). 2.5.6 Lock Timeout In general, a lock expires after a certain amount of time. This time can be specified in the LOCK creation request (however servers are not required to honor this request). If the timeout expires then the lock may be lost. Specifically, if the server wishes to harvest the lock upon time-out, the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with its override authority. Thus logs should be updated with the disposition of the lock, notifications should be sent, etc., just as they would be for an UNLOCK request. The timers used for timeout expiry can be reset by the client by submitting a LOCK refresh request. Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going off-line. A client MUST NOT assume that just because the time-out has expired the lock has been lost. Clients MUST assume that locks may arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if "extraordinary" circumstances do not occur. For example, an administrator may remove a lock at any time or the system may crash in such a way that it loses the record of the lock's existence. -- Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jul 6 15:28:41 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15928 for ; Tue, 6 Jul 2004 15:28:41 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 82207A239B; Tue, 6 Jul 2004 15:28:42 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 80CFFA239B for ; Tue, 6 Jul 2004 15:28:40 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhvcO-0000RA-EN for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 15:28:40 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i66JSdIN025442 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Tue, 6 Jul 2004 12:28:39 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by bandage.seagull.net (8.12.10) with ESMTP id i66JSbfk025364 sender ccjason@us.ibm.com; Tue, 6 Jul 2004 12:28:38 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i66JSQws604960; Tue, 6 Jul 2004 15:28:26 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i66JTH4A120906; Tue, 6 Jul 2004 15:29:18 -0400 To: Julian Reschke Cc: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Tue, 6 Jul 2004 15:28:20 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/06/2004 15:28:24, Serialize complete at 07/06/2004 15:28:24 Content-Type: multipart/alternative; boundary="=_alternative 006A115785256EC9_=" Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/OF9599C94D.FFCF6C3E-ON85256EC9.0069744B-85256EC9.006AF8E9@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8680 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: Resent-Message-Id: <20040706192842.82207A239B@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 15:28:42 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 006A115785256EC9_= Content-Type: text/plain; charset="us-ascii" On Tuesday, 07/06/2004 at 08:10 ZE2, Julian Reschke wrote: > 2.5 Status of a lock > > Having a URI (the lock token URI) on it's own, a lock is a resource > in the sense defined by [RFC2396]. In general, this resource does > not have a HTTP URL, and thus can not be directly manipulated using > HTTP methods. Instead, this specification defines the new methods > LOCK (creating and refreshing locks, see Section 4) and UNLOCK > (removing locks, see Section 5) that act indirectly on locks. I don't like us calling a lock a resource. The other paragraphs you included seem reasonable. --=_alternative 006A115785256EC9_= Content-Type: text/html; charset="us-ascii"
On Tuesday, 07/06/2004 at 08:10 ZE2, Julian Reschke wrote:

> 2.5 Status of a lock
>
> Having a URI (the lock token URI) on it's own, a lock is a resource
> in the sense defined by [RFC2396]. In general, this resource does
> not have a HTTP URL, and thus can not be directly manipulated using
> HTTP methods. Instead, this specification defines the new methods
> LOCK (creating and refreshing locks, see Section 4) and UNLOCK
> (removing locks, see Section 5) that act indirectly on locks.

I don't like us calling a lock a resource.

The other paragraphs you included seem reasonable.

--=_alternative 006A115785256EC9_=-- From w3c-dist-auth-request@w3.org Tue Jul 6 15:38:10 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16590 for ; Tue, 6 Jul 2004 15:38:10 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B99E3A2376; Tue, 6 Jul 2004 15:38:11 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0F336A238E for ; Tue, 6 Jul 2004 15:38:10 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhvlZ-0002Ua-Nl for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 15:38:09 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i66Jc8Gv030480 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Tue, 6 Jul 2004 12:38:08 -0700 Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i66Jc7s1030375 sender julian.reschke@gmx.de for ; Tue, 6 Jul 2004 12:38:07 -0700 Received: (qmail 9149 invoked by uid 65534); 6 Jul 2004 19:37:56 -0000 Received: from pD9FF098B.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.9.139) by mail.gmx.net (mp011) with SMTP; 06 Jul 2004 21:37:56 +0200 Message-ID: <40EAFF8F.1090002@gmx.de> Date: Tue, 06 Jul 2004 21:37:51 +0200 From: Julian Reschke MIME-Version: 1.0 To: Jason Crawford Cc: WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/40EAFF8F.1090002@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8681 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: Resent-Message-Id: <20040706193811.B99E3A2376@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 15:38:11 -0400 (EDT) Jason Crawford wrote: > ... > I don't like us calling a lock a resource. > ... > The other paragraphs you included seem reasonable. I expected pushback on that wording; but I think it really makes things clearer. Anything that has a URI *is* a resource (as per RFC2396 definition). Saying that it is a resource with internal state makes talking about it a lot simpler. So can you explain *why* you don't like that terminology? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jul 6 16:20:07 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19455 for ; Tue, 6 Jul 2004 16:20:07 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id A8C50A0678; Tue, 6 Jul 2004 16:19:46 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0025BA0678 for ; Tue, 6 Jul 2004 16:19:41 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhwPl-0000lr-RZ for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 16:19:42 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i66KJehK026167 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Tue, 6 Jul 2004 13:19:40 -0700 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by bandage.seagull.net (8.12.10) with ESMTP id i66KJc8q026042 sender ccjason@us.ibm.com; Tue, 6 Jul 2004 13:19:39 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i66KJRCc477046; Tue, 6 Jul 2004 16:19:27 -0400 Received: from d01ml604.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i66KKafC116264; Tue, 6 Jul 2004 16:20:36 -0400 To: Julian Reschke Cc: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Tue, 6 Jul 2004 16:19:22 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/06/2004 16:19:26, Serialize complete at 07/06/2004 16:19:26 Content-Type: multipart/alternative; boundary="=_alternative 006F695985256EC9_=" Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/OF7A94C828.2C4107EC-ON85256EC9.006DC76E-85256EC9.006FA4EF@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8682 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: Resent-Message-Id: <20040706201946.A8C50A0678@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 16:19:46 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 006F695985256EC9_= Content-Type: text/plain; charset="us-ascii" On Tuesday, 07/06/2004 at 09:37 ZE2, Julian Reschke wrote: > Jason Crawford wrote: > > ... > > I don't like us calling a lock a resource. > > ... > > The other paragraphs you included seem reasonable. > > So can you explain *why* you don't like that terminology? I'll try... Because we tend to tend to think of words the way we've used them even if they technically have a more generic definition. A lock seems to not behave like what we typically refer to as a resource. There doesn't seem to be a lot of overlap in their most important features and methods. You mentioned that a lock has a URI. I think of the lock-token identifying the lock, but the fact that it uses URI-like syntax is only coincidental to me. If a lock is a resource, I'd expect to be able to substitute the word "resource" for "lock" and have it sound reasonable. I'm comfortable saying that a lock acts on a resource, but I'd not be comfortable saying a resource acts on a resource. Similarly... "depth-resource", "exclusive resource", or "write resource". I'd prefer to simply think of resources as something that locks act upon. For me it feels better not to define a lock at all beyond it's behavior rather than to say it's a resource. J. --=_alternative 006F695985256EC9_= Content-Type: text/html; charset="us-ascii"
On Tuesday, 07/06/2004 at 09:37 ZE2, Julian Reschke wrote:
> Jason Crawford wrote:
> > ...
> > I don't like us calling a lock a resource.
> > ...
> > The other paragraphs you included seem reasonable.
>
> So can you explain *why* you don't like that terminology?

I'll try...

Because we tend to tend to think of words the way we've used them even if they technically have a more generic definition. A lock seems to not behave like what we typically refer to as a resource. There doesn't seem to be a lot of overlap in their most important features and methods.

You mentioned that a lock has a URI. I think of the lock-token identifying the lock, but the fact that it uses URI-like syntax is only coincidental to me.

If a lock is a resource, I'd expect to be able to substitute the word "resource" for "lock" and have it sound reasonable. I'm comfortable saying that a lock acts on a resource, but I'd not be comfortable saying a resource acts on a resource. Similarly... "depth-resource", "exclusive resource", or "write resource". I'd prefer to simply think of resources as something that locks act upon.

For me it feels better not to define a lock at all beyond it's behavior rather than to say it's a resource.

J.
--=_alternative 006F695985256EC9_=-- From w3c-dist-auth-request@w3.org Tue Jul 6 16:22:24 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19553 for ; Tue, 6 Jul 2004 16:22:24 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 78B99A053A; Tue, 6 Jul 2004 16:22:25 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0BC7CA053A for ; Tue, 6 Jul 2004 16:22:23 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhwSM-0001Ax-UL for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 16:22:23 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i66KMMIS028122 sender elias@cse.ucsc.edu for w3c-dist-auth@w3.org; Tue, 6 Jul 2004 13:22:22 -0700 Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by bandage.seagull.net (8.12.10) with ESMTP id i66KMLLD027980 sender elias@cse.ucsc.edu for ; Tue, 6 Jul 2004 13:22:21 -0700 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i66KLQL07581; Tue, 6 Jul 2004 13:21:28 -0700 (PDT) Message-ID: <40EB09C6.3090604@cse.ucsc.edu> Date: Tue, 06 Jul 2004 13:21:26 -0700 From: Elias Sinderson MIME-Version: 1.0 To: Julian Reschke Cc: Jason Crawford , WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/40EB09C6.3090604@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8683 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: Resent-Message-Id: <20040706202225.78B99A053A@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 16:22:25 -0400 (EDT) > Jason Crawford: > >> ... I don't like us calling a lock a resource. > Julian Reshke: > I expected pushback on that wording; but I think it really makes > things clearer. Anything that has a URI *is* a resource (as per > RFC2396 definition). Saying that it is a resource with internal state > makes talking about it a lot simpler. So can you explain *why* you > don't like that terminology? Elias Sinderson: Initially I also had a negative reaction to calling a lock a resource, since I generally use that word to refer to something that one can GET, PUT, PROPPATCH, etc. However, after reviewing RFC2396 to refresh my conceptual understanding of URIs vs. URLs, I have less of a reservation on using the term as Julian has for locks. A significant turning point in my feeling on this was in reading the explicitly referenced definition of a resource in section 1.1 of RFC2396: Resource A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable" [...] In short, while my initial reaction was on par with Jasons', I'm okay with the wording - especially since it seems to make things clearer and a clearer specification will only lead to better implementations in the long run (even if the implementors have to reference RFC2396 themselves)... Cheers, Elias From w3c-dist-auth-request@w3.org Tue Jul 6 17:21:13 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23978 for ; Tue, 6 Jul 2004 17:21:13 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 1EA31A06E1; Tue, 6 Jul 2004 16:36:23 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 32455A08D4 for ; Tue, 6 Jul 2004 16:36:20 -0400 (EDT) Received: from betlik.darwin.nasa.gov ([198.123.160.11] helo=dream.darwin.nasa.gov) by dr-nick.w3.org with esmtp (Exim 4.32) id 1Bhwfr-0003pt-So for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 16:36:20 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i66KaGL07664 for ; Tue, 6 Jul 2004 13:36:16 -0700 (PDT) Message-ID: <40EB0D40.4060903@cse.ucsc.edu> Date: Tue, 06 Jul 2004 13:36:16 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: multipart/alternative; boundary="------------090607090200040904030708" Subject: Re: Call for consensus on UNLOCK Request-URI being lock root X-Archived-At: http://www.w3.org/mid/40EB0D40.4060903@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8684 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: Resent-Message-Id: <20040706203623.1EA31A06E1@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 16:36:23 -0400 (EDT) --------------090607090200040904030708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > [...] the issue being discussed is just whether or not the refresh of > the lock has to be applied to the URL of the root of the lock, or > whether it can be applied to the URL of an indirectly locked resource > and then be automatically redirected by the server to the URL of the > root of the lock. Ah, thanks, I had indeed misunderstood the specific issue (while frantically trying to catch up on my email). So, in that case, I think I would still prefer option 1, given the evidence of current implementation behaviour. I'll try to read more carefully in the future... ;-) Cheers, Elias --------------090607090200040904030708 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote:

[...] the issue being discussed is just whether or not the refresh of the lock has to be applied to the URL of the root of the lock, or whether it can be applied to the URL of an indirectly locked resource and then be automatically redirected by the server to the URL of the root of the lock.

Ah, thanks, I had indeed misunderstood the specific issue (while frantically trying to catch up on my email). So, in that case, I think I would still prefer option 1, given the evidence of current implementation behaviour. I'll try to read more carefully in the future... ;-)

Cheers,
Elias
--------------090607090200040904030708-- From w3c-dist-auth-request@w3.org Tue Jul 6 19:32:11 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03674 for ; Tue, 6 Jul 2004 19:32:11 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 1A8A9A0C3F; Tue, 6 Jul 2004 19:32:12 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 87FBDA0C3F for ; Tue, 6 Jul 2004 19:32:09 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BhzQ0-0004WK-Ug for w3c-dist-auth@w3.org; Tue, 06 Jul 2004 19:32:09 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i66NW7A8016584 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Tue, 6 Jul 2004 16:32:07 -0700 Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i66NW5mR016505 sender julian.reschke@gmx.de for ; Tue, 6 Jul 2004 16:32:06 -0700 Received: (qmail 27323 invoked by uid 65534); 6 Jul 2004 23:31:54 -0000 Received: from pD9535E6E.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.110) by mail.gmx.net (mp016) with SMTP; 07 Jul 2004 01:31:54 +0200 Message-ID: <40EB3664.90505@gmx.de> Date: Wed, 07 Jul 2004 01:31:48 +0200 From: Julian Reschke MIME-Version: 1.0 To: Jason Crawford Cc: WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/40EB3664.90505@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8685 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: Resent-Message-Id: <20040706233212.1A8A9A0C3F@frink.w3.org> Resent-Date: Tue, 6 Jul 2004 19:32:12 -0400 (EDT) Jason Crawford wrote: > I'll try... > > Because we tend to tend to think of words the way we've used them even > if they technically have a more generic definition. A lock seems to > not behave like what we typically refer to as a resource. There doesn't > seem to be a lot of overlap in their most important features and methods. Well, I'd say they do. - you can ask the server to create a new lock using LOCK, similar to how servers frequently create new resources upon POST, - a lock has a URI, - a lock has state, - the state is observable indirectly through HTTP methods and last but not least, - it's pefectly ok to implement locks as HTTP resources (for instance which would react to DELETE). > You mentioned that a lock has a URI. I think of the lock-token > identifying the lock, but the fact that it uses URI-like syntax is only > coincidental to me. That's fine. > If a lock is a resource, I'd expect to be able to substitute the word > "resource" for "lock" and have it sound reasonable. I'm comfortable > saying that a lock acts on a resource, but I'd not be comfortable saying > a resource acts on a resource. Similarly... "depth-resource", > "exclusive resource", or "write resource". I'd prefer to simply think > of resources as something that locks act upon. If you substitute "lock" by "lock resource" things sound much better. The concept is similar to the version history resource in DeltaV. It's not strictly needed for many things, but making it an HTTP resource gives you a lot of advantages (such as properties you can observe *directly* though PROPFIND instead of indirectly through a specific REPORT). > For me it feels better not to define a lock at all beyond it's behavior > rather than to say it's a resource. The desire to define the *state* of a resource (what it must consist of) in a single place IMHO is independant of whether we actually *state* that it *is* a resource. I just happen to think that things become much clearer by seeing it this way. So far I've heard a resounding "of course" internally in our office, yours and Elias' feedback. Let's see what others think... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jul 7 15:06:06 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08620 for ; Wed, 7 Jul 2004 15:06:06 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 1380BA140F; Wed, 7 Jul 2004 15:06:08 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C8508A140F for ; Wed, 7 Jul 2004 15:06:06 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BiHk6-0008W2-IT for w3c-dist-auth@w3.org; Wed, 07 Jul 2004 15:06:06 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i67J64FH014988 sender lisa@osafoundation.org for w3c-dist-auth@w3.org; Wed, 7 Jul 2004 12:06:04 -0700 Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by bandage.seagull.net (8.12.10) with ESMTP id i67J61Kc014942 sender lisa@osafoundation.org for ; Wed, 7 Jul 2004 12:06:01 -0700 Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i67J5rJL029942 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 7 Jul 2004 12:05:53 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: WebDAV From: Lisa Dusseault Date: Wed, 7 Jul 2004 12:05:46 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/A6F3A918-D048-11D8-B746-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8686 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: Resent-Message-Id: <20040707190608.1380BA140F@frink.w3.org> Resent-Date: Wed, 7 Jul 2004 15:06:08 -0400 (EDT) Of course a lock can be *modelled* as a resource. Of course, RFC2518(bis) can explicitly model a lock as a resource. Of course implementations can model a lock as a resource. Note however we could instead choose to model the lock token as a resource if we wanted. To argue at least as devil's advocate, we can also simply say that a lock token is in the format of a URI and stop there. The original RFC2518 text says that a lock token "is represented as" a URI, not that it is a URI, although it also says that the URI identifies a lock. RFC2396 is clear that URIs identify resources, but since then, the format defined for URIs in RFC2396 has been used for many other identifiers. It's natural for a well defined format to be used for things beyond what it was defined for. Even HTTP URLs are used for things which are not HTTP resources -- for example, when an XML namespace begins with the "http" scheme. When does a new URI indicate a new resource? Does the addition of query parameters to a HTTP URL mean that it's now addressing a different resource? Who cares? Is an XML namespace a resource? Each namespace has a URI. How would it help or hinder XML Namespace definition if we were to insist that an XML namespace were a resource? Must we insist that every URI identifies a resource? What implications would this have for other specifications and their models? Does the "DAV:" URI point to a DAV resource? Other examples: - CAP uses "CAP URLs" without defining calendars as "resources" (draft-ietf-calsch-cap-13.txt) - XMPP URIs and URLs (there are several kinds) don't worry about whether the things identified are strictly resources Another way to look at this; is there some problem solved by modelling a lock as a resource? I took a look at the proposed text and "resource" is only used to refer to a lock in the first paragraph, so I don't understand the argument that this makes the text clearer. That argument ought to involve a claim that the original text is unclear in some way that matters to interoperability. My concrete worry is that implementors will feel that there are implementation implications resulting from modelling a lock as a resource, and make implementation decisions that aren't necessary. That was the result of the wording that a MOVE is the "logical equivalent of" a COPY followed by a DELETE -- definitional or explanatory wording was seen as normative in that case by some implementors. Philosophical, definitional or modeling changes do have an effect on implementors behavior. What effect would you like that to be? Lisa On Jul 6, 2004, at 4:31 PM, Julian Reschke wrote: > > Jason Crawford wrote: >> I'll try... >> Because we tend to tend to think of words the way we've used them >> even if they technically have a more generic definition. A lock >> seems to not behave like what we typically refer to as a resource. >> There doesn't seem to be a lot of overlap in their most important >> features and methods. > > Well, I'd say they do. > > - you can ask the server to create a new lock using LOCK, similar to > how servers frequently create new resources upon POST, > - a lock has a URI, > - a lock has state, > - the state is observable indirectly through HTTP methods and last but > not least, > - it's pefectly ok to implement locks as HTTP resources (for instance > which would react to DELETE). > >> You mentioned that a lock has a URI. I think of the lock-token >> identifying the lock, but the fact that it uses URI-like syntax is >> only coincidental to me. > > That's fine. > >> If a lock is a resource, I'd expect to be able to substitute the word >> "resource" for "lock" and have it sound reasonable. I'm comfortable >> saying that a lock acts on a resource, but I'd not be comfortable >> saying a resource acts on a resource. Similarly... >> "depth-resource", "exclusive resource", or "write resource". I'd >> prefer to simply think of resources as something that locks act upon. > > If you substitute "lock" by "lock resource" things sound much better. > The concept is similar to the version history resource in DeltaV. It's > not strictly needed for many things, but making it an HTTP resource > gives you a lot of advantages (such as properties you can observe > *directly* though PROPFIND instead of indirectly through a specific > REPORT). > >> For me it feels better not to define a lock at all beyond it's >> behavior rather than to say it's a resource. > > The desire to define the *state* of a resource (what it must consist > of) in a single place IMHO is independant of whether we actually > *state* that it *is* a resource. I just happen to think that things > become much clearer by seeing it this way. > > So far I've heard a resounding "of course" internally in our office, > yours and Elias' feedback. Let's see what others think... > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Wed Jul 7 15:35:20 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12468 for ; Wed, 7 Jul 2004 15:35:20 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 69DCDA1BE7; Wed, 7 Jul 2004 15:35:22 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 578C4A1C6F for ; Wed, 7 Jul 2004 15:35:19 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BiIBm-0004vo-6Q for w3c-dist-auth@w3.org; Wed, 07 Jul 2004 15:34:42 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i67JYfq0002843 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Wed, 7 Jul 2004 12:34:41 -0700 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i67JYYQ6002583 sender julian.reschke@gmx.de for ; Wed, 7 Jul 2004 12:34:35 -0700 Received: (qmail 17567 invoked by uid 65534); 7 Jul 2004 19:34:21 -0000 Received: from pD9535E6E.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.110) by mail.gmx.net (mp015) with SMTP; 07 Jul 2004 21:34:21 +0200 Message-ID: <40EC503B.3030402@gmx.de> Date: Wed, 07 Jul 2004 21:34:19 +0200 From: Julian Reschke MIME-Version: 1.0 To: Lisa Dusseault Cc: WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/40EC503B.3030402@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8687 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: Resent-Message-Id: <20040707193522.69DCDA1BE7@frink.w3.org> Resent-Date: Wed, 7 Jul 2004 15:35:22 -0400 (EDT) Lisa Dusseault wrote: > Of course a lock can be *modelled* as a resource. Of course, > RFC2518(bis) can explicitly model a lock as a resource. Of course > implementations can model a lock as a resource. Note however we could > instead choose to model the lock token as a resource if we wanted. According to RFC2396, anything that has a URI is a resource. There's a one-to-one relationship between a lock token and the lock. However, the lock token *is* the URI, so saying it is a resource doesn't really make sense. > To argue at least as devil's advocate, we can also simply say that a > lock token is in the format of a URI and stop there. The original > RFC2518 text says that a lock token "is represented as" a URI, not that > it is a URI, although it also says that the URI identifies a lock. Anything that is identified by a URI is a resource. This by *by definition*. RFC2518 says: "A lock token is a type of state token, represented as a URI, which identifies a particular lock." So we have a URI and an object identified by a URI. It's unclear to me why saying that object is a resource would be saying something new... > RFC2396 is clear that URIs identify resources, but since then, the > format defined for URIs in RFC2396 has been used for many other > identifiers. It's natural for a well defined format to be used for Example, please? > things beyond what it was defined for. Even HTTP URLs are used for > things which are not HTTP resources -- for example, when an XML > namespace begins with the "http" scheme. When does a new URI indicate > a new resource? Does the addition of query parameters to a HTTP URL > mean that it's now addressing a different resource? Who cares? A URI always identifies a resource. Whether a "new" URI identifies a "new" resource depends on URI scheme, implementation and intent. > Is an XML namespace a resource? Each namespace has a URI. How would it > help or hinder XML Namespace definition if we were to insist that an XML > namespace were a resource? Must we insist that every URI identifies a > resource? What implications would this have for other specifications Yes, because that's what the relevant RFCs say. > and their models? Does the "DAV:" URI point to a DAV resource? Other > examples: Strictly speaking, "DAV:" isn't a URI (as defined by RFC2396). However, for instance, "DAV:displayname" is a resource. > - CAP uses "CAP URLs" without defining calendars as "resources" > (draft-ietf-calsch-cap-13.txt) > - XMPP URIs and URLs (there are several kinds) don't worry about > whether the things identified are strictly resources I don't follow. What do you mean by "not being strictly a resource"? What's the definition of that? Do you have another definition for URI/resource than the one appearing in RFC2396? > Another way to look at this; is there some problem solved by modelling a > lock as a resource? I took a look at the proposed text and "resource" > is only used to refer to a lock in the first paragraph, so I don't > understand the argument that this makes the text clearer. That argument > ought to involve a claim that the original text is unclear in some way > that matters to interoperability. I think it helps understanding that a lock is an object that indeed has identity, a defined lifetime and observable properties. > My concrete worry is that implementors will feel that there are > implementation implications resulting from modelling a lock as a > resource, and make implementation decisions that aren't necessary. That Under the definition of RFC2396, there's no way to implement a WebDAV lock but as a resource. You may want to re-read RFC2396 () or RFC2396bis () to understand why this is correct. > was the result of the wording that a MOVE is the "logical equivalent of" > a COPY followed by a DELETE -- definitional or explanatory wording was > seen as normative in that case by some implementors. Philosophical, > definitional or modeling changes do have an effect on implementors > behavior. What effect would you like that to be? The intent is to better explain what a lock indeed *is*. Could you elaborate in which way people could possibly misunderstand the new text? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jul 7 15:55:58 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14070 for ; Wed, 7 Jul 2004 15:55:58 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id F1CBAA1344; Wed, 7 Jul 2004 15:55:59 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 57E06A1344 for ; Wed, 7 Jul 2004 15:55:58 -0400 (EDT) Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BiIWM-0001Ix-49 for w3c-dist-auth@w3c.org; Wed, 07 Jul 2004 15:55:58 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i67JtqJL009514 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 7 Jul 2004 12:55:56 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Webdav WG From: Lisa Dusseault Date: Wed, 7 Jul 2004 12:55:45 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: Using absolute URIs in headers and properties in DAV X-Archived-At: http://www.w3.org/mid/A2BB5528-D04F-11D8-B746-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8688 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: Resent-Message-Id: <20040707195559.F1CBAA1344@frink.w3.org> Resent-Date: Wed, 7 Jul 2004 15:55:59 -0400 (EDT) Content-Transfer-Encoding: 7bit Originally in RFC2518, the Destination header, the If header and the element all contained only absolute URIs (no paths). Then, after the 2002 Interop, we opened that up so that RFC2518bis now says the Destination header could take "abs path" as well. However, it was then pointed out (Dec 9 2002 mail) that we should make the If header consistent with the Destination header, which might also imply making the format the same. Nobody followed up on that Dec 9 2002 mail as far as I can see, so I'd like to reraise the issue. 1. Status quo in 'bis' -- are we really sure we want to make the Destination header inconsistent with the other DAV elements that take URI values? 2. Back to RFC2518 status -- only one option (full URIs) consistent across all uses 3. Forge ahead and allow absolute paths in Destination, If header, and possibly also . Doesn't this have backward compatibility issues? I'd like to recheck our reasoning on this one, and whether there's really a need to allow absolute paths in the value of Destination header. It was an interoperability issue, but I don't have all the details on why clients might find it difficult to include the server/host part of the URI. Lisa From w3c-dist-auth-request@w3.org Wed Jul 7 18:07:14 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20853 for ; Wed, 7 Jul 2004 18:07:14 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 6C863A0588; Wed, 7 Jul 2004 18:07:01 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C676CA0588 for ; Wed, 7 Jul 2004 18:06:59 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BiKZ9-0005QH-Fv for w3c-dist-auth@w3.org; Wed, 07 Jul 2004 18:06:59 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i67M6v1U018968 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Wed, 7 Jul 2004 15:06:57 -0700 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by bandage.seagull.net (8.12.10) with ESMTP id i67M6txZ018737 sender ccjason@us.ibm.com; Wed, 7 Jul 2004 15:06:55 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i67M6hCc441652; Wed, 7 Jul 2004 18:06:43 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i67M7YWm118072; Wed, 7 Jul 2004 18:07:34 -0400 To: Julian Reschke Cc: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Wed, 7 Jul 2004 18:06:39 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/07/2004 18:06:41, Serialize complete at 07/07/2004 18:06:41 Content-Type: multipart/alternative; boundary="=_alternative 0074445C85256ECA_=" Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/OFFABE9A6E.5EC49E06-ON85256ECA.0014AEE5-85256ECA.007975C7@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8689 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: Resent-Message-Id: <20040707220701.6C863A0588@frink.w3.org> Resent-Date: Wed, 7 Jul 2004 18:07:01 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 0074445C85256ECA_= Content-Type: text/plain; charset="us-ascii" On Wednesday, 07/07/2004 at 01:31 ZE2, Julian Reschke wrote: > Jason Crawford wrote: > > I'll try... > > > > Because we tend to tend to think of words the way we've used them even > > if they technically have a more generic definition. A lock seems to > > not behave like what we typically refer to as a resource. There doesn't > > seem to be a lot of overlap in their most important features and methods. > > Well, I'd say they do. > > - you can ask the server to create a new lock using LOCK, similar to how > servers frequently create new resources upon POST, I don't understand how this is related. As far as creation, typically to create a resource you do PUT or MKCOL. And the resource appears at the URL you provide as an argument. This is not the case for locks. > - a lock has a URI, Are you referring to the lock-token? It doesn't work the same way that URI's for typical resources work. For typical resources, the URI is a URL. This is not true for locks/locktokens. > - a lock has state, As do properties but we rarely refer to them as resources because that would cause confusion. Instead we give them a different name, "properties" to avoid that confusion. Of course, specifications that do properties more clearly as resources should feel free to also refer to them as resources. BTW... I'm not saying a lock is a property. I'm just providing a similar example of where we chose not to highlight the fact that something is a resource. > - the state is observable indirectly through HTTP methods Again, not the same way as typical resources. Only as a side effect of asking (PROPFIND) for the state of some OTHER resource. That's weird. And that's the only method locks and typical resources have in common. > and last but not least, > - it's pefectly ok to implement locks as HTTP resources (for instance > which would react to DELETE). You can say that for just about anything in this world, but we don't. When we find reason to standardize what you just mentioned, we then begin to have a reason to call locks resources, but right now they act differently than what we typically think of as resources. So although they (and just about anything else in this universe) can be called resources, it is not really helpful to do so... and because of the context, it's actually confusing. > If you substitute "lock" by "lock resource" things sound much better. It's less awkward as you say, but still a little. It works better to just say "lock" since adding "resource" detracts. > The concept is similar to the version history resource in DeltaV. It's > not strictly needed for many things, but making it an HTTP resource > gives you a lot of advantages (such as properties you can observe > *directly* though PROPFIND instead of indirectly through a specific > REPORT). Well... we don't do that in this spec though so it's premature to add verbiage claiming that they are resources. Adding the verbiage without the supporting behavior just adds confusion. Because you might want to eventually make them directly addressable via typical HTTP methods, we shouldn't say they aren't resources either. Instead we should be silent. > > For me it feels better not to define a lock at all beyond it's behavior > > rather than to say it's a resource. > > The desire to define the *state* of a resource (what it must consist of) > in a single place IMHO is independant of whether we actually *state* > that it *is* a resource. I agree. > I just happen to think that things become much > clearer by seeing it this way. ;-) --=_alternative 0074445C85256ECA_= Content-Type: text/html; charset="us-ascii"
On Wednesday, 07/07/2004 at 01:31 ZE2, Julian Reschke wrote:
> Jason Crawford wrote:
> > I'll try...
> >
> > Because we tend to tend to think of words the way we've used them even
> > if they technically have a more generic definition. A lock seems to
> > not behave like what we typically refer to as a resource. There doesn't
> > seem to be a lot of overlap in their most important features and methods.
>
> Well, I'd say they do.
>
> - you can ask the server to create a new lock using LOCK, similar to how
> servers frequently create new resources upon POST,
I don't understand how this is related. As far as creation, typically to create a resource you do PUT or MKCOL. And the resource appears at the URL you provide as an argument. This is not the case for locks.

> - a lock has a URI,
Are you referring to the lock-token? It doesn't work the same way that URI's for typical resources work. For typical resources, the URI is a URL. This is not true for locks/locktokens.

> - a lock has state,
As do properties but we rarely refer to them as resources because that would cause confusion. Instead we give them a different name, "properties" to avoid that confusion. Of course, specifications that do properties more clearly as resources should feel free to also refer to them as resources.

BTW... I'm not saying a lock is a property. I'm just providing a similar example of where we chose not to highlight the fact that something is a resource.

> - the state is observable indirectly through HTTP methods
Again, not the same way as typical resources. Only as a side effect of asking (PROPFIND) for the state of some OTHER resource. That's weird.

And that's the only method locks and typical resources have in common.

> and last but not least,
> - it's pefectly ok to implement locks as HTTP resources (for instance
> which would react to DELETE).
You can say that for just about anything in this world, but we don't. When we find reason to standardize what you just mentioned, we then begin to have a reason to call locks resources, but right now they act differently than what we typically think of as resources. So although they (and just about anything else in this universe) can be called resources, it is not really helpful to do so... and because of the context, it's actually confusing.

> If you substitute "lock" by "lock resource" things sound much better.
It's less awkward as you say, but still a little. It works better to just say "lock"
since adding "resource" detracts.

> The concept is similar to the version history resource in DeltaV. It's
> not strictly needed for many things, but making it an HTTP resource
> gives you a lot of advantages (such as properties you can observe
> *directly* though PROPFIND instead of indirectly through a specific
> REPORT).
Well... we don't do that in this spec though so it's premature to
add verbiage claiming that they are resources. Adding the verbiage
without the supporting behavior just adds confusion.
Because you might want to eventually make them directly addressable
via typical HTTP methods, we shouldn't say they aren't resources either.
Instead we should be silent.

> > For me it feels better not to define a lock at all beyond it's behavior
> > rather than to say it's a resource.
>
> The desire to define the *state* of a resource (what it must consist of)
> in a single place IMHO is independant of whether we actually *state*
> that it *is* a resource.
I agree.

> I just happen to think that things become much
> clearer by seeing it this way.
;-)

--=_alternative 0074445C85256ECA_=-- From w3c-dist-auth-request@w3.org Wed Jul 7 18:48:55 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25469 for ; Wed, 7 Jul 2004 18:48:54 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C8E0DA0D19; Wed, 7 Jul 2004 18:48:57 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 2EE14A0D19 for ; Wed, 7 Jul 2004 18:48:56 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.106]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BiLDZ-00028s-9f for w3c-dist-auth@w3.org; Wed, 07 Jul 2004 18:48:45 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i67MmEdu708522 for ; Wed, 7 Jul 2004 18:48:14 -0400 Received: from d01mc261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i67MnNZb054752 for ; Wed, 7 Jul 2004 18:49:24 -0400 In-Reply-To: <40EAEB0F.8070409@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 8 Jul 2004 00:48:12 +0200 X-MIMETrack: Serialize by Router on D01MC261/01/M/IBM(Release 6.0.2CF2 HFB2|May 18, 2004) at 07/07/2004 18:48:13, Serialize complete at 07/07/2004 18:48:13 Content-Type: multipart/alternative; boundary="=_alternative 007D44FFC1256ECA_=" Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/OF9BEE2A02.2B49946B-ONC1256ECA.007C64F1-C1256ECA.007D4500@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8691 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: Resent-Message-Id: <20040707224857.C8E0DA0D19@frink.w3.org> Resent-Date: Wed, 7 Jul 2004 18:48:57 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 007D44FFC1256ECA_= Content-Type: text/plain; charset="US-ASCII" Jason: The analogy with properties is not very close, because in WedDAV, the URI identifies a "property type", not an "instance of a property", so there would be ambiguity about the term "property resource", since the correct interpretation is the former, i.e. the property URI identifies a property type, while folks are likely to confuse this with the state of a particular property. There is no such ambiguity for a lock. But I'm not wedded to the idea of calling a lock a resource, so maybe it would be simplest to just say: ---------------------------------------- 2.5 Status of a lock A lock is identified by a URI (the lock token URI) but in general, it not have a HTTP URL, and thus can not be directly manipulated using HTTP methods. Instead, this specification defines the new methods LOCK (creating and refreshing locks, see Section 4) and UNLOCK (removing locks, see Section 5) that act indirectly on locks. ----------------------------------------- Since I believe this is the only section that refers to the "resourceness" of a lock, we can avoid the contention while keeping all the good stuff in the later paragraphs. Cheers, Geoff p.s. But just for the record, a lock really is a resource (:-). Julian wrote on 07/06/2004 08:10:23 PM: > > I noticed that RFC2518 historically says little about what a lock > actually *is*, instead just describes it's behaviour (which of course > needs to be done is well). The result is that essential information if > spread across the document; instead of being in a single place. A good > example for this is if you look at the various places in RFC2518 that > say something about what a timeout is, what it means to refresh it, when > the server needs to respect it and so on... > > Here's what I wrote for > latest.html#rfc.section.2> > (which continues to progress nicely)...: > > -- > > 2.5 Status of a lock > > Having a URI (the lock token URI) on it's own, a lock is a resource > in the sense defined by [RFC2396]. In general, this resource does > not have a HTTP URL, and thus can not be directly manipulated using > HTTP methods. Instead, this specification defines the new methods > LOCK (creating and refreshing locks, see Section 4) and UNLOCK > (removing locks, see Section 5) that act indirectly on locks. > > A lock has state that can be indirectly observed by using the > DAV:lockdiscovery property defined in Section 3.2. At a minimum, the > state of a lock consists of the items defined in the sections below. > After lock creation, all parts of the state with the exception of the > timeout value are immutable. > > 2.5.1 Lock Access Type > > At present, this specification only defines one lock access type, the > "write" lock defined in Section xx. > > 2.5.2 Lock Scope > > A lock has either exclusive or shared scope (see Section 2.1). > > 2.5.3 Lock Root > > A lock is created as effect of a LOCK (creation) method request. The > lock root is the URL to which this request was adressed. > > 2.5.4 Lock Depth > > A "depth 0" lock only affects the resource to which the LOCK request > was adressed to (the lock root). This resource is said to be > "directly locked" by the lock. > > On the other hand, a "depth infinity" lock on a collection > additionally affects all members of that collection. These resources > are said to be "indirectly locked" by the lock. A "depth infinity" > lock on a non-collection resource behaves exactly the same way as a > "depth 0" lock. > > 2.5.5 Lock Owner > > Clients can submit information about the lock owner when creating a > lock. This information should be 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). > > Owner information is kept with the lock so that it can be returned in > the DAV:lockdiscovery property upon request. Note that this > information is entirely client-controlled, thus a server MUST store > the information faithfully just like if it appeared in a WebDAV dead > property (see [RFC2518], section 4). > > 2.5.6 Lock Timeout > > In general, a lock expires after a certain amount of time. This time > can be specified in the LOCK creation request (however servers are > not required to honor this request). > > If the timeout expires then the lock may be lost. Specifically, if > the server wishes to harvest the lock upon time-out, the server > SHOULD act as if an UNLOCK method was executed by the server on the > resource using the lock token of the timed-out lock, performed with > its override authority. Thus logs should be updated with the > disposition of the lock, notifications should be sent, etc., just as > they would be for an UNLOCK request. > > The timers used for timeout expiry can be reset by the client by > submitting a LOCK refresh request. > > Servers are advised to pay close attention to the values submitted by > clients, as they will be indicative of the type of activity the > client intends to perform. For example, an applet running in a > browser may need to lock a resource, but because of the instability > of the environment within which the applet is running, the applet may > be turned off without warning. As a result, the applet is likely to > ask for a relatively small timeout value so that if the applet dies, > the lock can be quickly harvested. However, a document management > system is likely to ask for an extremely long timeout because its > user may be planning on going off-line. > > A client MUST NOT assume that just because the time-out has expired > the lock has been lost. Clients MUST assume that locks may > arbitrarily disappear at any time, regardless of the value given in > the Timeout header. The Timeout header only indicates the behavior > of the server if "extraordinary" circumstances do not occur. For > example, an administrator may remove a lock at any time or the system > may crash in such a way that it loses the record of the lock's > existence. > > -- > > Feedback appreciated, > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 007D44FFC1256ECA_= Content-Type: text/html; charset="US-ASCII"
Jason: The analogy with properties is not very close, because in WedDAV,
the URI identifies a "property type", not an "instance of a property", so
there would be ambiguity about the term "property resource", since the correct
interpretation is the former, i.e. the property URI identifies a property
type, while folks are likely to confuse this with the state of a particular
property. There is no such ambiguity for a lock.

But I'm not wedded to the idea of calling a lock a resource, so maybe
it would be simplest to just say:

----------------------------------------

2.5 Status of a lock
A lock is identified by a URI (the lock token URI) but in general, it not have a HTTP URL, and thus can not be directly manipulated using HTTP methods. Instead, this specification defines the new methods LOCK (creating and refreshing locks, see Section 4) and UNLOCK (removing locks, see Section 5) that act indirectly on locks.

-----------------------------------------

Since I believe this is the only section that refers to the "resourceness"
of a lock, we can avoid the contention while keeping all the good stuff in
the later paragraphs.

Cheers,
Geoff
p.s. But just for the record, a lock really is a resource (:-).

Julian wrote on 07/06/2004 08:10:23 PM: >
> I noticed that RFC2518 historically says little about what a lock > actually *is*, instead just describes it's behaviour (which of course > needs to be done is well). The result is that essential information if > spread across the document; instead of being in a single place. A good > example for this is if you look at the various places in RFC2518 that > say something about what a timeout is, what it means to refresh it, when > the server needs to respect it and so on... > > Here's what I wrote for > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking- > latest.html#rfc.section.2> > (which continues to progress nicely)...: > > -- > > 2.5 Status of a lock > > Having a URI (the lock token URI) on it's own, a lock is a resource > in the sense defined by [RFC2396]. In general, this resource does > not have a HTTP URL, and thus can not be directly manipulated using > HTTP methods. Instead, this specification defines the new methods > LOCK (creating and refreshing locks, see Section 4) and UNLOCK > (removing locks, see Section 5) that act indirectly on locks. > > A lock has state that can be indirectly observed by using the > DAV:lockdiscovery property defined in Section 3.2. At a minimum, the > state of a lock consists of the items defined in the sections below. > After lock creation, all parts of the state with the exception of the > timeout value are immutable. > > 2.5.1 Lock Access Type > > At present, this specification only defines one lock access type, the > "write" lock defined in Section xx. > > 2.5.2 Lock Scope > > A lock has either exclusive or shared scope (see Section 2.1). > > 2.5.3 Lock Root > > A lock is created as effect of a LOCK (creation) method request. The > lock root is the URL to which this request was adressed. > > 2.5.4 Lock Depth > > A "depth 0" lock only affects the resource to which the LOCK request > was adressed to (the lock root). This resource is said to be > "directly locked" by the lock. > > On the other hand, a "depth infinity" lock on a collection > additionally affects all members of that collection. These resources > are said to be "indirectly locked" by the lock. A "depth infinity" > lock on a non-collection resource behaves exactly the same way as a > "depth 0" lock. > > 2.5.5 Lock Owner > > Clients can submit information about the lock owner when creating a > lock. This information should be 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). > > Owner information is kept with the lock so that it can be returned in > the DAV:lockdiscovery property upon request. Note that this > information is entirely client-controlled, thus a server MUST store > the information faithfully just like if it appeared in a WebDAV dead > property (see [RFC2518], section 4). > > 2.5.6 Lock Timeout > > In general, a lock expires after a certain amount of time. This time > can be specified in the LOCK creation request (however servers are > not required to honor this request). > > If the timeout expires then the lock may be lost. Specifically, if > the server wishes to harvest the lock upon time-out, the server > SHOULD act as if an UNLOCK method was executed by the server on the > resource using the lock token of the timed-out lock, performed with > its override authority. Thus logs should be updated with the > disposition of the lock, notifications should be sent, etc., just as > they would be for an UNLOCK request. > > The timers used for timeout expiry can be reset by the client by > submitting a LOCK refresh request. > > Servers are advised to pay close attention to the values submitted by > clients, as they will be indicative of the type of activity the > client intends to perform. For example, an applet running in a > browser may need to lock a resource, but because of the instability > of the environment within which the applet is running, the applet may > be turned off without warning. As a result, the applet is likely to > ask for a relatively small timeout value so that if the applet dies, > the lock can be quickly harvested. However, a document management > system is likely to ask for an extremely long timeout because its > user may be planning on going off-line. > > A client MUST NOT assume that just because the time-out has expired > the lock has been lost. Clients MUST assume that locks may > arbitrarily disappear at any time, regardless of the value given in > the Timeout header. The Timeout header only indicates the behavior > of the server if "extraordinary" circumstances do not occur. For > example, an administrator may remove a lock at any time or the system > may crash in such a way that it loses the record of the lock's > existence. > > -- > > Feedback appreciated, > > Julian > > > -- > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 007D44FFC1256ECA_=-- From w3c-dist-auth-request@w3.org Wed Jul 7 18:52:30 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25835 for ; Wed, 7 Jul 2004 18:52:30 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 693D8A1A74; Wed, 7 Jul 2004 18:52:32 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3779AA0702 for ; Wed, 7 Jul 2004 18:52:31 -0400 (EDT) Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BiLHD-0002kg-0i for w3c-dist-auth@w3c.org; Wed, 07 Jul 2004 18:52:31 -0400 Old-X-Envelope-From: lisa@xythos.com Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i67Mp9JL021163 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 7 Jul 2004 15:51:11 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1FFD37E0-D068-11D8-B746-000A95B2BB72@xythos.com> Content-Transfer-Encoding: 7bit Cc: Jim Luther From: Lisa Dusseault Date: Wed, 7 Jul 2004 15:51:03 -0700 To: Webdav WG X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: WebDAV header typing X-Archived-At: http://www.w3.org/mid/1FFD37E0-D068-11D8-B746-000A95B2BB72@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8692 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: Resent-Message-Id: <20040707225232.693D8A1A74@frink.w3.org> Resent-Date: Wed, 7 Jul 2004 18:52:32 -0400 (EDT) Content-Transfer-Encoding: 7bit HTTP classifies headers as entity headers, general headers, request headers or response headers. Jim Luther suggested a while back that we should have classified the DAV headers accordingly. Here are the definitional sections from RFC2616: Entity-header fields define metainformation about the entity-body or, if no body is present, about the resource identified by the request. General-header: There are a few header fields which have general applicability for both request and response messages, but which do not apply to the entity being transferred. These header fields apply only to the message being transmitted. Example: Upgrade, indicating additional protocols supported by the client. The response-header fields allow the server to pass additional information about the response which cannot be placed in the Status- Line. These header fields give information about the server and about further access to the resource identified by the Request-URI. The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language method invocation. Beyond this, there's some unofficial explanation here (http://www.tcpipguide.com/free/t_HTTPGeneralHeaders.htm). Thus: - DAV must be a general-header, just like Upgrade, unless it's a response header because it only appears on responses. - Depth, Destination, Force-Authentication, If, Overwrite and Timeout are all simply request headers, like If-Match and Range. - Lock-Token is an entity-header like Content-Language and Expires -- on either the request or the response, it provides additional information about the resource addressed in the request. But what does this buy us? Besides limiting how they're used (e.g. prevent the server from using the Depth header on a response), I can't see how the definition helps implementors. Jim perhaps you could explain what I'm missing? Lisa From w3c-dist-auth-request@w3.org Wed Jul 7 19:14:25 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26880 for ; Wed, 7 Jul 2004 19:14:25 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 59144A0588; Wed, 7 Jul 2004 19:14:28 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 205C2A0588 for ; Wed, 7 Jul 2004 19:14:27 -0400 (EDT) Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BiLcR-00055L-0X for w3c-dist-auth@w3c.org; Wed, 07 Jul 2004 19:14:27 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i67NEOJL022723 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 7 Jul 2004 16:14:24 -0700 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <3FF156B5.7080809@gmx.de> References: <3FF156B5.7080809@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F5E4972-D06B-11D8-B746-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Wed, 7 Jul 2004 16:14:18 -0700 To: "'Webdav WG'" X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: When If headers with tagged lists fail X-Archived-At: http://www.w3.org/mid/5F5E4972-D06B-11D8-B746-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8693 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: Resent-Message-Id: <20040707231428.59144A0588@frink.w3.org> Resent-Date: Wed, 7 Jul 2004 19:14:28 -0400 (EDT) Content-Transfer-Encoding: 7bit I thought that RFC2518 was clear that if the If header includes a tagged list with the wrong URL then the request should be failed with 412. I went looking for the explanation in the section on tagged lists, and it wasn't terribly clear. It just tacitly "inherits" the definition from the untagged If header behavior. So, what if I added a sentence to the description of tagged list production in the If header, as follows: Text already there: The tagged-list production scopes a list production. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any. All clauses must be evaluated. Text to add immediately after: If the state of the resource named in the tag does not match any of the associated state lists then the request MUST fail with a 412 (Precondition Failed). Does this clear up the confusion? Is it OK/clear to have this information in a different section of the spec from where it says "a lock token is submitted if it appears anywhere in the If header"? Lisa On Dec 30, 2003, at 2:43 AM, Julian Reschke wrote: > > Geoffrey M Clemm wrote: > >> There are a couple of ways to go here: >> (1) consider a lock token to be submitted if it is submitted with a >> URL that is directly or indirectly locked by that lock token >> (2) consider a lock token to be submitted if it appears anywhere in >> the If header, even if it only appears on a URL that is not in >> fact locked by that lock. >> >> Lisa's initial statement sounded like she was advocating the >> second approach, but her last statement sounds more like the >> first approach. On the other hand, the last comment ("Otherwise >> you'd get a 412 Precondition Failed") is incorrect, since only >> one of the state lists need to match. >> >> Either way is OK with me (although I'd probably have gone with >> the first approach myself), but I just wanted to verify what >> folks had in mind here. > > I think the current spec > ( -05.txt>) > assumes (2): > > Quoting section 7.6: > > In order to prevent these collisions a lock token MUST be submitted > by an authorized principal for all locked resources that a method > may change or the method MUST fail. A lock token is submitted when > it appears in an If header. For example, if a resource is to be > moved and both the source and destination are locked then two lock > tokens must be submitted in the if header, one for the source and > the other for the destination. > > I can live with that, but I'm not sure why this is better than > requiring > the token to appear with the right URL (when in a tagged list). Is this > just a statement about current client behaviour, or a change compared > to > RFC2518? > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Jul 7 19:40:51 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28073 for ; Wed, 7 Jul 2004 19:40:51 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B659CA16E1; Wed, 7 Jul 2004 18:30:17 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BF250A1765 for ; Wed, 7 Jul 2004 18:30:14 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.105]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BiKve-00089J-Ic for w3c-dist-auth@w3.org; Wed, 07 Jul 2004 18:30:14 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i67MThDk764674 for ; Wed, 7 Jul 2004 18:29:43 -0400 Received: from d01mc261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i67MUrZb028590 for ; Wed, 7 Jul 2004 18:30:53 -0400 In-Reply-To: <40EB09C6.3090604@cse.ucsc.edu> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 8 Jul 2004 00:29:41 +0200 X-MIMETrack: Serialize by Router on D01MC261/01/M/IBM(Release 6.0.2CF2 HFB2|May 18, 2004) at 07/07/2004 18:29:42, Serialize complete at 07/07/2004 18:29:42 Content-Type: multipart/alternative; boundary="=_alternative 007B931BC1256ECA_=" Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/OF20B8041A.99B5331E-ONC1256ECA.007AAEC8-C1256ECA.007B931C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8690 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: Resent-Message-Id: <20040707223017.B659CA16E1@frink.w3.org> Resent-Date: Wed, 7 Jul 2004 18:30:17 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 007B931BC1256ECA_= Content-Type: text/plain; charset="US-ASCII" I agree with Elias (and Julian). In particular, I agree that Julian's usage of the term resource exactly follows the definition and recommended usage in RFC 2396. In general, I strongly support the proposed text for the locking overview as it is currently written (it is a very significant improvement over what appears in 2518 or 2518bis). Cheers, Geoff Elias wrote on 07/06/2004 10:21:26 PM: > > Jason Crawford: > > > >> ... I don't like us calling a lock a resource. > Julian Reshke: > > I expected pushback on that wording; but I think it really makes > > things clearer. Anything that has a URI *is* a resource (as per > > RFC2396 definition). Saying that it is a resource with internal state > > makes talking about it a lot simpler. So can you explain *why* you > > don't like that terminology? > Elias Sinderson: > Initially I also had a negative reaction to calling a lock a resource, > since I generally use that word to refer to something that one can GET, > PUT, PROPPATCH, etc. However, after reviewing RFC2396 to refresh my > conceptual understanding of URIs vs. URLs, I have less of a reservation > on using the term as Julian has for locks. A significant turning point > in my feeling on this was in reading the explicitly referenced > definition of a resource in section 1.1 of RFC2396: > > Resource > A resource can be anything that has identity. Familiar > examples include an electronic document, an image, a service > (e.g., "today's weather report for Los Angeles"), and a > collection of other resources. Not all resources are network > "retrievable" [...] > > In short, while my initial reaction was on par with Jasons', I'm okay > with the wording - especially since it seems to make things clearer and > a clearer specification will only lead to better implementations in the > long run (even if the implementors have to reference RFC2396 themselves)... --=_alternative 007B931BC1256ECA_= Content-Type: text/html; charset="US-ASCII"
I agree with Elias (and Julian). In particular, I agree
that Julian's usage of the term resource exactly follows the
definition and recommended usage in RFC 2396.

In general, I strongly support the proposed text for the locking
overview as it is currently written (it is a very significant
improvement over what appears in 2518 or 2518bis).
Cheers,
Geoff

Elias wrote on 07/06/2004 10:21:26 PM: > > Jason Crawford: > > > >> ... I don't like us calling a lock a resource. > Julian Reshke: > > I expected pushback on that wording; but I think it really makes > > things clearer. Anything that has a URI *is* a resource (as per > > RFC2396 definition). Saying that it is a resource with internal state > > makes talking about it a lot simpler. So can you explain *why* you > > don't like that terminology? > Elias Sinderson: > Initially I also had a negative reaction to calling a lock a resource, > since I generally use that word to refer to something that one can GET, > PUT, PROPPATCH, etc. However, after reviewing RFC2396 to refresh my > conceptual understanding of URIs vs. URLs, I have less of a reservation > on using the term as Julian has for locks. A significant turning point > in my feeling on this was in reading the explicitly referenced > definition of a resource in section 1.1 of RFC2396: > > Resource > A resource can be anything that has identity. Familiar > examples include an electronic document, an image, a service > (e.g., "today's weather report for Los Angeles"), and a > collection of other resources. Not all resources are network > "retrievable" [...] > > In short, while my initial reaction was on par with Jasons', I'm okay > with the wording - especially since it seems to make things clearer and > a clearer specification will only lead to better implementations in the > long run (even if the implementors have to reference RFC2396 themselves)... --=_alternative 007B931BC1256ECA_=-- From w3c-dist-auth-request@w3.org Thu Jul 8 02:04:04 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19930 for ; Thu, 8 Jul 2004 02:04:03 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id EE873A157E; Thu, 8 Jul 2004 02:04:03 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 1C476A159A for ; Thu, 8 Jul 2004 02:03:59 -0400 (EDT) Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by dr-nick.w3.org with smtp (Exim 4.32) id 1BiS0k-000511-To for w3c-dist-auth@w3c.org; Thu, 08 Jul 2004 02:03:59 -0400 Received: (qmail 25211 invoked by uid 65534); 8 Jul 2004 06:03:25 -0000 Received: from pD9E51CFC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.252) by mail.gmx.net (mp019) with SMTP; 08 Jul 2004 08:03:25 +0200 X-Authenticated: #1915285 Message-ID: <40ECE3A6.2070504@gmx.de> Date: Thu, 08 Jul 2004 08:03:18 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: "'Webdav WG'" References: <3FF156B5.7080809@gmx.de> <5F5E4972-D06B-11D8-B746-000A95B2BB72@osafoundation.org> In-Reply-To: <5F5E4972-D06B-11D8-B746-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: When If headers with tagged lists fail X-Archived-At: http://www.w3.org/mid/40ECE3A6.2070504@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8694 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: Resent-Message-Id: <20040708060403.EE873A157E@frink.w3.org> Resent-Date: Thu, 8 Jul 2004 02:04:03 -0400 (EDT) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > I thought that RFC2518 was clear that if the If header includes a > tagged list with the wrong URL then the request should be failed with > 412. I went looking for the explanation in the section on tagged > lists, and it wasn't terribly clear. It just tacitly "inherits" the > definition from the untagged If header behavior. > > So, what if I added a sentence to the description of tagged list > production in the If header, as follows: > > Text already there: > The tagged-list production scopes a list production. That is, it > specifies that the lists following the resource specification only > apply to the specified resource. The scope of the resource > production begins with the list production immediately following the > resource production and ends with the next resource production, if > any. All clauses must be evaluated. > > Text to add immediately after: > If the state of the resource named in the tag does not > match any of the associated state lists then the request MUST fail > with a 412 (Precondition Failed). "If the state of the resource identified by the URI specified in the tag does not match any of the associated state lists then the request MUST fail with a 412 (Precondition Failed)." Plus: define a precondition code. > Does this clear up the confusion? Is it OK/clear to have this > information in a different section of the spec from where it says "a > lock token is submitted if it appears anywhere in the If header"? I agree that something like this is what RFC2518 should have said in the first place. However, today we should take into account what exactly is implemented in the popular servers before making a change (so we need to run tests first). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jul 8 02:13:23 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28936 for ; Thu, 8 Jul 2004 02:13:22 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 99021A1811; Thu, 8 Jul 2004 02:13:22 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6ABC0A1811 for ; Thu, 8 Jul 2004 02:13:19 -0400 (EDT) Received: from mail.gmx.net ([213.165.64.20]) by dr-nick.w3.org with smtp (Exim 4.32) id 1BiS9n-00078h-8u for w3c-dist-auth@w3c.org; Thu, 08 Jul 2004 02:13:19 -0400 Received: (qmail 6092 invoked by uid 65534); 8 Jul 2004 06:12:48 -0000 Received: from pD9E51CFC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.252) by mail.gmx.net (mp027) with SMTP; 08 Jul 2004 08:12:48 +0200 X-Authenticated: #1915285 Message-ID: <40ECE5DA.3020505@gmx.de> Date: Thu, 08 Jul 2004 08:12:42 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: Webdav WG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Using absolute URIs in headers and properties in DAV X-Archived-At: http://www.w3.org/mid/40ECE5DA.3020505@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8695 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: Resent-Message-Id: <20040708061322.99021A1811@frink.w3.org> Resent-Date: Thu, 8 Jul 2004 02:13:22 -0400 (EDT) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Originally in RFC2518, the Destination header, the If header and the > element all contained only absolute URIs (no paths). Then, after > the 2002 Interop, we opened that up so that RFC2518bis now says the > Destination header could take "abs path" as well. However, it was then > pointed out (Dec 9 2002 mail) that we should make the If header > consistent with the Destination header, which might also imply making > the format the same. Nobody followed up on that Dec 9 2002 mail > as far as I can see, so I'd like to reraise the issue. > > 1. Status quo in 'bis' -- are we really sure we want to make the > Destination header inconsistent with the other DAV elements that take > URI values? > 2. Back to RFC2518 status -- only one option (full URIs) consistent > across all uses > 3. Forge ahead and allow absolute paths in Destination, If header, and > possibly also . Doesn't this have backward compatibility issues? > > I'd like to recheck our reasoning on this one, and whether there's > really a need to allow absolute paths in the value of Destination > header. It was an interoperability issue, but I don't have all the > details on why clients might find it difficult to include the > server/host part of the URI. Note that we already allow non-absolute URIs in href elements (right now defined as per 3.2.1 of RFC2068), so the inconsistency is just with places where we currently require "Coded-URL". Anyway, the spec should only be changed if that change doesn't break existing servers. So if one of Apache/moddav, MS IIS (and possibly others) do not allow non-absolute URIs , we shouldn't make any change. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jul 8 02:42:50 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01954 for ; Thu, 8 Jul 2004 02:42:50 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 92EEEA18E1; Thu, 8 Jul 2004 02:42:46 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 49D24A1E0E for ; Thu, 8 Jul 2004 02:41:02 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BiSP5-0001Lo-5N for w3c-dist-auth@w3.org; Thu, 08 Jul 2004 02:29:07 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i686T57x007540 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Wed, 7 Jul 2004 23:29:05 -0700 Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i686SwK2007382 sender julian.reschke@gmx.de for ; Wed, 7 Jul 2004 23:28:59 -0700 Received: (qmail 26739 invoked by uid 65534); 8 Jul 2004 06:28:45 -0000 Received: from pD9E51CFC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.252) by mail.gmx.net (mp005) with SMTP; 08 Jul 2004 08:28:45 +0200 Message-ID: <40ECE999.8000309@gmx.de> Date: Thu, 08 Jul 2004 08:28:41 +0200 From: Julian Reschke MIME-Version: 1.0 To: Jason Crawford Cc: Julian Reschke , WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/40ECE999.8000309@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8696 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: Resent-Message-Id: <20040708064246.92EEEA18E1@frink.w3.org> Resent-Date: Thu, 8 Jul 2004 02:42:46 -0400 (EDT) Jason Crawford wrote: > > Well, I'd say they do. > > > > - you can ask the server to create a new lock using LOCK, similar to how > > servers frequently create new resources upon POST, > I don't understand how this is related. As far as creation, typically > to create a resource you do PUT or MKCOL. And the resource appears at > the URL you provide as an argument. This is not the case for locks. That's only "typical" for WebDAV. Outside WebDAV, new resources are created as an effect of POST every second (and in this case, it's the server that assigns the URL). I'd actually call that the typical case, for the simply reason that it happens so often. > > - a lock has a URI, > Are you referring to the lock-token? It doesn't work the same way that > URI's for typical resources work. For typical resources, the URI is a > URL. This is not true for locks/locktokens. What is a "typical" resource? And why is this relevant unless I say that a lock indeed is a "typical" resource? > > - a lock has state, > As do properties but we rarely refer to them as resources because that > would cause confusion. Instead we give them a different name, > "properties" to avoid that confusion. Of course, specifications that > do properties more clearly as resources should feel free to also refer > to them as resources. As a matter of fact particular instances of WebDAV properties on a resource *are* resources on their own. We just don't have a common notation for their URLs. For instance we could have defined that the DAV:displayname property for a given WebDAV URL http://a/b has the following URL: http://a/b;displayname and then we could have allowed DELETE/PUT/GET on it. Many say that this is what WebDAV should have done, because it would have avoided the current situation where property values can not be addressed by the common WebDAV methods. > BTW... I'm not saying a lock is a property. I'm just providing a > similar example of where we chose not to highlight the fact that > something is a resource. > > > - the state is observable indirectly through HTTP methods > Again, not the same way as typical resources. Only as a side effect of > asking (PROPFIND) for the state of some OTHER resource. That's weird. OK. Does "urn:ietf:rfc:2518" identify a resource? Does "mailto:w3c-dist-auth@w3c.org"? None of them can be addressed using HTTP directly. They are still resources, just not HTTP resources. > And that's the only method locks and typical resources have in common. Again, unless you define what you understand with "typical" and how this is relevant here.... > > and last but not least, > > - it's pefectly ok to implement locks as HTTP resources (for instance > > which would react to DELETE). > You can say that for just about anything in this world, but we don't. > When we find reason to standardize what you just mentioned, we then > begin to have a reason to call locks resources, but right now they act > differently than what we typically think of as resources. So although > they (and just about anything else in this universe) can be called > resources, it is not really helpful to do so... and because of the > context, it's actually confusing. I'd like to understand *why* you find that confusing? Because you usually only use the term "resource" when talking about HTTP resources? > > If you substitute "lock" by "lock resource" things sound much better. > It's less awkward as you say, but still a little. It works better to > just say "lock" > since adding "resource" detracts. Well, that's what the spec *does*. The term "resource" is only used in the introduction. > > The concept is similar to the version history resource in DeltaV. It's > > not strictly needed for many things, but making it an HTTP resource > > gives you a lot of advantages (such as properties you can observe > > *directly* though PROPFIND instead of indirectly through a specific > > REPORT). > Well... we don't do that in this spec though so it's premature to > add verbiage claiming that they are resources. Adding the verbiage > without the supporting behavior just adds confusion. They technically *are* resources. If you're arguing with that statement, you should explain how this is incorrect according to RFC2396 (which is the relevant spec here). Whether we should *say* that they are resources is a different question. We don't need to say it, but my feeling was that it helps understanding how they work. > .. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jul 8 11:08:03 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29108 for ; Thu, 8 Jul 2004 11:08:03 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 03C41A0FD9; Thu, 8 Jul 2004 11:08:05 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by frink.w3.org (Postfix) with ESMTP id 4EEB2A1093 for ; Thu, 8 Jul 2004 11:08:03 -0400 (EDT) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i68F829L021706 for ; Thu, 8 Jul 2004 08:08:02 -0700 (PDT) Received: from [168.16.213.98] (sleepy.gcsu.edu [168.16.213.98]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i68F81kJ029564 for ; Thu, 8 Jul 2004 08:08:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: frank.lowney@mail.mac.com Message-Id: In-Reply-To: References: Date: Thu, 8 Jul 2004 11:07:59 -0400 To: w3c-dist-auth@frink.w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" Subject: Re: WindowsXP and double login challenges X-Archived-At: http://www.w3.org/mid/p06110406bd1310a1a1b7@%5B168.16.213.98%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8697 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: Resent-Message-Id: <20040708150805.03C41A0FD9@frink.w3.org> Resent-Date: Thu, 8 Jul 2004 11:08:05 -0400 (EDT) It's great to see that the WebDAV protocol is relentlessly advancing but, as someone who is trying to get end users to embrace it over older, more established methods, I have to wonder whether the basic aspects of the protocol work well enough to assure a level of acceptance sufficient to sustain the momentum. Take, for example, the query I posted here a week or so ago (quoted below). While it's difficult to definitively interpret a non-response, they tend to be interpreted as: yes, that's a problem but there is no solution or workaround. So, if that is the case with Win2K / WinXP Network Places access to a wide range of WebDAV-enabled servers where end users first and continuing experience with WebDAV is a double login challenge, we should not be surprised to learn that these end users are reluctant to consider change. >We are currently working with three WebDAV-enabled servers as follows: > >WebSTAR V v.5.3.2 on MacOS X 10.3.4 > >Apache on MacOS X Server 10.3.4 > >BEA Weblogic (supporting WebCT Vista) on Solaris. > >Using WindowsXP & 'My Network Places,' we and our various clients and other constituencies are consistently seeing a "double login challenge" in all three cases. We don't see this issue on Win2K Pro or MacOS X. > >First, can anyone confirm that this is a "Microsoft not following standards again" issue? > >Second, can anyone suggest a work around that will unburden WinXP WebDAV users from the necessity of meeting this challenge twice? > >Thanks for any light shed on this issue. -- ===================================================================== Dr. Frank Lowney frank.lowney@gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 NOTICE: Please be advised that I am hearing impaired and communicate most effectively via e-mail. Follow-up summaries of telephone conversations by e-mail are most appreciated. ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Thu Jul 8 12:01:05 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05067 for ; Thu, 8 Jul 2004 12:01:04 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 2A9F4A0DE9; Thu, 8 Jul 2004 12:01:05 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C901BA0DE9 for ; Thu, 8 Jul 2004 12:01:02 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BibKY-0000ZL-Ik for w3c-dist-auth@w3.org; Thu, 08 Jul 2004 12:01:02 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i68G11bX030899 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Thu, 8 Jul 2004 09:01:01 -0700 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by bandage.seagull.net (8.12.10) with ESMTP id i68G0Sof030564 sender ccjason@us.ibm.com; Thu, 8 Jul 2004 09:00:36 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i68G0Cdu468504; Thu, 8 Jul 2004 12:00:13 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i68G1LEC107128; Thu, 8 Jul 2004 12:01:22 -0400 To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Thu, 8 Jul 2004 12:00:06 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/08/2004 12:00:12, Serialize complete at 07/08/2004 12:00:12 Content-Type: multipart/alternative; boundary="=_alternative 0050322585256ECB_=" Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/OF335C7F92.D2E73FFE-ON85256ECB.004F8585-85256ECB.0057E684@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8698 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: Resent-Message-Id: <20040708160105.2A9F4A0DE9@frink.w3.org> Resent-Date: Thu, 8 Jul 2004 12:01:05 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 0050322585256ECB_= Content-Type: text/plain; charset="us-ascii" > But I'm not wedded to the idea of calling a lock a resource, so maybe > it would be simplest to just say: > > ---------------------------------------- > > 2.5 Status of a lock > A lock is identified by a URI (the lock token URI) but in general, it > not have a HTTP URL, and thus can not be directly manipulated using > HTTP methods. Instead, this specification defines the new methods > LOCK (creating and refreshing locks, see Section 4) and UNLOCK > (removing locks, see Section 5) that act indirectly on locks. > > ----------------------------------------- > > Since I believe this is the only section that refers to the "resourceness" > of a lock, we can avoid the contention while keeping all the good stuff in > the later paragraphs. I guess we'd have to see it in context, but if that's the only mention of resourceness, that should be a significant improvement. (Don't forget to include the word "is" between lines 0 and 1. :-)) J. --=_alternative 0050322585256ECB_= Content-Type: text/html; charset="us-ascii"
> But I'm not wedded to the idea of calling a lock a resource, so maybe
> it would be simplest to just say:
>
> ----------------------------------------
>
> 2.5 Status of a lock
> A lock is identified by a URI (the lock token URI) but in general, it
> not have a HTTP URL, and thus can not be directly manipulated using
> HTTP methods. Instead, this specification defines the new methods
> LOCK (creating and refreshing locks, see Section 4) and UNLOCK
> (removing locks, see Section 5) that act indirectly on locks.
>
> -----------------------------------------
>
> Since I believe this is the only section that refers to the "resourceness"
> of a lock, we can avoid the contention while keeping all the good stuff in
> the later paragraphs.

I guess we'd have to see it in context, but if that's the only mention of
resourceness, that should be a significant improvement. (Don't forget
to include the word "is" between lines 0 and 1. :-))

J.
--=_alternative 0050322585256ECB_=-- From w3c-dist-auth-request@w3.org Thu Jul 8 12:01:14 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05087 for ; Thu, 8 Jul 2004 12:01:13 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id E240BA0912; Thu, 8 Jul 2004 12:01:14 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 28076A0912 for ; Thu, 8 Jul 2004 12:01:14 -0400 (EDT) Received: from bandage.seagull.net ([67.136.24.2]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BibKj-0000ak-RF for w3c-dist-auth@w3.org; Thu, 08 Jul 2004 12:01:14 -0400 Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i68G15A7030972 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Thu, 8 Jul 2004 09:01:12 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by bandage.seagull.net (8.12.10) with ESMTP id i68G0TpT030618 sender ccjason@us.ibm.com; Thu, 8 Jul 2004 09:00:37 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i68G0Cws638678; Thu, 8 Jul 2004 12:00:12 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i68G1LEA097552; Thu, 8 Jul 2004 12:01:22 -0400 To: Julian Reschke Cc: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Thu, 8 Jul 2004 11:59:59 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/08/2004 12:00:12, Serialize complete at 07/08/2004 12:00:12 Content-Type: multipart/alternative; boundary="=_alternative 004EC42785256ECB_=" Subject: Re: new proposed text for locking overview X-Archived-At: http://www.w3.org/mid/OF1D36BAFC.30D66699-ON85256ECB.004909F6-85256ECB.0057E275@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8699 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: Resent-Message-Id: <20040708160114.E240BA0912@frink.w3.org> Resent-Date: Thu, 8 Jul 2004 12:01:14 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 004EC42785256ECB_= Content-Type: text/plain; charset="us-ascii" On Thursday, 07/08/2004 at 08:28 ZE2, Julian Reschke wrote: > Jason Crawford wrote: > > > > Well, I'd say they do. > > > > > > - you can ask the server to create a new lock using LOCK, similar to how > > > servers frequently create new resources upon POST, > > I don't understand how this is related. As far as creation, typically > > to create a resource you do PUT or MKCOL. And the resource appears at > > the URL you provide as an argument. This is not the case for locks. > > That's only "typical" for WebDAV. Outside WebDAV, new resources are > created as an effect of POST every second (and in this case, it's the > server that assigns the URL). I'd actually call that the typical case, > for the simply reason that it happens so often. We have different experience then. For me PUT is only second to FTP. And my web tools don't support authoring via POST. Besides.... We're working on or extending the WebDAV spec. It doesn't make sense to treat our own spec(s) as exceptional. We should be self consistant. When we speak of resources, it has meant HTTP resources. This is not just coincidental. The whole of 2518 is dedicated to defining these "resources". To briefly use the term to refer to something that doesn't behave like the spec outlines doesn't make sense. > > > - a lock has a URI, > > Are you referring to the lock-token? It doesn't work the same way that > > URI's for typical resources work. For typical resources, the URI is a > > URL. This is not true for locks/locktokens. > > What is a "typical" resource? And why is this relevant unless I say that > a lock indeed is a "typical" resource? An HTTP resource. > As a matter of fact particular instances of WebDAV properties on a > resource *are* resources on their own. We just don't have a common > notation for their URLs. For instance we could have defined that the > DAV:displayname property for a given WebDAV URL http://a/b has the > following URL: > > http://a/b;displayname > > and then we could have allowed DELETE/PUT/GET on it. Many say that this > is what WebDAV should have done, because it would have avoided the > current situation where property values can not be addressed by the > common WebDAV methods. Right. Properties are resources, but we don't call them resources. That was my point. > OK. Does "urn:ietf:rfc:2518" identify a resource? Does > "mailto:w3c-dist-auth@w3c.org"? None of them can be addressed using HTTP > directly. They are still resources, just not HTTP resources. That's right. In the context of a spec dedicate to HTTP resources it's not useful to call these or LOCKS resources. It actually is confusing because resources usually refers to HTTP resources. > Again, unless you define what you understand with "typical" and how this > is relevant here.... HTTP Resources. One's that support simple namespace operations like GET/PUT/DELETE or GET/MKCOL/DELETE... and our new operations in the binding spec. > > > and last but not least, > > > - it's pefectly ok to implement locks as HTTP resources (for instance > > > which would react to DELETE). > > You can say that for just about anything in this world, but we don't. > > When we find reason to standardize what you just mentioned, we then > > begin to have a reason to call locks resources, but right now they act > > differently than what we typically think of as resources. So although > > they (and just about anything else in this universe) can be called > > resources, it is not really helpful to do so... and because of the > > context, it's actually confusing. > > I'd like to understand *why* you find that confusing? Because you > usually only use the term "resource" when talking about HTTP resources? Because throughout the spec resources refer to HTTP resources. Now it is being suggested to use the term briefly for something that doesn't behave like an HTTP resource at all. It will draw the wrong picture because all the important operational behaviors that the spec defines for resources don't apply. > They technically *are* resources. If you're arguing with that statement, > you should explain how this is incorrect according to RFC2396 (which is > the relevant spec here). > Whether we should *say* that they are resources is a different question. > We don't need to say it, but my feeling was that it helps understanding > how they work. Right. The disagreement is not whether they are resources are not. The rfc you mention clearly allows them and just about anything else in the world to be a resource. The disagreement is over whether we should mention that they are resources. Down the road we might want to openly call them resources if we go ahead and have the lock-token be a URL that responds to GET/DELETE/PROPSTAT methods, but right now calling these things resources despite the fact that they don't have the behaviors that our spec spends so much time defining for resources would be confusing and not really helpful. --=_alternative 004EC42785256ECB_= Content-Type: text/html; charset="us-ascii"
On Thursday, 07/08/2004 at 08:28 ZE2, Julian Reschke wrote:
> Jason Crawford wrote:
>
> > > Well, I'd say they do.
> > >
> > > - you can ask the server to create a new lock using LOCK, similar to how
> > > servers frequently create new resources upon POST,
> > I don't understand how this is related. As far as creation, typically
> > to create a resource you do PUT or MKCOL. And the resource appears at
> > the URL you provide as an argument. This is not the case for locks.
>
> That's only "typical" for WebDAV. Outside WebDAV, new resources are
> created as an effect of POST every second (and in this case, it's the
> server that assigns the URL). I'd actually call that the typical case,
> for the simply reason that it happens so often.

We have different experience then. For me PUT is only second to FTP. And my web tools don't support authoring via POST.

Besides.... We're working on or extending the WebDAV spec. It doesn't make sense to treat our own spec(s) as exceptional. We should be self consistant. When we speak of resources, it has meant HTTP resources. This is not just coincidental. The whole of 2518 is dedicated
to defining these "resources". To briefly use the term to refer to something that doesn't behave like the spec outlines doesn't make sense.

> > > - a lock has a URI,
> > Are you referring to the lock-token? It doesn't work the same way that
> > URI's for typical resources work. For typical resources, the URI is a
> > URL. This is not true for locks/locktokens.
>
> What is a "typical" resource? And why is this relevant unless I say that
> a lock indeed is a "typical" resource?

An HTTP resource.

> As a matter of fact particular instances of WebDAV properties on a
> resource *are* resources on their own. We just don't have a common
> notation for their URLs. For instance we could have defined that the
> DAV:displayname property for a given WebDAV URL http://a/b has the
> following URL:
>
> http://a/b;displayname
>
> and then we could have allowed DELETE/PUT/GET on it. Many say that this
> is what WebDAV should have done, because it would have avoided the
> current situation where property values can not be addressed by the
> common WebDAV methods.

Right. Properties are resources, but we don't call them resources. That was my point.

> OK. Does "urn:ietf:rfc:2518" identify a resource? Does
> "mailto:w3c-dist-auth@w3c.org"? None of them can be addressed using HTTP
> directly. They are still resources, just not HTTP resources.

That's right. In the context of a spec dedicate to HTTP resources it's not useful to call these or LOCKS resources. It actually is confusing because resources usually refers to HTTP resources.

> Again, unless you define what you understand with "typical" and how this
> is relevant here....

HTTP Resources. One's that support simple namespace operations like GET/PUT/DELETE or GET/MKCOL/DELETE... and our new operations in the binding spec.

> > > and last but not least,
> > > - it's pefectly ok to implement locks as HTTP resources (for instance
> > > which would react to DELETE).
> > You can say that for just about anything in this world, but we don't.
> > When we find reason to standardize what you just mentioned, we then
> > begin to have a reason to call locks resources, but right now they act
> > differently than what we typically think of as resources. So although
> > they (and just about anything else in this universe) can be called
> > resources, it is not really helpful to do so... and because of the
> > context, it's actually confusing.
>
> I'd like to understand *why* you find that confusing? Because you
> usually only use the term "resource" when talking about HTTP resources?

Because throughout the spec resources refer to
HTTP resources. Now it is being suggested to use the term briefly
for something that doesn't behave like an HTTP resource at all. It
will draw the wrong picture because all the important operational
behaviors that the spec defines for resources don't apply.

> They technically *are* resources. If you're arguing with that statement,
> you should explain how this is incorrect according to RFC2396 (which is
> the relevant spec here).
> Whether we should *say* that they are resources is a different question.
> We don't need to say it, but my feeling was that it helps understanding
> how they work.
Right. The disagreement is not whether they are resources are not. The
rfc you mention clearly allows them and just about anything else in the
world to be a resource.

The disagreement is over whether we should mention that they are
resources.

Down the road we might want to openly call them resources if we go
ahead and have the lock-token be a URL that responds to
GET/DELETE/PROPSTAT methods, but right now calling these things
resources despite the fact that they don't have the behaviors that
our spec spends so much time defining for resources would be
confusing and not really helpful.
--=_alternative 004EC42785256ECB_=-- From w3c-dist-auth-request@w3.org Thu Jul 8 12:13:54 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06102 for ; Thu, 8 Jul 2004 12:13:54 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id CA7FBA1268; Thu, 8 Jul 2004 12:13:55 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by frink.w3.org (Postfix) with SMTP id F33EEA1268 for ; Thu, 8 Jul 2004 12:13:51 -0400 (EDT) Received: (qmail 30662 invoked by uid 65534); 8 Jul 2004 16:13:47 -0000 Received: from pD9E51CFC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.252) by mail.gmx.net (mp014) with SMTP; 08 Jul 2004 18:13:47 +0200 X-Authenticated: #1915285 Message-ID: <40ED72B5.3060206@gmx.de> Date: Thu, 08 Jul 2004 18:13:41 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Lowney Cc: w3c-dist-auth@frink.w3.org References: