From w3c-dist-auth-request@w3.org Wed Aug 1 05:32:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23996 for ; Wed, 1 Aug 2001 05:32:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA20103; Wed, 1 Aug 2001 05:30:45 -0400 (EDT) Resent-Date: Wed, 1 Aug 2001 05:30:45 -0400 (EDT) Resent-Message-Id: <200108010930.FAA20103@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA20081 for ; Wed, 1 Aug 2001 05:30:31 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA32043 for ; Wed, 1 Aug 2001 05:30:30 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id KAA25908; Wed, 1 Aug 2001 10:30:24 +0100 (BST) Received: from eurgbrbh01.emeacinops.xerox.com (eurgbrbh01.eur.xerox.com [13.202.66.71]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id KAA08390; Wed, 1 Aug 2001 10:30:22 +0100 (BST) Received: from gbrwgcbh01.wgc.gbr.xerox.com ([13.200.2.175]) by eurgbrbh01.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PPQZ9XBJ; Wed, 1 Aug 2001 10:30:21 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 10:30:24 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB7767287600@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Alan Kent'" , w3c-dist-auth@w3.org Date: Wed, 1 Aug 2001 10:30:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5207 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: Bits snipped. All IMHO. > -----Original Message----- > From: Alan Kent [mailto:ajk@mds.rmit.edu.au] > Sent: 01 August 2001 03:19 > To: w3c-dist-auth@w3.org > Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > Sticking with a UNIX file system is easier to explain. > > There are possible solutions. For example, create a file, lock it, > then if the WebDAV client issues a MKCOL, delete the file and create > a directory instead and hope another application does not sneak in > with a race condition and create the directory first. (Deleting the > file I believe will delete the lock.) But this defeats the purpose of > a lock, doesn't it? It does reduce the chance of a race condition, but > it is not a guarantee. I think you are taking WebDAV out of its intended context (see below). You don't need race conditions because your WebDAV layer in the above example can be circumvented full stop. For example, there's nothing to stop another non-WebDAV application creating a directory with the same name as the LNR even though your WebDAV server has created a LNR. As far as the WebDAV client is concerned, they have reserved the name. When your server tries to create the directory (after a MKCOL), it will fail unless you delete the existing directory first which probably wouldn't be very popular (and the failure may confuse the client). Unless the heart of your "back end" (in this case a OS's file system) supports WebDAV, its going to be a "best effort" approach. Everything is difficult (not just the LOCKing mechanism) when you have multiple protocols into the same shared data area. Unless there is some common base "controller", you will always run into these sort of problems. > > To summarise: I can implement LNR in the WebDAV layer easily. But as > soon as the underlying data store is accessible by an means other > than WebDAV, the locking model (for a 100% correct implementation of > locks) must be pushed down into a common layer. I believe the problem > with the WebDAV LNR is that it is not a commonly implemented > scheme for > locking by other systems, so it will be hard for implementors to > implement correctly according to the spec. > > The choices (in my opinion) then are > > (1) Its ok for implementors to not implement locking safely - its just > an aid for applications, not something they should rely on. > > (2) Locking is only to protect against other WebDAV clients and not > against anything else > > (3) WebDAV is only for use when the underlying storage model supports > the LNR concept > > (4) The locking model needs to change > > I think (3) is not an appropriate choice for WebDAV as it > restricts its > scope too much (I don't know of any other system that supports LNR). > I think (2) is silly - what is the purpose of locking if they > don't work? > I think the real choices are (1) or (4). With the current WebDAV spec, > (1) is the only choice to me. Actually 2) is correct as well: Remember that WebDAV is a set of extensions to HTTP, which suffers similar problems. WebDAV is about WWW functionality, not a "be all and end all" access mechanism for everything - see section 1 of RFC 2518, read RFC 2291. This is what I mean when I say you've taken WebDAV out of intended context. Your example of other applications accessing your Web/WebDAV Server's data area is not WWW functionality and therefore WebDAV does not apply IMHO. People have to live with it. Is WebDAV going to stop admins/root formatting the hard disk which contains the data ? In your file system example, there is nothing to stop another application deleting a file (that is not a LNR) that your WebDAV Server has locked. Therefore the locking mechanism has failed. What mechanism can you invent that would solve all these multiple protocol problems? This is NOT a WebDAV problem, but occurs whenever you have multiple paths/protocols/etc into a shared data area. In the real world, the end users system in question should be configured so only HTTP/WebDAV clients can access the data area that the WebDAV Server interacts with. If this cannot be done, there is not a lot you can do about the WebDAV protocol being circumvented. Simply because you as a WebDAV implementor do not have full control (unless you start writing OS file system drivers :-). > > Alan > Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Wed Aug 1 20:16:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12407 for ; Wed, 1 Aug 2001 20:16:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA14017; Wed, 1 Aug 2001 20:14:41 -0400 (EDT) Resent-Date: Wed, 1 Aug 2001 20:14:41 -0400 (EDT) Resent-Message-Id: <200108020014.UAA14017@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA13993 for ; Wed, 1 Aug 2001 20:14:35 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA29340 for ; Wed, 1 Aug 2001 20:14:31 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 115C349B67; Thu, 2 Aug 2001 10:13:41 +1000 (EST) Date: Thu, 2 Aug 2001 10:13:41 +1000 From: Alan Kent To: w3c-dist-auth@w3.org Message-ID: <20010802101341.A19978@io.mds.rmit.edu.au> References: <59697CCC6CE3D411B4CD00805FBB7767287600@gbrwgcms03.wgc.gbr.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <59697CCC6CE3D411B4CD00805FBB7767287600@gbrwgcms03.wgc.gbr.xerox.com>; from Hall, Shaun on Wed, Aug 01, 2001 at 10:30:22AM +0100 Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5208 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I am discussing only for the sake of discussing - not because I actually have a strong opinion on this. On Wed, Aug 01, 2001 at 10:30:22AM +0100, Hall, Shaun wrote: > I think you are taking WebDAV out of its intended context (see below). I would be interested to know what the intended context for other WebDAV implementors are. > You don't need race conditions because your WebDAV layer in the above > example can be circumvented full stop. For example, there's nothing to stop > another non-WebDAV application creating a directory with the same name as > the LNR even though your WebDAV server has created a LNR. If the LOCK requests are passed down to the underlying system and supported by the underlying system, then it *is* possible to stop another non-WebDAV application doing things. My understanding is this is exactly (one of) the reasons why it was being proposed that LNR be changed. For example, I thought it would be a real issue with Oracle iFS. I might have misunderstood. I agree that not all possible implementations of the underlying system will be able to support WebDAV. But if (for example) a LNR request did create a file and lock it in the underlying file system, then other applications *would* be stopped from creating a directory with that name concurrently. This is the whole point. > Unless the heart of your "back end" (in this case a OS's file system) > supports WebDAV, its going to be a "best effort" approach. I agree with this. The question is it worth changing WebDAV to use a model closer to what the majority of file systems do support, to allow more implementations do locking properly (that is, at the file system level, not the WebDAV level). In other words, is it worth minimizing the impedience between protocols/systems? > > (2) Locking is only to protect against other WebDAV clients and not > > against anything else > Actually 2) is correct as well: I agree - this is a valid position to take (which is why I included it). I *personally* dislike it, but it is a completely valid position to take. > Remember that WebDAV is a set of extensions to HTTP, which suffers similar > problems. WebDAV is about WWW functionality, not a "be all and end all" > access mechanism for everything - see section 1 of RFC 2518, read RFC 2291. > This is what I mean when I say you've taken WebDAV out of intended context. I think this weakens WebDAV when there is no real reason to weaken it. > Your example of other applications accessing your Web/WebDAV Server's data > area is not WWW functionality and therefore WebDAV does not apply IMHO. > People have to live with it. Philosophically I think we disagree here. I am interested in WebDAV as a means to maximize integration of systems. To maximize integration it is common to have to support multiple protocols accessing the same information. I think Oracle iFS is a good example of this need in real life. I think Microsoft users using Web Folders want WebDAV to act as much like other file systems as possible and integrate with them as safely as possible. > Is WebDAV going to stop admins/root formatting > the hard disk which contains the data ? Yes. If a lock is held in the underlying file system, it cannot be unmounted (for UNIX anyway), and so cannot be reformatted. You would have to shut down the machine to circumvent this. > In your file system example, there is nothing to stop another application > deleting a file (that is not a LNR) that your WebDAV Server has locked. There is *if* the LOCK is mapped down to something the underlying file system can understand. > Therefore the locking mechanism has failed. If this is truely the case, I would almost consider arguing that locking serves > What mechanism can you invent > that would solve all these multiple protocol problems? If (and it is *if*) all the protocols can map locking requests down to the base level, then there is no problem. In terms of WebDAV my question is "should WebDAV be changed to be a better protocol citizen to make it easier to share an underlying file system with other protocols". No, there is no guarantee. But using more standard semantics would make it much more likely. > In the real world, the end users system in question should be configured so > only HTTP/WebDAV clients can access the data area that the WebDAV Server > interacts with. I would be interested in other implementors feeling on this one. Its certainly not true for our system. Its certainly not true for Oracle iFS. I am pretty sure its not true for Apache mod_dav (its not unreasonable for web site administrators to go to the file system directly). I suspect the same holds for IIS. I have probably said enough on this topic. I am interested in the outcome because it makes a difference to our locking implementation. I am not really stressed which way it goes. I agree that changing the LNR semantics will not solve *all* problems. But I dont think this alone is a reason not to try to reduce implementation/compatibility problems when used in systems with other protocols/systems etc. Alan From w3c-dist-auth-request@w3.org Wed Aug 1 22:53:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19397 for ; Wed, 1 Aug 2001 22:53:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA20265; Wed, 1 Aug 2001 22:52:13 -0400 (EDT) Resent-Date: Wed, 1 Aug 2001 22:52:13 -0400 (EDT) Resent-Message-Id: <200108020252.WAA20265@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA20245 for ; Wed, 1 Aug 2001 22:52:09 -0400 (EDT) Received: from inet-mail3.oraclecorp.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA09165 for ; Wed, 1 Aug 2001 22:52:09 -0400 Received: from gmgw01.us.oracle.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail3.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f722lNA09696; Wed, 1 Aug 2001 19:47:23 -0700 (PDT) Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81]) by gmgw01.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f722pbD15194; Wed, 1 Aug 2001 19:51:37 -0700 (PDT) Message-ID: <3B68C08B.5DEBF971@oracle.com> Date: Wed, 01 Aug 2001 19:52:59 -0700 From: Ilya Kirnos X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hall, Shaun" CC: w3c-dist-auth@w3.org References: <59697CCC6CE3D411B4CD00805FBB77672875F9@gbrwgcms03.wgc.gbr.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5209 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > I don't think LNRs should be changed at all. > > You could use a file to track the lock if you wish and you won't be > deviating from the RFC. > > The RFC doesn't place restrictions on implementation (in this case LNRs) - > you can basically use whatever you want, so why are you suggesting that the > semantics should be changed ? > > Its an implementation problem, not a protocol problem. > As I recall, there are some restrictions on the behavior of a lock-null resource that make it difficult to track with an honest-to-goodness file. For example: As I recall an LNR is supposed to show up as a member of its parent collection, but return 404 when you try to do a GET on it. This means you have to keep some metadata about that file to know that it's 'special'. You can keep it in the DAV server, but nobody else would know or care about it, so even another DAV server (forget other protocols) working against the same filesystem wouldn't know about the 'specialness'. Why would you want to limit DAV locking in this way if you have a filesystem that supports locking natively, for example? I think there were other examples as well. Generally, IMHO, LNRs have unusual behavior, and perhaps we can solve the problems LNRs are intended to solve and make them a little easier to implement on many existing systems. Like I said, I'd be up for keeping LNRs if things like this were amended. I know these are all implementation details, but if the implementation becomes one hack after another, as I think LNRs would have to be as currently defined, maybe it's time to step back and revisit the spec. -ilya From w3c-dist-auth-request@w3.org Wed Aug 1 23:21:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20098 for ; Wed, 1 Aug 2001 23:21:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA21577; Wed, 1 Aug 2001 23:20:10 -0400 (EDT) Resent-Date: Wed, 1 Aug 2001 23:20:10 -0400 (EDT) Resent-Message-Id: <200108020320.XAA21577@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA21555 for ; Wed, 1 Aug 2001 23:19:57 -0400 (EDT) Received: from inet-mail4.oraclecorp.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA11150 for ; Wed, 1 Aug 2001 23:19:56 -0400 Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail4.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f723D9t28219; Wed, 1 Aug 2001 20:13:09 -0700 (PDT) Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81]) by gmgw02.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f723JPn11551; Wed, 1 Aug 2001 20:19:25 -0700 (PDT) Message-ID: <3B68C70F.4D41C60F@oracle.com> Date: Wed, 01 Aug 2001 20:20:47 -0700 From: Ilya Kirnos X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Reschke CC: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5210 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Inspection of OPTIONS and PROPFIND responses showed: 1) Oracle IFS only supports DAV class 1, and doesn't return an ALLOW header on OPTIONS, That's correct, iFS DAV does not support locking in its current version. 2) is "getetag_blah" for all resources, Yes, that's a known hole. We're looking at cache interaction for our next release, this will fall under that. 3) It tries to return in RFC format, but uses it's locale for formatting, which obviously will not produce an RNC formatted date when your language isn't english, Tell me more about the problem? Where are we using the locale? 4) It tries to return in RFC format (and fails in the same way), while this should be in ISO8601 format, Does the spec say it has to be ISO8601? I remember that Web Folders didn't seem to like that, so we put in a hack at the last minute to make it display dates correctly. 5) (when not "unknown") is set to language strings like "ENGLISH" (which I think is incorrect according to section 14.13 of [RFC2068]) Yep, that's a bug. Will fix it in our next release. Let me know if you found any other issues. Thanks. -ilya Julian Reschke wrote: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos > > Sent: Tuesday, July 31, 2001 3:59 AM > > To: w3c-dist-auth@w3.org > > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > > > This would be fine with me as well. It basically says that if a LOCK > > > is applied to an unmapped URI, the LOCK is automatically preceded with > > > > > a PUT with a zero-length body. As Stefan and Lisa say, having a > > > zero length resource remain when the LOCK is removed will not cause > > > a problem with existing clients, and clients that care about IIS > > already > > > cannot expect to be able to apply MKCOL to a "lock null" resource. > > > > > If we didn't already have clients that expected a LOCK on an unmapped > > > URI to succeed, I'd prefer to just say that the LOCK just returns 404 > > > on an unmapped URI, but I can live with this compromise proposal. > > > > I agree: my first choice would be for abandoning the concept of a null > > lock, but if people feel strongly they should be kept, the semantics > > should be changed to allow the server to create an actual file to track > > the lock. > > > > Among other things, this allows other protocols to have at least a shot > > at playing nice with DAV locks. This point (interoperability with other > > protocols) has been brought up a couple of times in this discussion > > already, and is an important consideration for the server I'm working on > > (Oracle iFS), and I suspect for others as well. It can't just be > > ignored. > > Hi. > > If you happen to work on Oracle IFS, would it be possible to give us some > feedback on the WebDAV compliance issues listed in > > > > ? > > Thanks, > > Julian From w3c-dist-auth-request@w3.org Wed Aug 1 23:47:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21328 for ; Wed, 1 Aug 2001 23:47:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA23246; Wed, 1 Aug 2001 23:46:56 -0400 (EDT) Resent-Date: Wed, 1 Aug 2001 23:46:56 -0400 (EDT) Resent-Message-Id: <200108020346.XAA23246@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA23211 for ; Wed, 1 Aug 2001 23:46:45 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.64.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA13774 for ; Wed, 1 Aug 2001 23:46:45 -0400 Received: from Tycho (dsl3-63-249-84-213.cruzio.com [63.249.84.213]) by mail.cruzio.com with SMTP id UAA29426 for ; Wed, 1 Aug 2001 20:46:36 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 1 Aug 2001 20:43:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: IETF '51 and WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5211 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit FYI. - Jim -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, August 01, 2001 5:13 PM To: ietf-dav-versioning@w3.org; w3c-dist-auth@w3c.org Subject: [Moderator Action] IETF '51 and WebDAV Just a reminder of the schedule for IETF '51: WebDAV Working Group Meeting: Monday, August 6, 3:30PM to 5:30, Cadogan/Berkeley DeltaV breakout session, Tuesday 9:00AM to 5:00PM, location to be posted on the message board DeltaV Working Group Meeting: Wedensday, August 8, 1:00PM to 3:00 PM, Cadogan/Berkeley Hope to see you there! From w3c-dist-auth-request@w3.org Wed Aug 1 23:50:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21411 for ; Wed, 1 Aug 2001 23:50:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA23632; Wed, 1 Aug 2001 23:49:23 -0400 (EDT) Resent-Date: Wed, 1 Aug 2001 23:49:23 -0400 (EDT) Resent-Message-Id: <200108020349.XAA23632@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA23606 for ; Wed, 1 Aug 2001 23:49:09 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id XAA13943 for ; Wed, 1 Aug 2001 23:49:09 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 01 Aug 2001 23:56:51 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 23:56:51 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103CA8F44@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 1 Aug 2001 23:48:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5212 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I strongly support all of Ilya's and Allan's points. Remember that the point of the current process is to address any issues that have arisen during the implementation of 2518, and a feature that has negligible value and has demonstrated implementation and interoperability problems is a prime candidate for revision or removal. Cheers, Geoff -----Original Message----- From: Ilya Kirnos [mailto:ilya.kirnos@oracle.com] Sent: Wednesday, August 01, 2001 10:53 PM To: Hall, Shaun Cc: w3c-dist-auth@w3.org Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > I don't think LNRs should be changed at all. > > You could use a file to track the lock if you wish and you won't be > deviating from the RFC. > > The RFC doesn't place restrictions on implementation (in this case LNRs) - > you can basically use whatever you want, so why are you suggesting that the > semantics should be changed ? > > Its an implementation problem, not a protocol problem. > As I recall, there are some restrictions on the behavior of a lock-null resource that make it difficult to track with an honest-to-goodness file. For example: As I recall an LNR is supposed to show up as a member of its parent collection, but return 404 when you try to do a GET on it. This means you have to keep some metadata about that file to know that it's 'special'. You can keep it in the DAV server, but nobody else would know or care about it, so even another DAV server (forget other protocols) working against the same filesystem wouldn't know about the 'specialness'. Why would you want to limit DAV locking in this way if you have a filesystem that supports locking natively, for example? I think there were other examples as well. Generally, IMHO, LNRs have unusual behavior, and perhaps we can solve the problems LNRs are intended to solve and make them a little easier to implement on many existing systems. Like I said, I'd be up for keeping LNRs if things like this were amended. I know these are all implementation details, but if the implementation becomes one hack after another, as I think LNRs would have to be as currently defined, maybe it's time to step back and revisit the spec. -ilya From: Alan Kent [ajk@mds.rmit.edu.au] Sent: Wednesday, August 01, 2001 8:14 PM To: w3c-dist-auth@w3.org Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC I am discussing only for the sake of discussing - not because I actually have a strong opinion on this. On Wed, Aug 01, 2001 at 10:30:22AM +0100, Hall, Shaun wrote: > I think you are taking WebDAV out of its intended context (see below). I would be interested to know what the intended context for other WebDAV implementors are. > You don't need race conditions because your WebDAV layer in the above > example can be circumvented full stop. For example, there's nothing to stop > another non-WebDAV application creating a directory with the same name as > the LNR even though your WebDAV server has created a LNR. If the LOCK requests are passed down to the underlying system and supported by the underlying system, then it *is* possible to stop another non-WebDAV application doing things. My understanding is this is exactly (one of) the reasons why it was being proposed that LNR be changed. For example, I thought it would be a real issue with Oracle iFS. I might have misunderstood. I agree that not all possible implementations of the underlying system will be able to support WebDAV. But if (for example) a LNR request did create a file and lock it in the underlying file system, then other applications *would* be stopped from creating a directory with that name concurrently. This is the whole point. > Unless the heart of your "back end" (in this case a OS's file system) > supports WebDAV, its going to be a "best effort" approach. I agree with this. The question is it worth changing WebDAV to use a model closer to what the majority of file systems do support, to allow more implementations do locking properly (that is, at the file system level, not the WebDAV level). In other words, is it worth minimizing the impedience between protocols/systems? > > (2) Locking is only to protect against other WebDAV clients and not > > against anything else > Actually 2) is correct as well: I agree - this is a valid position to take (which is why I included it). I *personally* dislike it, but it is a completely valid position to take. > Remember that WebDAV is a set of extensions to HTTP, which suffers similar > problems. WebDAV is about WWW functionality, not a "be all and end all" > access mechanism for everything - see section 1 of RFC 2518, read RFC 2291. > This is what I mean when I say you've taken WebDAV out of intended context. I think this weakens WebDAV when there is no real reason to weaken it. > Your example of other applications accessing your Web/WebDAV Server's data > area is not WWW functionality and therefore WebDAV does not apply IMHO. > People have to live with it. Philosophically I think we disagree here. I am interested in WebDAV as a means to maximize integration of systems. To maximize integration it is common to have to support multiple protocols accessing the same information. I think Oracle iFS is a good example of this need in real life. I think Microsoft users using Web Folders want WebDAV to act as much like other file systems as possible and integrate with them as safely as possible. > Is WebDAV going to stop admins/root formatting > the hard disk which contains the data ? Yes. If a lock is held in the underlying file system, it cannot be unmounted (for UNIX anyway), and so cannot be reformatted. You would have to shut down the machine to circumvent this. > In your file system example, there is nothing to stop another application > deleting a file (that is not a LNR) that your WebDAV Server has locked. There is *if* the LOCK is mapped down to something the underlying file system can understand. > Therefore the locking mechanism has failed. If this is truely the case, I would almost consider arguing that locking serves > What mechanism can you invent > that would solve all these multiple protocol problems? If (and it is *if*) all the protocols can map locking requests down to the base level, then there is no problem. In terms of WebDAV my question is "should WebDAV be changed to be a better protocol citizen to make it easier to share an underlying file system with other protocols". No, there is no guarantee. But using more standard semantics would make it much more likely. > In the real world, the end users system in question should be configured so > only HTTP/WebDAV clients can access the data area that the WebDAV Server > interacts with. I would be interested in other implementors feeling on this one. Its certainly not true for our system. Its certainly not true for Oracle iFS. I am pretty sure its not true for Apache mod_dav (its not unreasonable for web site administrators to go to the file system directly). I suspect the same holds for IIS. I have probably said enough on this topic. I am interested in the outcome because it makes a difference to our locking implementation. I am not really stressed which way it goes. I agree that changing the LNR semantics will not solve *all* problems. But I dont think this alone is a reason not to try to reduce implementation/compatibility problems when used in systems with other protocols/systems etc. Alan From w3c-dist-auth-request@w3.org Thu Aug 2 00:58:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23862 for ; Thu, 2 Aug 2001 00:58:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA26820; Thu, 2 Aug 2001 00:57:00 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 00:57:00 -0400 (EDT) Resent-Message-Id: <200108020457.AAA26820@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA26800 for ; Thu, 2 Aug 2001 00:56:53 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id AAA19235 for ; Thu, 2 Aug 2001 00:56:52 -0400 Received: (qmail 6686 invoked by uid 0); 2 Aug 2001 04:56:22 -0000 Received: from pd950c2f5.dip.t-dialin.net (HELO lisa) (217.80.194.245) by mail.gmx.net (mail10) with SMTP; 2 Aug 2001 04:56:22 -0000 From: "Julian Reschke" To: "Ilya Kirnos" , "Julian Reschke" Cc: Date: Thu, 2 Aug 2001 06:56:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B68C70F.4D41C60F@oracle.com> Importance: Normal Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5213 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Ilya Kirnos [mailto:ilya.kirnos@oracle.com] > Sent: Thursday, August 02, 2001 5:21 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > Inspection of OPTIONS and PROPFIND responses showed: > > 1) Oracle IFS only supports DAV class 1, and doesn't return an ALLOW > header > on OPTIONS, > > > That's correct, iFS DAV does not support locking in its current version. > > 2) is "getetag_blah" for all resources, > > > Yes, that's a known hole. We're looking at cache interaction for our next > release, this will fall under that. > > 3) It tries to return in RFC format, but uses it's > locale > for formatting, which obviously will not produce an RNC formatted > date when > your language isn't english, > > Tell me more about the problem? Where are we using the locale? As far as I remember, with WebIFS installed on a german Windows2000 server machine, it will generate something like "Montag, 12. Jan 1998 08:25:56 GMT" rather than "Monday, 12-Jan-98 09:25:56 GMT". This means, you can't use the standard locale date formatting routines for WebDAV (or HTTP) RFC dates (unless you force it to use the english language). > 4) It tries to return in RFC format (and fails in the > same > way), while this should be in ISO8601 format, > > > Does the spec say it has to be ISO8601? I remember that Web Yes (). > Folders didn't > seem to like that, so we put in a hack at the last minute to make > it display > dates correctly. Well. The way it's done now, MS web folders won't even *mount* the directory because of the broken date format. I think I remember that an old version of MS web folders only accepted ISO8691 dates if they came with a data type attribute a la 2001-08-01T14:38:27Z This isn't nice, but at least it doesn't break any client. Newer versions of web folders don't seem to have this problem. > 5) (when not "unknown") is set to language > strings like > "ENGLISH" (which I think is incorrect according to section 14.13 of > [RFC2068]) > > > Yep, that's a bug. Will fix it in our next release. > > Let me know if you found any other issues. Due to the bugs mentioned, I currently can't use WebIFS with anything beside some special test scripts. Microsoft Webfolders (and Office) will reject them, so it's hard to do any serious testing. Thanks for the feedback! Julian From w3c-dist-auth-request@w3.org Thu Aug 2 02:31:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10358 for ; Thu, 2 Aug 2001 02:31:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA00589; Thu, 2 Aug 2001 02:30:26 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 02:30:26 -0400 (EDT) Resent-Message-Id: <200108020630.CAA00589@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA00564 for ; Thu, 2 Aug 2001 02:30:11 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA25213 for ; Thu, 2 Aug 2001 02:29:56 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id D171149B6A; Thu, 2 Aug 2001 16:27:01 +1000 (EST) Date: Thu, 2 Aug 2001 16:27:01 +1000 From: Alan Kent To: w3c-dist-auth@w3.org Message-ID: <20010802162701.F19978@io.mds.rmit.edu.au> References: <3906C56A7BD1F54593344C05BD1374B103CA8F44@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103CA8F44@SUS-MA1IT01>; from Clemm, Geoff on Wed, Aug 01, 2001 at 11:48:36PM -0400 Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5214 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: Here is a proposal I think someone else posted a while back. - LOCK on existing resource stays as is - LOCK on unmapped URI should (must? can?) create a non-collection resource - UNLOCK on the same URI without a PUT should (can?) delete the resource - MKCOL on a LOCKed unmapped URI will fail (pity, but too bad). This allows implementations to create a file in the underlying file system if they want to. In order to completely remove the concept of LNR, PROPFIND must be cleaned up too. Here are some alternatives: (1) I would say a LOCK on a unmapped URI MUST create a resource and lock it. That way it will appear in PROPFIND's. A PUT on the resource would then say 200, not 201. (2) If a LOCK creates a temporary file, PROPFIND returns it. If a LOCK does not create a temporary file, PROPFIND does not return it. (3) Keep more of the current semantics. PROPFIND returns info about LNR resources. If your implementation creates a temporary file, then your implementation does not have to worry about LNR (but it stays in the standard as a concept). I was actually going to propose a new optional flag to say for locks that the intent is to create a non-collection resource or a collection resource (where non-collection is the default for backwards compatibility). The idea is in order to be able to create a temporary placeholder resource in the underlying file system, get the client to say in advance whether it is going to PUT or MKCOL. Have a default value of PUT means MS Word will probably be conformant as is (or pretty close) for example. The problem with this however was a sequence of LOCK /a, MKCOL /a would probably have troubles (MKCOL would not like the fact that /a already existed). The implementation would have to remember that the collection created was temporary (which is probably fine actually) so the MKCOL just clears the 'temporary' status of it. Another variation (which could always be added later) is to add new variations of LOCK which has an additional mode/flag/header field to 'create collection resource' and 'create non-collection resource' so you can create and lock in an atomic operation. One question then. If LOCK on an unmapped URI creates a resource, should the resource be marked with a WebDAV property of being 'temporary'. That way a PUT or MKCOL on an existing resource marked as 'temporary' could behave as if the resource did not exist before (and return 201). The implementation however would simply clear the 'temporary' flag. A PROPFIND on the resource would also clearly identify it as being temporary. There are lots of variations possible. One could even go full circle and say "well, temporary resources are really just LNR's". The only difference is that LOCK on a unmapped URL should be able to determine in advance if its going to be a non-collection or collection resource. That way an implementation can send things down to the lower level file system if needed. (ie, it can create a temporary file or directory which other applications see as a file or directory - not as a LNR). Also in the new proposal, an UNLOCK does not have to remove the LNR (it should, but its not mandatory). To be clean, I would say it really should be a MUST not a SHOULD, but some existing implementations don't do it correctly. I guess backwards compatibility with currently implementaions is not a requirement. Oh dear, I seem to be arguing against myself. In this last bit I guess I am really saying maybe the problem with LNR's is that they dont have a resource type (collection/non-collection) when they are created. If they did have a resource type, then they could be immediately created as such a resource in the underlying file system. The WebDAV layer could remember that they are 'temporary' (LNR) resources and so remove them later, or make PUT on them return 201 etc. Alan From w3c-dist-auth-request@w3.org Thu Aug 2 04:56:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17472 for ; Thu, 2 Aug 2001 04:56:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA03575; Thu, 2 Aug 2001 04:19:13 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 04:19:13 -0400 (EDT) Resent-Message-Id: <200108020819.EAA03575@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA03554 for ; Thu, 2 Aug 2001 04:19:00 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA00847 for ; Thu, 2 Aug 2001 04:18:55 -0400 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 02 Aug 2001 10:18:18 +0200 From: "Stefan Eissing" To: "Alan Kent" , Date: Thu, 2 Aug 2001 10:18:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010802162701.F19978@io.mds.rmit.edu.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5215 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Alan Kent > > Here is a proposal I think someone else posted a while back. Very close: > - LOCK on existing resource stays as is > > - LOCK on unmapped URI should (must? can?) create a > non-collection resource MUST if the namespace is kept consistent. > - UNLOCK on the same URI without a PUT should (can?) delete the resource Same holds true for LOCK timeout. should or can is the question. > - MKCOL on a LOCKed unmapped URI will fail (pity, but too bad). > > This allows implementations to create a file in the underlying file > system if they want to. > > In order to completely remove the concept of LNR, PROPFIND must be > cleaned up too. Here are some alternatives: > > (1) I would say a LOCK on a unmapped URI MUST create a resource > and lock it. > That way it will appear in PROPFIND's. A PUT on the resource > would then > say 200, not 201. That's what I would expect. > (2) If a LOCK creates a temporary file, PROPFIND returns it. If a > LOCK does > not create a temporary file, PROPFIND does not return it. > > (3) Keep more of the current semantics. PROPFIND returns info about LNR > resources. If your implementation creates a temporary file, then your > implementation does not have to worry about LNR (but it stays in > the standard as a concept). That makes life of clients unnecessary difficult. > I was actually going to propose a new optional flag to say for locks > that the intent is to create a non-collection resource or a collection > resource (where non-collection is the default for backwards > compatibility). The idea is in order to be able to create a temporary > placeholder resource in the underlying file system, get the client to > say in advance whether it is going to PUT or MKCOL. Have a default > value of PUT means MS Word will probably be conformant as is (or pretty > close) for example. > > [removed neuronal interference patterns] The question is what to do with such resources when they are unlocked or the lock times out. Possibilities: 1. If the resource disappears, WebDAV still has the concepts of LNRs and servers have to track resources created by a LOCK. 2. If the resource stays as an empty file, the concept of LNRs can be removed completely from the spec. Additionally, servers would have no need to track resources created by LOCK. I favour the second approach. It gives most bang for less bugs. //Stefan From w3c-dist-auth-request@w3.org Thu Aug 2 09:32:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26720 for ; Thu, 2 Aug 2001 09:32:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA16527; Thu, 2 Aug 2001 09:16:26 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 09:16:26 -0400 (EDT) Resent-Message-Id: <200108021316.JAA16527@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA16488 for ; Thu, 2 Aug 2001 09:16:20 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA28366 for ; Thu, 2 Aug 2001 09:16:21 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 02 Aug 2001 09:24:00 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 09:24:00 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103CA8FA3@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 2 Aug 2001 09:15:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5216 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Alan Kent > - LOCK on existing resource stays as is > - LOCK on unmapped URI should (must? can?) create a > non-collection resource MUST if the namespace is kept consistent. A MUST is always better than a SHOULD or MAY, so we should try for a MUST. One alternative is "MUST fail with 404", but to minimize impact on existing implementations, I'd support "MUST create a non-collection resource". I'd phrase it as "MUST produce the same result as if the LOCK were preceded with a PUT with a zero-length body. > - UNLOCK on the same URI without a PUT should (can?) delete the resource Same holds true for LOCK timeout. should or can is the question. Here as well we should try for a MUST. Automatic resource deletion is one of the main incompatibilities of lock-null resources with other protocols. One problem is that when an "unlock" operation is seen, an implementation would have to ask "if this unlock is from WebDAV, then do an auto-delete, otherwise just unlock it". But implementation layering often will not allow you to do a deletion as a side effect of the unlock operation. It is very unlikely that an existing repository will be re-layered to support an unnecessary construct like lock-null resources, which means that (as was done by Microsoft), the auto-delete behavior will not be implemented. There is a reason why no other protocol has introduced a concept like lock-null resources ... they are unnecessary. So I advocate that a resource created by a LOCK on an unbound resource should behave just like a resource created by PUT, with no special auto-delete on UNLOCK characteristics. > - MKCOL on a LOCKed unmapped URI will fail ... I agree, but would phrase this differently. There would be no such thing as an locked unmapped URI, since the LOCK will automatically create a resource, which is then locked. Then it is expected that a MKCOL will fail, because MKCOL only succeeds on an unmapped URI. > In order to completely remove the concept of LNR, PROPFIND must be > cleaned up too. I don't think PROPFIND behavior is affected, but PUT is. > Here are some alternatives: > (1) I would say a LOCK on a unmapped URI MUST create a resource > and lock it. > That way it will appear in PROPFIND's. A PUT on the resource > would then > say 200, not 201. That's what I would expect. I agree. > (2) If a LOCK creates a temporary file, PROPFIND returns it. If a > LOCK does > not create a temporary file, PROPFIND does not return it. > > (3) Keep more of the current semantics. PROPFIND returns info about LNR > resources. If your implementation creates a temporary file, then your > implementation does not have to worry about LNR (but it stays in > the standard as a concept). That makes life of clients unnecessary difficult. I agree. Just say LOCK of an unmapped URI does an "auto-PUT", and then nothing more needs to be said. > I was actually going to propose a new optional flag to say for locks > that the intent is to create a non-collection resource or a collection > resource (where non-collection is the default for backwards > compatibility). I would vigorously argue against this added complexity, without a very compelling argument that this is required for a use case that cannot be otherwise achieved. The question is what to do with such resources when they are unlocked or the lock times out. Possibilities: 1. If the resource disappears, WebDAV still has the concepts of LNRs and servers have to track resources created by a LOCK. 2. If the resource stays as an empty file, the concept of LNRs can be removed completely from the spec. Additionally, servers would have no need to track resources created by LOCK. I favour the second approach. It gives most bang for less bugs. I totally agree. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Aug 2 09:42:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27098 for ; Thu, 2 Aug 2001 09:42:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA16852; Thu, 2 Aug 2001 09:23:04 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 09:23:04 -0400 (EDT) Resent-Message-Id: <200108021323.JAA16852@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA16672 for ; Thu, 2 Aug 2001 09:22:55 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA29160 for ; Thu, 2 Aug 2001 09:22:51 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA41940 for ; Thu, 2 Aug 2001 08:20:47 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f72DLX8109496 for ; Thu, 2 Aug 2001 09:21:33 -0400 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Steve K Speicher" Date: Thu, 2 Aug 2001 09:22:50 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 08/02/2001 09:21:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Why MKCOL/PUT can't automatically create ancestor collections? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5217 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I assume that based on the lack of response to my previous posting (http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0286.html), that no one is in agreement that I have a valid point/issue. Should I assume this? Thanks, Steve > Re: Why MKCOL/PUT can't automatically create ancestor collections? > > From: Steve K Speicher (sspeiche@us.ibm.com) > Date: Mon, Jun 18 2001 > > ------------------------------------------------------------------------ > > To: w3c-dist-auth@w3.org > From: "Steve K Speicher" > Date: Mon, 18 Jun 2001 09:48:51 -0400 > Subject: Re: Why MKCOL/PUT can't automatically create ancestor collections? > > Sorry about the delay on the response... > > "Jim Amsden" wrote: > > I think the reasoning was the same for PUT, PROPPATCH, etc. You don't > want > > the server creating namespaces as the side effect of an operation. MKCOL > > and DELETE make namespace manipulations explicit. This prevents > erroneously > > typed URLs from creating spurious namespaces. > > > I don't understand how making these explict will cause anything other than > forcing a bunch of overhead. > > Take for example, in a client app the user decides to do a "Create file > with path: 0/1/2/3/4/5/6/7/8/9/foo.c" > > The client app has the options of: > a) Performing the PUT and seeing what the status code is. If it is 409, > then client can then attempt a MKCOL on each parent collection until one is > successful. Once successful, then traverse back down the path and perform > each MKCOL, then perform the PUT. > b) Performing many PROPFIND's (either starting from the root or from the > file resource), then perform a MKCOL for each collection and then finally > the PUT. > > Does the client app have to prompt the user whether each collection should > be created? How does forcing the client app to perform all these > operations prevent erroneously typed URLs from spurious namespaces? > > My app does a large amount of *implicit* namespace creation and I'd like to > do a simple: > PUT /0/1/2/3/4/5/6/7/8/9/foo.c HTTP/1.1 > and have the parent collections implicitly created if they don't exist but > the spec forces the overhead mentioned above. > > Could this server behavior be advertised using the DAV header with > something like "auto-collections"? Then if one so desired, removing the > requirement that "PUT operation creates a new non-collection resource all > ancestors MUST already exist" (RFC2518 8.2.2) if auto-collections is > supported and making the method MKCOL an optional feature. > I'm not sure this requirement is consistent with DELETE, MOVE, and COPY: > which can perform a large amount of namespace manipulation in one METHOD > (namely on a parent collection). There is no way to guarantee that the new > target destination URL has not been erroneously typed other then by user > inspection after the fact (or by client app prompting, do we ever pay > attention to those ;-) > > Thoughts? > From w3c-dist-auth-request@w3.org Thu Aug 2 10:21:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28584 for ; Thu, 2 Aug 2001 10:21:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA21861; Thu, 2 Aug 2001 10:13:47 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 10:13:47 -0400 (EDT) Resent-Message-Id: <200108021413.KAA21861@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA21825 for ; Thu, 2 Aug 2001 10:13:34 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA03391 for ; Thu, 2 Aug 2001 10:13:34 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 02 Aug 2001 10:21:17 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 10:21:17 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103CA8FF4@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 2 Aug 2001 10:13:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Why MKCOL/PUT can't automatically create ancestor collections ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5218 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: Yes, no response is usually an indication of lack of interest, but to make it explicit, I personally do not feel that the optimization of auto-creation of ancestor collections warrants the added complexity of having either an "auto-create ancestor" header, or having it be server-defined whether or not ancestor auto-creation takes place. Cheers, Geoff -----Original Message----- From: Steve K Speicher [mailto:sspeiche@us.ibm.com] Sent: Thursday, August 02, 2001 9:23 AM To: w3c-dist-auth@w3.org Subject: Re: Why MKCOL/PUT can't automatically create ancestor collections? I assume that based on the lack of response to my previous posting (http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0286.html), that no one is in agreement that I have a valid point/issue. Should I assume this? Thanks, Steve > Re: Why MKCOL/PUT can't automatically create ancestor collections? > > From: Steve K Speicher (sspeiche@us.ibm.com) > Date: Mon, Jun 18 2001 > > ------------------------------------------------------------------------ > > To: w3c-dist-auth@w3.org > From: "Steve K Speicher" > Date: Mon, 18 Jun 2001 09:48:51 -0400 > Subject: Re: Why MKCOL/PUT can't automatically create ancestor collections? > > Sorry about the delay on the response... > > "Jim Amsden" wrote: > > I think the reasoning was the same for PUT, PROPPATCH, etc. You don't > want > > the server creating namespaces as the side effect of an operation. MKCOL > > and DELETE make namespace manipulations explicit. This prevents > erroneously > > typed URLs from creating spurious namespaces. > > > I don't understand how making these explict will cause anything other than > forcing a bunch of overhead. > > Take for example, in a client app the user decides to do a "Create file > with path: 0/1/2/3/4/5/6/7/8/9/foo.c" > > The client app has the options of: > a) Performing the PUT and seeing what the status code is. If it is 409, > then client can then attempt a MKCOL on each parent collection until one is > successful. Once successful, then traverse back down the path and perform > each MKCOL, then perform the PUT. > b) Performing many PROPFIND's (either starting from the root or from the > file resource), then perform a MKCOL for each collection and then finally > the PUT. > > Does the client app have to prompt the user whether each collection should > be created? How does forcing the client app to perform all these > operations prevent erroneously typed URLs from spurious namespaces? > > My app does a large amount of *implicit* namespace creation and I'd like to > do a simple: > PUT /0/1/2/3/4/5/6/7/8/9/foo.c HTTP/1.1 > and have the parent collections implicitly created if they don't exist but > the spec forces the overhead mentioned above. > > Could this server behavior be advertised using the DAV header with > something like "auto-collections"? Then if one so desired, removing the > requirement that "PUT operation creates a new non-collection resource all > ancestors MUST already exist" (RFC2518 8.2.2) if auto-collections is > supported and making the method MKCOL an optional feature. > I'm not sure this requirement is consistent with DELETE, MOVE, and COPY: > which can perform a large amount of namespace manipulation in one METHOD > (namely on a parent collection). There is no way to guarantee that the new > target destination URL has not been erroneously typed other then by user > inspection after the fact (or by client app prompting, do we ever pay > attention to those ;-) > > Thoughts? > From w3c-dist-auth-request@w3.org Thu Aug 2 10:46:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29773 for ; Thu, 2 Aug 2001 10:46:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA24491; Thu, 2 Aug 2001 10:40:40 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 10:40:40 -0400 (EDT) Resent-Message-Id: <200108021440.KAA24491@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA24433 for ; Thu, 2 Aug 2001 10:40:13 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA07491 for ; Thu, 2 Aug 2001 10:40:02 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id PAA07198; Thu, 2 Aug 2001 15:39:48 +0100 (BST) Received: from eurgbrbh02.emeacinops.xerox.com (eurgbrbh02.eur.xerox.com [13.202.66.72]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id PAA07416; Thu, 2 Aug 2001 15:36:16 +0100 (BST) Received: from gbrwgcbh01.wgc.gbr.xerox.com ([13.200.2.175]) by eurgbrbh02.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PV3K3053; Thu, 2 Aug 2001 15:36:15 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 15:36:06 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB7767287601@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Alan Kent'" , w3c-dist-auth@w3.org Date: Thu, 2 Aug 2001 15:36:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OT Bypassing WebDAV LOCK mechanism (was RFC2518 issue...) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5220 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: Again, not bashing the vendors/implementors as these are observations and its all IMHO ... > -----Original Message----- > From: Alan Kent [mailto:ajk@mds.rmit.edu.au] > Sent: 02 August 2001 01:14 > To: w3c-dist-auth@w3.org > Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > I would be interested in other implementors feeling on this one. > Its certainly not true for our system. Its certainly not true > for Oracle iFS. I am pretty sure its not true for Apache mod_dav > (its not unreasonable for web site administrators to go to the file > system directly). I suspect the same holds for IIS. FYI: Greg/Keith (or whoever wrote it) sums it up nicely. Take a look at the "Caveats" for mod_dav at http://www.webdav.org/mod_dav/win32/, specifically the 3rd bullet. Off the top of my head, I don't know if this applies to the Unix version as well. I haven't tested either platform in this destructive manner. Maybe Greg can shed more light on the matter. As a side note, I did a quick test with IIS on Windows 2000. Sure enough, when you LOCK an existing file (can't lock folders) or create an LNR, the file (including LNR as they are implemented as files) cannot be deleted say via the cmd line ("In use by another process" kinda msg). Looks good so far. However, using a utility (SysInternals Process Explorer at http://www.sysinternals.com/ntw2k/freeware/procexp.shtml), I could close the handle to the locked file (whilst it was still locked by IIS) and then delete the file via the cmd line. I haven't investigated how Process Viewer actually closes the handle (maybe a call with Win32 CloseHandle()) or what permissions are needed (I did it all with Admin rights). See how easy it was for me to circumvent the *entire* WebDAV LOCK mechanism (for LNR and "normal" resources) ? Okay this is getting a little off topic, but you get my point. > > > I have probably said enough on this topic. Me too :-) > > Alan > Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Thu Aug 2 13:30:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29774 for ; Thu, 2 Aug 2001 10:46:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA24466; Thu, 2 Aug 2001 10:40:34 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 10:40:34 -0400 (EDT) Resent-Message-Id: <200108021440.KAA24466@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA24435 for ; Thu, 2 Aug 2001 10:40:21 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA07644 for ; Thu, 2 Aug 2001 10:40:20 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 02 Aug 2001 10:48:03 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 10:48:03 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103CA9013@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Thu, 2 Aug 2001 10:39:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Reason for disappearing lock-null resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5219 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Lisa Dusseault [mailto:lisa@xythos.com] I think I reconstructed why lock-null resources were designed to disappear when their locks go away. It's because lock-null resources may be created accidentally, then they may not be removable if the user doesn't have delete permission. That probably is right, and it also highlights why lock-null resources are unlikely to be implemented in multi-protocol repositories. In order to maintain DAV locking semantics, a multi-protocol repository will allocate a "regular" resource as the result of applying a LOCK to an unmapped URL. But then at UNLOCK time, the regular resource constraints will apply, and you may be able to unlock the resource but not be able to delete that regular resource that was created to hold the lock. A secure repository is unlikely to give the WebDAV process a hammer big enough to violate the underlying acl constraints on a resource, and so the resource will remain undeleted, no matter what the protocol says. It would be preferable to make this behavior predictable. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Aug 2 14:04:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10255 for ; Thu, 2 Aug 2001 14:04:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11652; Thu, 2 Aug 2001 13:58:52 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 13:58:52 -0400 (EDT) Resent-Message-Id: <200108021758.NAA11652@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA11616 for ; Thu, 2 Aug 2001 13:58:41 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA31909 for ; Thu, 2 Aug 2001 13:58:40 -0400 Received: from [216.36.75.57] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 3568814; Thu, 02 Aug 2001 10:53:27 -0700 From: "Lisa Dusseault" To: "Jim Amsden" , , Date: Thu, 2 Aug 2001 10:58:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Subject: RE: IETF '51 and WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5221 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Please make sure the breakout session is at or near the conference hotel. There are other meetings on Tuesday that may be of interest to WebDAV implementors: WebI, IP Storage. lisa > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden > Sent: Wednesday, August 01, 2001 5:11 PM > To: ietf-dav-versioning@w3.org; w3c-dist-auth@w3c.org > Subject: IETF '51 and WebDAV > > > Just a reminder of the schedule for IETF '51: > > WebDAV Working Group Meeting: Monday, August 6, 3:30PM to 5:30, > Cadogan/Berkeley > DeltaV breakout session, Tuesday 9:00AM to 5:00PM, location to be posted > on the message board > DeltaV Working Group Meeting: Wedensday, August 8, 1:00PM to 3:00 PM, > Cadogan/Berkeley > > Hope to see you there! From w3c-dist-auth-request@w3.org Thu Aug 2 14:30:41 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11636 for ; Thu, 2 Aug 2001 14:30:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA13004; Thu, 2 Aug 2001 14:23:03 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 14:23:03 -0400 (EDT) Resent-Message-Id: <200108021823.OAA13004@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA12956 for ; Thu, 2 Aug 2001 14:22:47 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA02397 for ; Thu, 2 Aug 2001 14:22:48 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA343480; Thu, 2 Aug 2001 14:20:13 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f72IEU649830; Thu, 2 Aug 2001 14:14:30 -0400 Importance: Normal To: Alan Kent Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 2 Aug 2001 14:11:39 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/02/2001 02:22:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5222 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: > - UNLOCK on the same URI without a PUT should (can?) delete the resource I think most people would change this to be... - UNLOCK on the same URI without a PUT should NOT delete the resource This will give existing implementations that try to delete it some flexibility but push people away from that direction. I doubt we can say anything stronger right now. From w3c-dist-auth-request@w3.org Thu Aug 2 14:52:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13067 for ; Thu, 2 Aug 2001 14:52:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA14363; Thu, 2 Aug 2001 14:49:02 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 14:49:02 -0400 (EDT) Resent-Message-Id: <200108021849.OAA14363@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA14343 for ; Thu, 2 Aug 2001 14:48:50 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA05779 for ; Thu, 2 Aug 2001 14:48:50 -0400 Received: from [216.36.75.57] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 3575187; Thu, 02 Aug 2001 11:43:37 -0700 From: "Lisa Dusseault" To: "Clemm, Geoff" , Date: Thu, 2 Aug 2001 11:48:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103CA8FF4@SUS-MA1IT01> Subject: RE: Why MKCOL/PUT can't automatically create ancestor collections ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5223 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'll second that; it's unnecessary complexity. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, August 02, 2001 7:13 AM > To: w3c-dist-auth@w3.org > Subject: RE: Why MKCOL/PUT can't automatically create ancestor > collections ? > > > Yes, no response is usually an indication of lack of interest, > but to make it explicit, I personally do not feel > that the optimization of auto-creation of ancestor > collections warrants the added complexity of having either an > "auto-create ancestor" header, or having it be server-defined whether > or not ancestor auto-creation takes place. > > Cheers, > Geoff > > -----Original Message----- > From: Steve K Speicher [mailto:sspeiche@us.ibm.com] > Sent: Thursday, August 02, 2001 9:23 AM > To: w3c-dist-auth@w3.org > Subject: Re: Why MKCOL/PUT can't automatically create ancestor > collections? > > > I assume that based on the lack of response to my previous posting > (http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0286.html), > that no one is in agreement that I have a valid point/issue. > > Should I assume this? > > Thanks, > Steve > > > Re: Why MKCOL/PUT can't automatically create ancestor collections? > > > > From: Steve K Speicher (sspeiche@us.ibm.com) > > Date: Mon, Jun 18 2001 > > > > > ------------------------------------------------------------------------ > > > > To: w3c-dist-auth@w3.org > > From: "Steve K Speicher" > > Date: Mon, 18 Jun 2001 09:48:51 -0400 > > Subject: Re: Why MKCOL/PUT can't automatically create ancestor > collections? > > > > Sorry about the delay on the response... > > > > "Jim Amsden" wrote: > > > I think the reasoning was the same for PUT, PROPPATCH, etc. You don't > > want > > > the server creating namespaces as the side effect of an operation. > MKCOL > > > and DELETE make namespace manipulations explicit. This prevents > > erroneously > > > typed URLs from creating spurious namespaces. > > > > > I don't understand how making these explict will cause anything other > than > > forcing a bunch of overhead. > > > > Take for example, in a client app the user decides to do a "Create file > > with path: 0/1/2/3/4/5/6/7/8/9/foo.c" > > > > The client app has the options of: > > a) Performing the PUT and seeing what the status code is. If it is 409, > > then client can then attempt a MKCOL on each parent collection until one > is > > successful. Once successful, then traverse back down the path and > perform > > each MKCOL, then perform the PUT. > > b) Performing many PROPFIND's (either starting from the root or from the > > file resource), then perform a MKCOL for each collection and > then finally > > the PUT. > > > > Does the client app have to prompt the user whether each collection > should > > be created? How does forcing the client app to perform all these > > operations prevent erroneously typed URLs from spurious namespaces? > > > > My app does a large amount of *implicit* namespace creation and I'd like > to > > do a simple: > > PUT /0/1/2/3/4/5/6/7/8/9/foo.c HTTP/1.1 > > and have the parent collections implicitly created if they don't exist > but > > the spec forces the overhead mentioned above. > > > > Could this server behavior be advertised using the DAV header with > > something like "auto-collections"? Then if one so desired, removing the > > requirement that "PUT operation creates a new non-collection > resource all > > ancestors MUST already exist" (RFC2518 8.2.2) if auto-collections is > > supported and making the method MKCOL an optional feature. > > I'm not sure this requirement is consistent with DELETE, MOVE, and COPY: > > which can perform a large amount of namespace manipulation in one METHOD > > (namely on a parent collection). There is no way to guarantee that the > new > > target destination URL has not been erroneously typed other then by user > > inspection after the fact (or by client app prompting, do we ever pay > > attention to those ;-) > > > > Thoughts? > > > From w3c-dist-auth-request@w3.org Thu Aug 2 17:08:21 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19591 for ; Thu, 2 Aug 2001 17:08:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA20477; Thu, 2 Aug 2001 17:01:41 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 17:01:41 -0400 (EDT) Resent-Message-Id: <200108022101.RAA20477@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA20401 for ; Thu, 2 Aug 2001 17:01:31 -0400 (EDT) Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA19189 for ; Thu, 2 Aug 2001 17:01:31 -0400 Received: from sus-ma1it00.rational.com by sophia.inria.fr (8.11.1/8.10.0) with SMTP id f72Kr8A16694 for ; Thu, 2 Aug 2001 22:53:09 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host ext-37015.rational.com [192.229.37.15] claimed to be sus-ma1it00.rational.com Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 02 Aug 2001 17:00:22 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 17:00:22 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E255C@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 2 Aug 2001 16:52:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5225 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Jason's revision, although I'd probably further revise the wording to say: "When a new resource is created by a LOCK request against an unmapped URI, if an UNLOCK is applied to that resource before it has been explicitly updated (e.g. by a PUT or a PROPPATCH), then that resource SHOULD NOT be deleted as a side effect of the UNLOCK. Note that this changes the behavior defined in RFC-2518, which stated that the resource MUST be deleted in this case." Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, August 02, 2001 2:12 PM To: Alan Kent Cc: w3c-dist-auth@w3.org Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > - UNLOCK on the same URI without a PUT should (can?) delete the resource I think most people would change this to be... - UNLOCK on the same URI without a PUT should NOT delete the resource This will give existing implementations that try to delete it some flexibility but push people away from that direction. I doubt we can say anything stronger right now. From w3c-dist-auth-request@w3.org Thu Aug 2 19:05:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29472 for ; Thu, 2 Aug 2001 19:05:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA17730; Thu, 2 Aug 2001 16:03:27 -0400 (EDT) Resent-Date: Thu, 2 Aug 2001 16:03:27 -0400 (EDT) Resent-Message-Id: <200108022003.QAA17730@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA17703 for ; Thu, 2 Aug 2001 16:03:21 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA13766 for ; Thu, 2 Aug 2001 16:03:21 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id NAA23251; Thu, 2 Aug 2001 13:03:20 -0700 (PDT) From: "Jim Whitehead" To: "Steve K Speicher" , Date: Thu, 2 Aug 2001 13:00:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Why MKCOL/PUT can't automatically create ancestor collections? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5224 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > I assume that based on the lack of response to my previous posting > (http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0286.html), > that no one is in agreement that I have a valid point/issue. > > Should I assume this? I went a couple rounds with Yoram Last on a similar issue back in 1999: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0062.html - Jim From w3c-dist-auth-request@w3.org Fri Aug 3 06:33:26 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12454 for ; Fri, 3 Aug 2001 06:33:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA00588; Fri, 3 Aug 2001 06:32:22 -0400 (EDT) Resent-Date: Fri, 3 Aug 2001 06:32:22 -0400 (EDT) Resent-Message-Id: <200108031032.GAA00588@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA00564 for ; Fri, 3 Aug 2001 06:32:17 -0400 (EDT) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA19106 for ; Fri, 3 Aug 2001 06:32:17 -0400 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id f73AVTO22942 for ; Fri, 3 Aug 2001 03:31:29 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f73AVRb25639 for ; Fri, 3 Aug 2001 03:31:27 -0700 (PDT) Received: from larrypad ([130.248.184.180]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with SMTP id GHHMKN00.JNY for ; Fri, 3 Aug 2001 03:31:35 -0700 From: "Larry Masinter" To: Date: Fri, 3 Aug 2001 03:30:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: WebDAV Interoperability Event report Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5226 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On July 19th and 20th, there was a WebDAV interoperability event at UCSC, Santa Cruz. There were nearly 60 people at the event, from 20 different organizations, representing 35 implementations of WebDAV, including 17 clients and 18 servers. The event was a great success; lots got tested, lots of issues. See http://www.webdav.org/users/masinter/interop/report.html From w3c-dist-auth-request@w3.org Fri Aug 3 15:13:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24649 for ; Fri, 3 Aug 2001 15:13:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA03075; Fri, 3 Aug 2001 15:10:14 -0400 (EDT) Resent-Date: Fri, 3 Aug 2001 15:10:14 -0400 (EDT) Resent-Message-Id: <200108031910.PAA03075@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA03054 for ; Fri, 3 Aug 2001 15:10:04 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA09746 for ; Fri, 3 Aug 2001 15:10:04 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA16044 for ; Fri, 3 Aug 2001 12:10:09 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 3 Aug 2001 12:07:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: End: WG Last Call on ACL specification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5227 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This message marks the end of the WebDAV Working Group last call for comments on the WebDAV Access Control Protocol specification, draft-ietf-webdav-acl-06. This last call period began on Thursday, June 21, 2001, and ended July 29, 2001. The message starting the last call was: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0313.html While the last call period has ended, you may still submit comments on the -06 (or later) revision of the specification. My best estimate for the completion of a new revision of draft-ietf-webdav-acl is August 27th, so any comments submitted before that time would be easily incorporated into the next revision. Note that with the end of the last call period, the burden of evidence required to effect a significant design change in the protocol is now much greater. There were several comments on this specification -- kudos to Stefan, Keith, Tim, Peter and Alan for their thorough review. Stefan Eissing: http://mailman.webdav.org/pipermail/acl/2001-June/000591.html Stefan Eissing: http://mailman.webdav.org/pipermail/acl/2001-July/000595.html Keith Wannamaker: http://mailman.webdav.org/pipermail/acl/2001-July/000599.html Keith Wannamaker: http://mailman.webdav.org/pipermail/acl/2001-July/000602.html Stefan Eissing: http://mailman.webdav.org/pipermail/acl/2001-July/000605.html Tim Ellison: http://mailman.webdav.org/pipermail/acl/2001-July/000611.html Peter Raymond: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0036.html Alan Kent: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0006.html While many of these comments will result in modifications to the specification, these changes will not, in my opinion, be significant design modifications. As a result, it is my opinion as Chair that this document does not need another Working Group last call for comments period when draft-ietf-webdav-acl-07 is released (the -07 draft is the next revision). My plan is to revise the -06 specification accoridng to comments received during last call, and then give a few days for the commentors to read the new specification and make sure their issues have been addressed. Once this is done, draft-ietf-webdav-acl-07 will be submitted as an I-D. At this time I will also forward it to the Application Area Directors for their comments, and for eventual consideration by the IESG as a Standards Track RFC. In plain English: the next draft is very likely to be the last one before this specification is approved as a Proposed Standard (the first rung on the IETF standards track). - Jim From w3c-dist-auth-request@w3.org Sat Aug 4 13:01:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28954 for ; Sat, 4 Aug 2001 13:01:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06466; Sat, 4 Aug 2001 13:00:35 -0400 (EDT) Resent-Date: Sat, 4 Aug 2001 13:00:35 -0400 (EDT) Resent-Message-Id: <200108041700.NAA06466@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA06439 for ; Sat, 4 Aug 2001 13:00:30 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA02099 for ; Sat, 4 Aug 2001 13:00:30 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA368308; Sat, 4 Aug 2001 12:57:56 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f74GqCH53286; Sat, 4 Aug 2001 12:52:12 -0400 Importance: Normal To: "Clemm, Geoff" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sat, 4 Aug 2001 12:40:09 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/04/2001 12:59:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5228 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: > "When a new resource is created by a LOCK request against an > unmapped URI, if an UNLOCK is applied to that resource before it > has been explicitly updated (e.g. by a PUT or a PROPPATCH), then > that resource SHOULD NOT be deleted as a side effect of the UNLOCK. > Note that this changes the behavior defined in RFC-2518, which > stated that the resource MUST be deleted in this case." I support Geoff's wording above over my little one liner. :-) This would be in conjuction with Alan Kent's proposals... > - LOCK on existing resource stays as is > - LOCK on unmapped URI [should] create a non-collection resource > - MKCOL on a LOCKed unmapped URI will fail (pity, but too bad). So is this the way we want to go? Items of note so far (just to make sure we're comfortable with this): - We don't speak about what happens if you violate Geoff's (SHOULD NOT). - This doesn't speak about the nature of the non-collection resource created. Nor do we explicitly mention that this is a change of behavior from 2518 except through Geoff's words about what happens upon UNLOCK. - Presumably we'd only use the "MKCOL on a LOCKed..." wording if somewhere in the 2518 it says otherwise since this is implicit if we are clear that we generated an ordinary non-collection resource. Comments? Wordings? Additions? J. From w3c-dist-auth-request@w3.org Sun Aug 5 19:16:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23903 for ; Sun, 5 Aug 2001 19:16:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA03903; Sun, 5 Aug 2001 19:15:18 -0400 (EDT) Resent-Date: Sun, 5 Aug 2001 19:15:18 -0400 (EDT) Resent-Message-Id: <200108052315.TAA03903@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA03883 for ; Sun, 5 Aug 2001 19:15:13 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA16265 for ; Sun, 5 Aug 2001 19:15:14 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 05 Aug 2001 19:22:26 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 5 Aug 2001 19:22:26 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103CA9488@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Sun, 5 Aug 2001 19:13:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5229 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The full proposal I advocate is as follows: Delete all references to the term "lock null resource". Instead, in the LOCK semantics, add the following: "If a LOCK request is applied to an unmapped URL, the server MUST automatically precede the LOCK request with the creation of a resource at the request URL. This automatically created resource has the same behavior as a resource created by a PUT with a zero length body. In particular, it is never automatically deleted when it is UNLOCK'ed. Note that this changes the behavior defined in RFC-2518, which stated that the resource MUST be automatically deleted if it is unlocked before it has been explicitly updated (e.g. by a PUT)." I believe that this reference to the old 2518 semantics is sufficient. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] > "When a new resource is created by a LOCK request against an > unmapped URI, if an UNLOCK is applied to that resource before it > has been explicitly updated (e.g. by a PUT or a PROPPATCH), then > that resource SHOULD NOT be deleted as a side effect of the UNLOCK. > Note that this changes the behavior defined in RFC-2518, which > stated that the resource MUST be deleted in this case." I support Geoff's wording above over my little one liner. :-) This would be in conjuction with Alan Kent's proposals... > - LOCK on existing resource stays as is > - LOCK on unmapped URI [should] create a non-collection resource > - MKCOL on a LOCKed unmapped URI will fail (pity, but too bad). So is this the way we want to go? Items of note so far (just to make sure we're comfortable with this): - We don't speak about what happens if you violate Geoff's (SHOULD NOT). - This doesn't speak about the nature of the non-collection resource created. Nor do we explicitly mention that this is a change of behavior from 2518 except through Geoff's words about what happens upon UNLOCK. - Presumably we'd only use the "MKCOL on a LOCKed..." wording if somewhere in the 2518 it says otherwise since this is implicit if we are clear that we generated an ordinary non-collection resource. Comments? Wordings? Additions? J. From w3c-dist-auth-request@w3.org Mon Aug 6 00:43:33 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00311 for ; Mon, 6 Aug 2001 00:43:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA12301; Mon, 6 Aug 2001 00:38:53 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 00:38:53 -0400 (EDT) Resent-Message-Id: <200108060438.AAA12301@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA12281 for ; Mon, 6 Aug 2001 00:38:41 -0400 (EDT) Received: from www.pspl.co.in (www.pspl.co.in [202.54.11.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA05392 for ; Mon, 6 Aug 2001 00:38:40 -0400 Received: from gaurishankar (gateway.pspl.co.in [203.199.147.2]) by www.pspl.co.in (8.11.0/8.11.0) with SMTP id f764aOY27241 for ; Mon, 6 Aug 2001 10:06:24 +0530 Reply-To: From: =?iso-8859-1?Q?Medha_Atr=E9?= To: "WebDAV" Date: Mon, 6 Aug 2001 10:13:27 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Creating a Null-resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5230 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, I read RFC 2518, but I am not very clear about how to actually create a Null-Resource using available client APIs like HTTP::WebDAV (Perl) or Neon (C) ? Can anybody explain that to me ? Thanks and Regards. Medha From w3c-dist-auth-request@w3.org Mon Aug 6 01:11:41 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01717 for ; Mon, 6 Aug 2001 01:11:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA13199; Mon, 6 Aug 2001 01:11:40 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 01:11:40 -0400 (EDT) Resent-Message-Id: <200108060511.BAA13199@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA13179 for ; Mon, 6 Aug 2001 01:11:34 -0400 (EDT) Received: from www.pspl.co.in (www.pspl.co.in [202.54.11.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA07480 for ; Mon, 6 Aug 2001 01:11:33 -0400 Received: from gaurishankar (gateway.pspl.co.in [203.199.147.2]) by www.pspl.co.in (8.11.0/8.11.0) with SMTP id f7659IY28254 for ; Mon, 6 Aug 2001 10:39:18 +0530 Reply-To: From: =?iso-8859-1?Q?Medha_Atr=E9?= To: "WebDAV" Date: Mon, 6 Aug 2001 10:46:20 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Creating Multiple URIs for same resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5231 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, How to create multiple URIs for the same resource ? What requests a client gives to create a null resource ? Medha From w3c-dist-auth-request@w3.org Mon Aug 6 01:45:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06874 for ; Mon, 6 Aug 2001 01:45:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA14013; Mon, 6 Aug 2001 01:44:46 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 01:44:46 -0400 (EDT) Resent-Message-Id: <200108060544.BAA14013@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA13989 for ; Mon, 6 Aug 2001 01:44:40 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA09743 for ; Mon, 6 Aug 2001 01:44:38 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id D403149B49; Mon, 6 Aug 2001 15:43:57 +1000 (EST) Date: Mon, 6 Aug 2001 15:43:57 +1000 From: Alan Kent To: WebDAV Message-ID: <20010806154357.L22662@io.mds.rmit.edu.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95i In-Reply-To: =?iso-8859-1?Q?=3CNEBBLHKIOJLOAGDHCGDAMEKICCAA=2Emedha=5Fatre=40persiste?= =?iso-8859-1?Q?nt=2Eco=2Ein=3E=3B_from_Medha_Atr=E9_on_Mon=2C_Aug_06=2C_?= =?iso-8859-1?Q?2001_at_10:13:27AM_+0530?= Subject: Re: Creating a Null-resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5232 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Mon, Aug 06, 2001 at 10:13:27AM +0530, Medha Atré wrote: > Hello, > I read RFC 2518, but I am not very clear about how to actually create a > Null-Resource using available client APIs like HTTP::WebDAV (Perl) or Neon > (C) ? > Can anybody explain that to me ? > > Thanks and Regards. > > Medha A few people actually dislike the term 'null resource'. There is no resource of type 'null' that is ever created. Basically a 'null resource' means there is no resource. So you cannot create them. Any URI not currently bound to a resource is said to refer to a 'null resource'. A better way of describing it is that the URI is unmapped or unbound. I could imaging the terminology came about from the concept of having a variable in a programming language of type 'resource' that is null rather than pointing to a resource object. Bottom line: there is no API to create null resources because null resources are not resources. The phase "null resource" really means "there is no resource". Alan ps: I guess you could then argue that DELETE can create null resources! :-) :-) :-) From w3c-dist-auth-request@w3.org Mon Aug 6 01:49:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07554 for ; Mon, 6 Aug 2001 01:49:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA14116; Mon, 6 Aug 2001 01:49:24 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 01:49:24 -0400 (EDT) Resent-Message-Id: <200108060549.BAA14116@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA14096 for ; Mon, 6 Aug 2001 01:49:19 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA09963 for ; Mon, 6 Aug 2001 01:49:18 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 2078649B49; Mon, 6 Aug 2001 15:48:47 +1000 (EST) Date: Mon, 6 Aug 2001 15:48:46 +1000 From: Alan Kent To: =?iso-8859-1?Q?Medha_Atr=E9?= Cc: WebDAV Message-ID: <20010806154846.M22662@io.mds.rmit.edu.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95i In-Reply-To: =?iso-8859-1?Q?=3CNEBBLHKIOJLOAGDHCGDACEKKCCAA=2Emedha=5Fatre=40persiste?= =?iso-8859-1?Q?nt=2Eco=2Ein=3E=3B_from_Medha_Atr=E9_on_Mon=2C_Aug_06=2C_?= =?iso-8859-1?Q?2001_at_10:46:20AM_+0530?= Subject: Re: Creating Multiple URIs for same resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5233 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Mon, Aug 06, 2001 at 10:46:20AM +0530, Medha Atré wrote: > How to create multiple URIs for the same resource ? There was a separate proposal to introduce a BIND command which allows a URI to be bound to an existing resource given the URI of the existing resource. http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-binding-protocol-02.txt > What requests a client gives to create a null resource ? "null resource" indicates there is no resource, so you cannot "create" them. Alan From w3c-dist-auth-request@w3.org Mon Aug 6 03:33:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18346 for ; Mon, 6 Aug 2001 03:33:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA22036; Mon, 6 Aug 2001 03:32:36 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 03:32:36 -0400 (EDT) Resent-Message-Id: <200108060732.DAA22036@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA22005 for ; Mon, 6 Aug 2001 03:32:21 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA17657 for ; Mon, 6 Aug 2001 03:32:21 -0400 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 06 Aug 2001 09:32:11 +0200 From: "Stefan Eissing" To: Date: Mon, 6 Aug 2001 09:32:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103CA9488@SUS-MA1IT01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5234 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, August 06, 2001 1:13 AM > To: w3c-dist-auth@w3.org > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > The full proposal I advocate is as follows: > > Delete all references to the term "lock null resource". > > Instead, in the LOCK semantics, add the following: > > "If a LOCK request is applied to an unmapped URL, the server > MUST automatically precede the LOCK request with the creation > of a resource at the request URL. > This automatically created resource has the same behavior as > a resource created by a PUT with a zero length body. > In particular, it is never automatically deleted when it is > UNLOCK'ed. Note that this changes the behavior defined in > RFC-2518, which stated that the resource MUST be automatically > deleted if it is unlocked before it has been explicitly updated > (e.g. by a PUT)." > > I believe that this reference to the old 2518 semantics is sufficient. I fully agree and support the proposal. //Stefan From w3c-dist-auth-request@w3.org Mon Aug 6 04:58:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19906 for ; Mon, 6 Aug 2001 04:58:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA24473; Mon, 6 Aug 2001 04:47:11 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 04:47:11 -0400 (EDT) Resent-Message-Id: <200108060847.EAA24473@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA24444 for ; Mon, 6 Aug 2001 04:47:04 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA22694 for ; Mon, 6 Aug 2001 04:47:04 -0400 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA03958 for ; Mon, 6 Aug 2001 09:47:01 +0100 (BST) Received: from eurgbrbh03.emeacinops.xerox.com (eurgbrbh03.eur.xerox.com [13.202.66.73]) by eurodns4.eur.xerox.com (8.9.3/8.9.3) with ESMTP id JAA08549 for ; Mon, 6 Aug 2001 09:47:00 +0100 (BST) Received: from gbrwgcbh01.wgc.gbr.xerox.com ([13.200.2.175]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PPQVFQT5; Mon, 6 Aug 2001 09:47:00 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 09:46:50 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB7767287603@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'W3C WebDAV Mailing List'" Date: Mon, 6 Aug 2001 09:46:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: FW: OT Bypassing WebDAV LOCK mechanism (was RFC2518 issue...) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5235 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: Resending as the list didn't send me (or a colleague) a copy so not sure if it got through. Apologies if you've seen this. Shaun Hall Xerox Europe > -----Original Message----- > From: Hall, Shaun > Sent: 02 August 2001 15:36 > To: 'Alan Kent'; w3c-dist-auth@w3.org > Subject: RE: OT Bypassing WebDAV LOCK mechanism (was RFC2518 issue...) > > > Again, not bashing the vendors/implementors as these are > observations and its all IMHO ... > > > -----Original Message----- > > From: Alan Kent [mailto:ajk@mds.rmit.edu.au] > > Sent: 02 August 2001 01:14 > > To: w3c-dist-auth@w3.org > > Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > I would be interested in other implementors feeling on this one. > > Its certainly not true for our system. Its certainly not true > > for Oracle iFS. I am pretty sure its not true for Apache mod_dav > > (its not unreasonable for web site administrators to go to the file > > system directly). I suspect the same holds for IIS. > > FYI: > > Greg/Keith (or whoever wrote it) sums it up nicely. Take a > look at the "Caveats" for mod_dav at > http://www.webdav.org/mod_dav/win32/, > specifically the 3rd > bullet. Off the top of my head, I don't know if this applies > to the Unix version as well. I haven't tested either platform > in this destructive manner. Maybe Greg can shed more light on > the matter. > > As a side note, I did a quick test with IIS on Windows 2000. > Sure enough, when you LOCK an existing file (can't lock > folders) or create an LNR, the file (including LNR as they > are implemented as files) cannot be deleted say via the cmd > line ("In use by another process" kinda msg). Looks good so > far. However, using a utility (SysInternals Process Explorer > at http://www.sysinternals.com/ntw2k/freeware/procexp.shtml), > I could close the handle to the locked file (whilst it was > still locked by IIS) and then delete the file via the cmd > line. I haven't investigated how Process Viewer actually > closes the handle (maybe a call with Win32 CloseHandle()) or > what permissions are needed (I did it all with Admin rights). > > See how easy it was for me to circumvent the *entire* WebDAV > LOCK mechanism (for LNR and "normal" resources) ? > > Okay this is getting a little off topic, but you get my point. > > > > > > > I have probably said enough on this topic. > > Me too :-) > > > > > Alan > > > > Regards > > Shaun Hall > Xerox Europe > From w3c-dist-auth-request@w3.org Mon Aug 6 06:26:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20913 for ; Mon, 6 Aug 2001 06:26:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA28737; Mon, 6 Aug 2001 06:18:30 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 06:18:30 -0400 (EDT) Resent-Message-Id: <200108061018.GAA28737@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA28713 for ; Mon, 6 Aug 2001 06:18:20 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA29171 for ; Mon, 6 Aug 2001 06:18:20 -0400 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 06 Aug 2001 12:17:24 +0200 From: "Stefan Eissing" To: Date: Mon, 6 Aug 2001 12:17:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: GoLive, Host and Destination Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5236 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I stumbled today about different behaviours when it comes to treatment of Host and Destination headers, which I'd like to get your point of view on. GoLive (5.0 tryout) does send a Host header in request, however it omittes the port part. So, if you have a server localhost:8080, GoLive will send a Host header "Host: localhost". However in Destination headers, GoLive uses the correct URLs, e.g. Destination: http://localhost:8080/test.html Now, my Servlet checks these headers on a COPY/MOVE and responds with a 502 (Bad Gateway), as source and destination do not match. I checked with mod_dav: same behaviour: I checked with IIS: works. IIS seems to disregard the host part of the destination URL and performs the MOVE/COPY. Now, you can look at it two ways: a) Well, nobody can move to a destination on a different server, so ignoring the host part in Destination is Ok. b) Non-matching host parts is an error and should be reported as such. What do you think? How is your server handling this? //Stefan PS. I don't know if there is a newer version of GoLive where the host header is fixed. Anyone can verify or comment on that? From w3c-dist-auth-request@w3.org Mon Aug 6 08:12:52 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21860 for ; Mon, 6 Aug 2001 08:12:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA04965; Mon, 6 Aug 2001 08:12:32 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 08:12:32 -0400 (EDT) Resent-Message-Id: <200108061212.IAA04965@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA04945 for ; Mon, 6 Aug 2001 08:12:27 -0400 (EDT) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA06192 for ; Mon, 6 Aug 2001 08:12:27 -0400 Received: from grumman (1Cust134.tnt6.indianapolis.in.da.uu.net [63.57.225.134]) by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id IAA32589 for ; Mon, 6 Aug 2001 08:12:26 -0400 (EDT) From: "Keith Wannamaker" To: Date: Mon, 6 Aug 2001 07:11:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Subject: RE: GoLive, Host and Destination Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5237 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit | Now, you can look at it two ways: | a) Well, nobody can move to a destination on a different server, | so ignoring the host part in Destination is Ok. | b) Non-matching host parts is an error and should be reported as such. | | What do you think? How is your server handling this? Xythos does allow moves and copies to (and from) a different server; the destination header functions independently of the host header. My reading of 2616 says the port in the Host header is required if non-standard. Therefore I would say Adobe's client's Host header is incorrect. Keith From w3c-dist-auth-request@w3.org Mon Aug 6 09:52:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23405 for ; Mon, 6 Aug 2001 09:52:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA10763; Mon, 6 Aug 2001 09:51:30 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 09:51:30 -0400 (EDT) Resent-Message-Id: <200108061351.JAA10763@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA10539 for ; Mon, 6 Aug 2001 09:51:15 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA16808 for ; Mon, 6 Aug 2001 09:51:15 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA20343 for ; Mon, 6 Aug 2001 09:50:37 -0400 Received: from 241.dhcp3.liv.opentext.com(172.17.3.241) by krusty.wl.opentext.com via smap (V2.1) id xmab20124; Mon, 6 Aug 01 09:50:33 -0400 From: "Dylan Barrell" To: Date: Mon, 6 Aug 2001 09:50:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: GoLive, Host and Destination Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5238 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Our server also expects these headers to match. I would also vote that these headers must match if the port is not 80. --Dylan From w3c-dist-auth-request@w3.org Mon Aug 6 12:47:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27378 for ; Mon, 6 Aug 2001 12:47:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA21935; Mon, 6 Aug 2001 12:46:06 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 12:46:06 -0400 (EDT) Resent-Message-Id: <200108061646.MAA21935@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA21915 for ; Mon, 6 Aug 2001 12:46:01 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA06840 for ; Mon, 6 Aug 2001 12:46:01 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA25756 for ; Mon, 6 Aug 2001 09:46:03 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 6 Aug 2001 09:43:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: WebDAV hosting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5239 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added lawrence@pop02.odn.ne.jp to the accept2 list, so future email from this address will go straight through to the list. - Jim -----Original Message----- From: Lawrence LaFerla [mailto:lawrence@pop02.odn.ne.jp] Sent: Friday, August 03, 2001 11:29 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV hosting Hello list, I've looked all over the place trying to find a list of web hosting companies that will allow my (remote) design partner and I to collaboratively design sites using Adobe GoLive's WebDAV uploading/downloading. I have asked several hosting companies and they all say nope, they don't have WebDAV enabled; and most ask why we can't just use FTP. Can anyone recommend any hosting services? Or is WebDAV only for people who own servers?? If you have any info, I would be grateful if you'll respond to: laferla@mac.com Thank you very much, Lawrence LaFerla Nishinomiya, Japan From w3c-dist-auth-request@w3.org Mon Aug 6 12:52:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27476 for ; Mon, 6 Aug 2001 12:52:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA22455; Mon, 6 Aug 2001 12:52:10 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 12:52:10 -0400 (EDT) Resent-Message-Id: <200108061652.MAA22455@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA22342 for ; Mon, 6 Aug 2001 12:52:02 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA07523 for ; Mon, 6 Aug 2001 12:52:02 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA27294; Mon, 6 Aug 2001 09:52:02 -0700 (PDT) From: "Jim Whitehead" To: "Lawrence LaFerla" , "WebDAV" Cc: Date: Mon, 6 Aug 2001 09:49:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: WebDAV hosting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5240 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I've looked all over the place trying to find a list of web hosting > companies that will allow my (remote) design partner and I to > collaboratively design sites using Adobe GoLive's WebDAV > uploading/downloading. I have asked several hosting companies and they all > say nope, they don't have WebDAV enabled; and most ask why we > can't just use FTP. Well, I do know that the ISP spoke.net supports the WebDAV protocol. But, more generally, this raises the issue of how to get the word out to ISPs about DAV. Is there an ISP Conference that most ISPs attend? Or a well-known ISP trade magazine? - Jim From w3c-dist-auth-request@w3.org Mon Aug 6 14:52:46 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29466 for ; Mon, 6 Aug 2001 14:52:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA10575; Mon, 6 Aug 2001 14:52:02 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 14:52:02 -0400 (EDT) Resent-Message-Id: <200108061852.OAA10575@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA10554 for ; Mon, 6 Aug 2001 14:51:50 -0400 (EDT) Received: from relay2.bt.net (relay2.bt.net [194.72.6.62]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA24581 for ; Mon, 6 Aug 2001 14:51:50 -0400 Received: from [217.33.137.44] (helo=beaver) by relay2.bt.net with smtp (Exim 3.15 #1) id 15TpT7-0005bY-00; Mon, 06 Aug 2001 19:51:13 +0100 From: "Lisa Dusseault" To: "Clemm, Geoff" , Date: Mon, 6 Aug 2001 11:51:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103CA9488@SUS-MA1IT01> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5241 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This means that LOCK can return 201, which is important to distingusih between LOCK of an unmapped URL (I can go ahead and put my content) and LOCK of URL that somebody else just created (I should NOT send my content before checking). lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Sunday, August 05, 2001 4:13 PM > To: w3c-dist-auth@w3.org > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > The full proposal I advocate is as follows: > > Delete all references to the term "lock null resource". > > Instead, in the LOCK semantics, add the following: > > "If a LOCK request is applied to an unmapped URL, the server > MUST automatically precede the LOCK request with the creation > of a resource at the request URL. > This automatically created resource has the same behavior as > a resource created by a PUT with a zero length body. > In particular, it is never automatically deleted when it is > UNLOCK'ed. Note that this changes the behavior defined in > RFC-2518, which stated that the resource MUST be automatically > deleted if it is unlocked before it has been explicitly updated > (e.g. by a PUT)." > > I believe that this reference to the old 2518 semantics is sufficient. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > > > "When a new resource is created by a LOCK request against an > > unmapped URI, if an UNLOCK is applied to that resource before it > > has been explicitly updated (e.g. by a PUT or a PROPPATCH), then > > that resource SHOULD NOT be deleted as a side effect of the UNLOCK. > > Note that this changes the behavior defined in RFC-2518, which > > stated that the resource MUST be deleted in this case." > > I support Geoff's wording above over my little one liner. :-) > > This would be in conjuction with Alan Kent's proposals... > > > - LOCK on existing resource stays as is > > - LOCK on unmapped URI [should] create a non-collection resource > > - MKCOL on a LOCKed unmapped URI will fail (pity, but too bad). > > So is this the way we want to go? > > Items of note so far (just to make sure we're comfortable with this): > > - We don't speak about what happens if you violate Geoff's (SHOULD NOT). > > - This doesn't speak about the nature of the non-collection resource > created. Nor do we explicitly mention that this is a change of behavior > from 2518 except through Geoff's words about what happens upon UNLOCK. > > - Presumably we'd only use the "MKCOL on a LOCKed..." wording if somewhere > in the 2518 it says otherwise since this is implicit if we are clear that > we generated an ordinary non-collection resource. > > Comments? Wordings? Additions? > > J. From w3c-dist-auth-request@w3.org Mon Aug 6 15:20:52 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29814 for ; Mon, 6 Aug 2001 15:20:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA15423; Mon, 6 Aug 2001 15:17:10 -0400 (EDT) Resent-Date: Mon, 6 Aug 2001 15:17:10 -0400 (EDT) Resent-Message-Id: <200108061917.PAA15423@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA15328 for ; Mon, 6 Aug 2001 15:16:55 -0400 (EDT) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA28511 for ; Mon, 6 Aug 2001 15:16:55 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA51400 for ; Mon, 6 Aug 2001 14:14:50 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f76JGre48690 for ; Mon, 6 Aug 2001 15:16:53 -0400 To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jim Amsden" Date: Mon, 6 Aug 2001 15:12:17 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 08/06/2001 03:16:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: DeltaV breakout session Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5242 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: Let's meet at 9:00 AM Wedensday morning in the lobby of the Hilton. Depending on the group size, we can probably just squat nearby pretty comfortably. Hope to see many of you there. From w3c-dist-auth-request@w3.org Thu Aug 9 02:50:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16082 for ; Thu, 9 Aug 2001 02:50:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA17568; Thu, 9 Aug 2001 02:39:01 -0400 (EDT) Resent-Date: Thu, 9 Aug 2001 02:39:01 -0400 (EDT) Resent-Message-Id: <200108090639.CAA17568@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA17548 for ; Thu, 9 Aug 2001 02:38:47 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA29287 for ; Thu, 9 Aug 2001 02:38:46 -0400 Received: (qmail 26060 invoked by uid 0); 9 Aug 2001 06:38:24 -0000 Received: from p3ee24606.dip.t-dialin.net (HELO lisa) (62.226.70.6) by mail.gmx.net (mail10) with SMTP; 9 Aug 2001 06:38:24 -0000 From: "Julian Reschke" To: Date: Thu, 9 Aug 2001 08:38:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: Possible bug mod_dav 1.0.2 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5243 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I was doing interop tests and encountered the following problem: a) Set a dead property with no namespace, for instance by: 123 This works, no error is reported. b) A PROPFIND however returns XML formatted like this: /test/UTF8.TXT 123 2001-08-08T12:14:01Z 32 Wed, 08 Aug 2001 12:14:01 GMT "c5077-20-3b712d09" F text/plain HTTP/1.1 200 OK Note the invalid namespace declaration xmlns:ns1="", which is correctly rejected by MSXML and AElfred (Saxon), but sadfully accepted by Xerces [1]. Also note that the prefix isn't actually used in the property, so maybe this can easily be fixed by not creating the namespace declaration at all. [1] From w3c-dist-auth-request@w3.org Thu Aug 9 02:50:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16094 for ; Thu, 9 Aug 2001 02:50:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA17609; Thu, 9 Aug 2001 02:40:00 -0400 (EDT) Resent-Date: Thu, 9 Aug 2001 02:40:00 -0400 (EDT) Resent-Message-Id: <200108090640.CAA17609@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA17583 for ; Thu, 9 Aug 2001 02:39:51 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA29354 for ; Thu, 9 Aug 2001 02:39:50 -0400 Received: (qmail 32533 invoked by uid 0); 9 Aug 2001 06:39:37 -0000 Received: from p3ee24606.dip.t-dialin.net (HELO lisa) (62.226.70.6) by mail.gmx.net (mail01) with SMTP; 9 Aug 2001 06:39:37 -0000 From: "Julian Reschke" To: "WebDAV Working Group" Date: Thu, 9 Aug 2001 08:39:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_01C120AE.D2140410" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5244 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C120AE.D2140410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I've made some minor editorial changes, and added wording which should take care of issues 1) and 2). I'm attaching the draft as XML/HTML/TXT and the diffs from the last version. Regards, Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky > Sent: Monday, June 25, 2001 9:24 PM > To: WebDAV Working Group > Subject: RE: Proposal for marshalling property type information > > > I also like Julian's proposal and would be glad to see it > incorporated into 2518. But there are a few questions related to > live properties that I'm hoping Julian and others would comment on: > > 1. I work on a number of servers that have specialized live > ("computed" in the deltaV sense) properties for workflow tracking. > It seems that we could use the extended PROPFIND to indicate to > clients the datatype of those properties, but Julian only shows an > example where the client has indicated the datatype. Were live > properties expected to obey the same extension rule? If so we might > want to clarify this and add an example. > > 2. Some of my servers implement "type-restricted" live properties > which are essentially dead properties whose values are restricted to > a certain datatype. These servers will reject PROPPATCH requests > that use the wrong datatype whether or not the client has declared a > datatype in the PROPPATCH. Julian's proposal shows an example of a > 422 response when the PROPPATCH-declared datatype doesn't match the > datatype of the value; I would also like to use such a response when > the value's datatype doesn't match the PROPFIND-shown (and enforced) > datatype. How does this strike people? > > dan > -- > Daniel Brotsky, Adobe Systems > tel 408-536-4150, pager 877-704-4062 > 2-way pager email: > ------=_NextPart_000_0010_01C120AE.D2140410 Content-Type: application/octet-stream; name="diffs" Content-Disposition: attachment; filename="diffs" Content-Transfer-Encoding: quoted-printable 19c19 < --- > 90,91c90 < instance of dates). Servers that support searching can also take = advantage < of known data types when doing comparisons and sorting. --- > instance of dates). 115c114 < WebDAV and for properties of type --- > WebDAV and related standards and = properties of type 122,132d120 < < Note that a particular property can be typed for a number of reasons: < < The property is a live property with server-defined semantics = and < value space. < The property may have been set using a non-WebDAV protocol that = the < server understands in addition to WebDAV. < The type may have been specified in an extended PROPPATCH = method < as defined in . < =20 < 135c123 <
--- >
169c157 < --- > 216c204 < --- > 234c222 < Does not parse as = xs:boolean --- > Does not parse as = xsd:boolean 243,292d230 < < Note that similar error conditions can occur in the standard WebDAV = protocol < even though no data type was specified: for instance, when a client = tries to set < a live property for which only a certain value space is allowed. < <
<=20 <
<
< >>Request < < < < t < < < < ]]>
<
< >>Response < < < http://www.foo.com/bar.html < < < HTTP/1.1 200 OK < < < < ]]>
< < In this case the request succeeded, but the server did not know how = to < handle the data type "Z:custom". Therefore no data type information = was < returned in the response body. < 304c242 < The property's data type MUST not be defined in --- > The property's data type MUST not defined in ------=_NextPart_000_0010_01C120AE.D2140410 Content-Type: application/x-gzip; name="draft-reschke-webdav-property-datatypes-00.tar.gz" Content-Disposition: attachment; filename="draft-reschke-webdav-property-datatypes-00.tar.gz" Content-Transfer-Encoding: base64 H4sIAOQicTsAA+xc7XPbNtLvV2em/wOOH2p7zqIsOc6LKytWbad2a9m+WGkuvbm5oUhIQk2RKgHa UW6e//3ZXQAkSMm2nPRy99wTdVJLIF4W+/LbxQJglAUj1ci4DCfXvHHLh1Fw05hl6Yxnat6IAhWo +YzLxva2/2Eaf/NJn+3W9vazp0+/2YbP82f0F0pa9Ht7e7e187z9zfbznZ2n7Xar1YLn7e1Wq/0N 2/604R73yaUKMsa++S3j99b7mYvkS9DzhT+dVyDWhlTzmMsJ54qhuPfXFf+gmh9kvM4mGR/tr2ej sP2s/dKHIrXOXnW/fdL509HF4eD95TGDZ+zq/dXguM88Wy9SkYeVXuFDlYb73pxL71VRJOdT6Fc6 xVgqZtm+N8rjuL3dfuaxKA3Pgynf96KVlRQHXeuMsjRR8I3BZ62jhIp598jWYqM0Y+/48Kj3CzN9 CC47TV0Nmq+tdYJcTaCWSIQSQQxk/uSz177HZJ4lRNEbTYvHkFpd9FMeiyCBasw+NJ2l2ThIxMdA iTRhwXCY8Zt9b5xxngznCqbfLb+zH6fDk07TbWEpiiKYvzSTsp+1ziwF/Y3rxWsdqaBT1b0K4o/T IEngZyAlZ63ddqdpnlXb6O5Coebdfs6hAc86TfrZyfgYCTl/12mar50wjXj36YvW7kuohN8XO2MM auWJyubdH3kGRMyxqi6o1AZqm8U01nCyfBqIuPsbMdQ3Yj8oueRHvNPUddY0d5ole+gXic+M0gH9 4GwKGjHZ93r5GAzeY3MegKq1AYU81iRtbjSg5W2aXY+zNJ913x3/gAryDgpEMmY/YmGnWT5njYYz i04wRA6HqttBvg4mQjI546EYiVDLHeyJJ5FkasKt8h0JaCOGueIR6xHFONJlloK9pDFYDfv2icxn szRTzOg4VoDOrOqzmyDOgR9lIx7zKU+UZEHGoXnERyKB7qGvGGw7jIV+mERM8uyGZ5bMORGG9sHS EQuKEbaorkq/fSJQh/JQuTOYcqA6YpdvLi5fn54f4TAZV2Ajll4OJgTmNiUe+A6/mkqLCv8UfEA+ wegKuQe2n+NMGHzPk1hMBbAJJhrzANRYAi9ZmE71XGFYJMrpqcJRnMEvMFXoHn9uaOI32a2RLQmU BYp1OGASA3cw5mrfQ/1S6d7tTtiIoN8GKtXB7Y4Pxul1l5WCTkL77ha7nYhwwqbBnA05+y0lCQzn RDTRA3yTMhhzdivUBDBl+BsHvn77xIOvMoQJAK7AnB4mByDxd5C/MgS8Ml3tl/1076tvCPa10Rjd BR6GuURmSS0MkLa2hRq/QMGCLJyIG5gdMO/tm7M9mEOV6IlSs71mMwYCpK8HbfZ0I9m8zIexCJsV Cpte9/Ft7Dxq8FOoG00OaWsWZopeomndBP6Yiigi+Mf/OhK4iNpIPmHfO08VaXAQs8M0uQGlQ/aQ g6OuBsCkaz5HDoGJe/23VwNvS/9l5xf0/c3xX96evjk+wu9XJ72zs+KLqQHdwO+Lt2emCn4rGx9e 9PvH50e6fb/33tOG6V1cDk4vzntnHhiaNhzop7AdlBEo0hDNEPB8BsaJwgLr4lo/ImzW+eCK7M3r Q4jCXiIs+sgyVZkl9DJlXoE/Bm48MPsRgomxxL/2z+wj+A3KISLk2Qj8LAoF4CUApxvmMUReJdKM yOOCH0hCXow8EuM8Q7l0oAlqYLfzp78dHvUGvb+h2IDkEIQIvcc8GYM1QTSTgL8Gfd3TyP73v3dB 7qYtdlv2uGRW5YwQdyQwCKlyII9qecXsiJeEsTgxYKbVnFbbb7XQgBa5u9t6cQd3kW8ZBzEBVGiN wx7A/YGzQ7ibpQkBHhBmGHmThsEQ+TgveUxggyRjXCJnQai/MWuNt7e31q7QATZh1CsawiOEfg0T xhhFoEzIK4DvIm3jH4LpDOLEQteqLg6oovpA/0h8YN4Huedhh6AUKFTLSmhXEPY9djVDixQhR5We 29YhhFKgtygCxCcPWaOp3GNX5IhAiNJjG1X+/vWKHPomg6gtNaIBOjm4uiAmlinjIXQcGIkMsRdJ B0pwfBzIGhB4VhALPHNaoU1hVewsEiNQe9SDYkYW/SeB/CQZNKwF/OHCEHdJI4bZ8ezxQjHa2zQq 312GnKcQ7qVRTmUFXjK2JEAa5iIG8MSmEwobIGC1ckaQuAH9Js2mSawaRQH5ETldN5BqYGRCBlvG /z6rmmMvhq7y8aSIk6YQNxa9oJIY3NHMqsRjW0wo6/5JTbgUWTCMCYxnGIlAV7oqAogMAwRCU3A7 4dBhCh4YGtjwC6QNRdxOHSexLnW4RvW1pF0iEL90LKbDP6yhwz/SafOdQAssAUJrrCTGSYouA6Xj BG5bIBzlzMlORQXX8CO6CQCsxhQ4CuqRSJqmYB1zHe9Y0mqQd6EJT+F/GRhMEm3pppIrhQ0TfutI iLhqNNDlKMkRFjfEFVYPOgEIUuiKIi0cjJjjs56RK3VYnQf2Z6NQtyOYcDpTEIh+hPhTpRlO2UgH KMR6pGsmTgAPJynahAfaNWizxq5xQSI3fXZlVItcpFUtySmqgqZIGsHYUvquk/Q2KedsFCdKqSW4 iiATEmM4ivWhYyhf0WYvgKgbAbzXpJr+HestbKO6ip4bQoyMADcUzYOmZwqnwJZJEMfa/ED5rRXh qiNxA4ctNCxcNUJTcHcovDkDTMqh9ZxQWAoEQLIJGjcW1zrQGQNTQWfTFBYLGMVmmuM+c7wIu4SY gLX3WJEXIHSse5M2epPCjwSomuSSaeiC8Qj4eoLYB4UNAdYeBlJoP4PSjckaFhQU9Kd0Lz6r4dDR UqUm4zZxAgyWS81nx1ExDxt5YNrpFJ8gYc7sS7f0OI+0dpo43Wy5+oci+R2ko0MQGsDAl4lszNBI CThdWrxFejoL/EVnoGDgYh0p2YbV0h2ocKeoNrdsPKb9Is37EZP16lEZCOcmFcDiJOEhLtsg0gL7 GKaSXPJyzJFgHnEEviyeG50g+SNfBIIkAgVGcYRgNV0wUE7ey2fA7jJW3rK6XteFJFUMl3YQzGi/ HsNiyYFOhyfYhTHbOyNTZsMDpwdERBgZm2Nghz43Gde5VaAqOgoyER0koxGn06FIipi2kCvaKUCz VVNUFBzD6EpNT5Au4xrnuon2HYWAZY0gWLhxjT9L1xwWlSgeoBmDZeTTIXQJNGY8QATdI2XD5Sij NOm+J+fTYRoTIlJ+sTtw3a9APXYFMDfrfGJNw4pCwvwgXg8JofVSVTtumoivZ0G5klr/yNtJAN0P ufaVxvyB9DRplJBsskg4eWMHzIonTyKASIwCKXy0bgvVT7dfHJ7Urja0jt+0qQU2xcV1PuiyNzg8 MQki3VHgqmFN+frHg5OLo38UDWl9ZGnoUC6g6yDjve7rECKJsQnv65R4QGcIIeKSEQudOR1Vwym7 1MOI3rioEmVR8yIdXRPebtkQzTEEHYovRhMSeg7ROoq4Iqqt/rAz8h5KR7WLYZ5PKwSL0FuUZtIJ Payv14gkOiAe7dY4RW/LCQhBLCFYhfaxRf/YViukziAYALBulW3cJ0+Lxr4O9ivsAP6nksIDQEWh DAbCCgTDJs0gDT46UNbzFtIJ101WUrjYSGYXx+mtDndHgYhpOibjhbiLP3X/2NcYLBTjJa7hcySU U6GYWbFIwrkvWbGbeRnAF0mEyxkozkN0FqM8hp6U0U9CLxMWmsyaBh5iM9JESUKlrKitVjn6libL lVM7O5itnAFk6c7SaM42tOJN0fmYQBMmasg1udqA9d+eDU6vBr3B2ytcHKoc47KIW2QK2Hex+n6a x0rop9+N1ffFWDTQZsGbRYM81itVEwcVjKmansnKdED9g+kwNhsK3e4bLb9O03mwLBUElUtjbw6D zJ+oacxOBoPLZstvUYWTVKo9hr5/lKY+eBYqPdQRaGMAnN5jeuNrGlcenVFuaY99gA/OEGHxaM8K IZ/RDgNlnvaOTO7JJh91KUhy/xGBVr3xw21rTX6tt4DJNgnwgyySzY87L/3dbc9uYMBcpLsfZObm 7tJ0ft3LOOXeo0It911A6Y5gqcI7zbKe01+z2iH+Lga0D0tO1pN2bsrubjXRyriKnlidYO3t56yP Wt24IrX+PHVw7OP/ti5Yw64oBG4Dd51+jAUVloZipDp1LUKOVDTJ6MKDGgX+o644VlmJyV1Hjtvs 4mfSKv3E3WhapALLqnPEEkd89ymgDhFMyo1WplsPYLWFaK+csFd4CqnjBR2jWW8CDzlwBQMOE6ml qV5GyXw4FQqXfEsXHncs8O+HZHSVbtD2FY7//Sb4+XCsvkLxw1D8nw+NK2Pg03abvU2gIiUpMKY+ htWlmi9FRXcqeitwRmBxZKNhDFNpzVCqlIuabpsF1fpDoZYxF2srEb3BrSEPA7vZUWRZ9MLF09t4 OCGzWxbEor7GMst+u6zRq6q7sggSlmm42OBZBq3CNNELZ53zTMMwz2wkbrWI1RbkSAi/oZQ9pVCT 1IHy20CWq+q9yoaoSY0Hds0GToZLvYpUenLVlAO21YlJykJBOygOROImGZw104qp4cVQvhLJI40Z X0xR4bxIrZDv4OKirz7mfh/zhRzGr3thDsHF9Ku7+NdH7v9FvuZLx9v3OAECIfBHkd6jdILoCJAe MQf3ydgE/umdQtxmjHmxi6qxqjQE2hwF/uE2aAWaa3CmNzHM9mot+UIJkbsA9VGpSzpUZzKXJTOK J8CQIudaHr2rTs2lu5rSp62qJIZwAVwEtxmpUYoOQW8iFt4NBgIqVkyEl2PT+SfcrS2OSVDO3tk/ YBul+ybxJlpnoBEMLwUsfrhe+UR8FIDGlL1v3p0iX5d1IlARaNv4jnyls/mhe3TowvMf5Q5XEANK RXN2y+PY5vI366nq1XJhVo5NOlL0B3pEUo4v5xCBB1ENNz8V86rgAwXl+S4UQdN55uKWAzRlD/YX kvdf55gexeAvvfj94k7MKVqiNV3iuO249oxV2z64rm4tD5QWQ6VH+85/TaqKTlqZs2KY97+VZbqp dmLIU1nOvcrBIXtsBocO04zOyi31LXanv5rICie40+N4FyASu7LHm2pLscqGUnliwGenSh+EKenH XpY7uWI73EwBkdarix2Pz8qFbaWK36C1kcb6VdzGp/l7PKejxFDEsFJHLCCPFyycLl44LFdsWwlz vk7vp5kDU9WrAFtQMaMWOFc8Q0VRhj1mh4yLi8N0gyPi9hT8bjwv1qLSPdmkZYt9lVvY9pAsxWd6 EWjvGuiUpdvBUrkRbbSN/PBm18YMT0SmuQQSMUGqnbBWQVoL4+mKIHHHrHRa71CyHCyscJ211f+h mQiyO7jFGMCeDqvKxGyqYTV92oeIL7eGibL7ydgIRngSE9bkW3qEsv6Q4zk2e8Ia+yoNpHFqD5eV J13KU6i0V+/uZwIahIrIM+qfZ3i4cNNnF0B/ITc9HbI7cy5wGT8xeHRtqJxMYYHDeRmVbNBxNJNF 0ZGtRMmZE2U6G16c7awymBIZ9qgQsWfIJwEqQkbzyhN9Js5SgJ3ReCgqEdNJlGEKqwRbsZzEZk3m 9mTeQzLngs6fRHhy/B5pb7FyP5uO/1TPJNa39E/SWzywTBsLtA9/K+IYjNvsDSxsMdc2lUv7As5r KcBT7GcYhNflRZ/6sgVUq8inuNu5Dx3wxZ17rRb2ktsdSMbMwV+cbypBi8ozv3fiqt3qBzYLUCr8 Rx2J2rgaQ1c9ldw7761M5D1YS/2ElX62QNXQEjWRqmxt71nZtuWZJbZhJDHmCR5Tx4tCYI56RUv9 GDjGY/9gveZQBLhVueJ8D9PZPBPjiSpmOaAzHUW+1FwYAL6zY7DxNFv9eDesgzidysQz16TGnzuI DnyKCzlrHVRbPTxdM+HAX7rpVy2yR3vWzQ2Wdd3EXvLR10Dt/UusxH7mc7zgF8n17s/F7R1CEn0d AOoQ4J5am3ujz9iREzoDc4yda6MLd0bXr/z14sLo+g9ZEIF018sLo+tXYaoUsw+wi8q9z5Mgu8EE 8ttEIBZRLr92MdS5FVpeBLVXP1s7u9usH0jps94NHigrrn3aGoewqslENOZLnvV7bLvd2nlRPHLu aHZmE1C+boP9ucWetZ6zpy932c6LZ0+hCj3AW2B0O7Nhr2mWFzSdy5nuxcz1Pp56Xtf3MtdbL18+ X4eqJqcIiy4edH/U1oGxLvyC0ms+R5F1zd9O0xZgi/Kil7XqU3OcuFgeMaxxXV72sNdEjCIg6tNR XkyygwcE46V+bPrJKIIsMv6uZ/CZuTlS9pWCb9fpjTCYCYWohTcaNdoUV7ZK/+a0NqefjUvWJ0or V7qAhNPjwWv34oq5DIHHk1OT1TGdjnOAqxhHoX6Ks0sQ4M/SLFAmGTObZBjNJSARmt+Qj0WSlH5G ZMVwe2RpNvVRLtGq9+K++z1P1feYj9HftpwSvOlWLbUX5qqldGNuSZEdcaEbfZFuWdmyIYtrdvaB JbH33pYUpzXtM3sFT/8qruM87hKe7RJhCcHLQKPJJzmhCc6x2I4yB9ZCu74qNAYTdnj/woFdR2Wp lxjxqwgZitu2iYkc9XH7rHLZx7k/6V6eBKeAm1GnEMwzA3aHl+s6mAFbfrqub1gv1IK5FrUIsHW9 ZoHo3eUAj6f4vfoVUycbMXjTBAB50QRxNvDlBvgDsGxbp9gq7qB7jPlTvRYFBLrOZ+wMFkc53u3Y gGE2Wcvfvg/jBzWMn7sAPxBTRmUL2D7gH9Bl4qoPw5tzriSAAr8b4A2gqiF0d6CK1pg2uR9jFyj+ yaX4Mkhj4ZL8E+6B6tIFovsizFIJMPYgmb9BL7PgYGobfAKZhz7ru5ReQWgx5Nm40Q//ksOKxiWa 6rKFGgsTKD0p6v1pDBiY0iKLHYLOB+OUhIGyYceAhnRv7JQoUtDwwVmHUzkNfz/IRejzKH/kfI/d yfaDuBoqHN+gfsbLwoSrPGFaMnOp+FQ+SCbYvT/Fvg54IJUv82RV8dTHLl5m8W7n0OtCJAVu5B34 Fly+UXiN147y6ePClv7pAGxwiI4ozfQ+NqZJclwYX4UCgWBJuLL7dBcEF06SNE7Hc3b1ew7Y5daj N1k4AQ/9ZvbVFv1e8WoLpt9tgcFP+W6L4k0Wb6/cl1gsxkR/Zjokau/usPaz1o4TEo2CkBa+bqUX bPflSximfFbETkpMh3F5UZ/K4GGeiW4F8kJdAcuRIIe1yyMt7zUfZsCduX0JBsKjeQlGAeoLYE0i NmCt8XdVrMYLufdiNUC0vuHcaDWXQXT9zlbLvQB8HzafACa4VjWYgB7JtAIdJzwBJbvCbT/z8AHU gJVLMsyz8eRBO5uogzAdy1AAGvhB6OfXj4SEo4pv4Rzj45Lyo+BGREwXL9B8AU46fhixqA+f+jhI qcknIHW/hlyg7hUv2M8zcFrMPlmgFW9IbqKNwyoXFOcieZjuKXV5MM0/TtNPoPi8QjHun8YynVT0 4jwNJsx5tED1WYqbMkcYRKUzCp0OTfgMTx+cAHb/j7L7gxh7+wrD/59guB/Ml7yGaFUEvmo9AoHb KyNweyUEdm/N3gfAlz77pYJhIqui72WQx1CF6QcLNvZzIIAL7JLeHoU3XfU7Qk44pot1AoZd4WG6 B+0NB/J/8Wmcg+uZK8wVMaNXQ7lJCgshdy49WEdfs+LJ3dEzTQKwLtZR6A/9B6kPsOvpJ8TTX5Hi K1Lom3irIMW6SbsvTZzSDjYzy2XcqkU5L3/3RqNh3hh1Hza8d+3pxzSGlZdrTe99ZgoXDKmmnauv qt5NhOITHlQGOvZZWf5ZY1UQ4nUgPlYW1j2f6bLPGqMSzx4CFtcyyj4zhZ81SiXw/Ak3IyqofeQz U/iYUdxkr12COPnel0W+9/7UUiVphMq6RLmdX7Jb7iiYbQR4Ogrh77/7zZv/GZ/VX61JR3M+aYz7 3//6fKfdel68/7W9/Rzf/9p+tvP1/a9f4kPvf2U3+vWI+17L3/YYN8mvfU/ItPHixe7LRst71e3Q aULzgrXFQBKNuPkB63hQFeC0+7g3r3boUKl+/6xHR7ZCKb3uk96Tfz5Zw9+NiIdmgbWH7zrgT/7n SW9vkgLxS6vQ3Tnc56B6+DqrG/5gxR8ujv63vW/rbuNI0pxX4Kz/QzasaZC9uBCgrjSJFk1RNj0S qSWpdXt09AACRRIjEMCgQEm02/9Fb/s3NyPyfqsLqkDZ0yifVhN1iYyMjMyMjIyM7xd4aUDtkvkO +Zbp6Hc4hFzSYal52afT/t0OuY7GH6PFaNBvkP6cjpsNEvcncRMGrEvt9Xj0a7RDOtuzz99R6j92 dNrbeLkvP4aX4Sbw1LyOYOdWv52Dj8qsfxU1qdHX/9DE4JIdls8EmekmVpQz87DsUrezlLpdcqlv oNAbuggaTZrj6JKKsxvdsBL43TmTMt6m758eOl9siy/M9qNvn+9//wrft6oAj160oC8wFRUfXuLl 1nrLW2teVa3ytqbBuaYrqsiL6YwWSVcHfLvfZmkLWWrRFQo4uRVHLkOfuNJNMDyMPfD2QQ+/g5Rm 0jh6xhiiev6hm4Wdi+l4mI+ZXN2Us0NtDI2Zx3jdAzMeweDIqGvOs2fe/tLteocMdTuJca48qDF4 u5KZacpj9flNNBxBjrfRZEF+U8GvrcmU3xuO4tm4f7cDUvmdfgLLvDsY8dtsmoDzEnSywFOLg3E/ ptML/7ZGeZ3TzrNXo9PSIBqPZyydn/wNETT4m65yPo2GsFzapo+YAOh09qhGsHp7NR7/sruY0/8N ycUVinSvxocg+d4AHA3zGu9T6reHOv2bMk8nrll/IhinulPrfaH/fqG1pPdpJekbF/O2+RrvgjU4 c7MYwj9zD2ustR3W/BXt7fZZsvbat9TAbS2mgxo5eLV/drZXw/4FvIri+Y0v5yfA5wUY6jojbWwL 0SS8uMeP/z3cHB2rOTpK0oLbbfhcVo31qpqUB46Rtd5xhHHMZt7tL4y1vLQwZ7tIxv7FlXMuYkfH 54enx4fn5MXp/svzJTlSKcyLsqMHrZMKpGfJbshD9hbj+yVrw3KpQ0R7p8zqVA7oKvBqOr/bMZg8 UrHC/fGSHBdl8/DzbEQlvEPEAhYq3y2BGdHhcJwYjj7ag5Y+dOCcUEu3qvnoQ6lRc7zTY+dRZBzr 6+hmSsffTm931sOk++d21nVaIgvujBbNF6BchMfS4uv4T6UymqBjAIIgsXnAnYRxrX16E7O2ykzi ZyIz8hb8Al8TXeVhzm5sZySKVM1SWfCUyD2ugrV45Ip4mRxOqKUWReCBYvXpxx8gORZlaANiozYb GDwKwWM8LyH8NHKaxy38UsXXsOxy7BnmrmJZhaXXy8NWP/bVoRWsGHZb7Xt2RJ2dSb/pfx7d3N6w hJOfmfOEkQf2eTJWdvJ22ICzFOP+AP6iH08v4ukYA40u7ng1NB5ZSr7F6CbijGGDjyb9GSgQneQX GLIEYZAOzzFRjkPaHSMwCaBE+v5gtIiQHi1PpOajcpxg8jEc1lmu3CtweNZaDLlhpmlgRPB0Ia3v 4HaOBwbt4kVuUYx9xsTzDDFCTH3asnQULS5xYQp/tDujYVNEL8WtBZ16e9nfhekxkV2ro5xd94fT T+QFJpee4kn9ZRiPkUyLLalTXgiwSJvV4g1jySMcyCDw2hjJFAE6MMigYQg4G4ETX44W6tHGwSZG +clueDYdUPbuyAZMC5stsk9LO4VXY5iJ8fB/i/vjWDH7XNCSfFngGcWwM8qDzigDOUM7X40NAHIq CzajMGqGUOElADP6S6NlOGAZSVwUxslgfUt0rUIQGVW7y68cHKPvIGMIdcIaUY6u5866C9aVaNbD GBOBwd9eL9H+gEu0Pt/zE/RwTD3HdqKqyY8Xx2xwBQq3Y5YdnGp/jf8hLVP2/YXFJT+a0erg4dd+ 74scjNBU8gCjKHmGaNGKdW1aOlRAOoXtWm/bpuBPXO6n5eZ/fWiTS0okm87gQxAY/cemmpYNMwvl LlB2BJiU1C0L1W2g6gi1rJQ/6RzQ/vEorQ20jBgZCEITPEpuAiMJQzrJx7XeY4fHhFO86RSf1HpP PF0h7VBdOuGntd5Th7B78C2d0LNa75lbZ24Bpn8OgfedLV8VnZNjYWJqQ7fW+382rVP5MEyAbUTL r5mdU4/JPgu/qDIYutDXA3WAjn3/Eha9ygyGxTUajxad9u24V63+8SfYrz2Lweykz2T2nNNSzR2a ciiJKjXO/GRaM0qq3SsHqaskoK78OF1S7BKjix/DXPb0Yq33jpN6z2xcXF4kSbErpVgYCayaCQiM sVSF7Cy0YHB0pkB+oXcTc7bgZ+GqPPRUZXn4r2oA/ctoMzzTzNtsiXgq3lyUStbmeiTrmAdarLoC ZLFqycBi1RJwxRJhxWTDsRMMrNESzyLQ5qHvYtP48ceqJcKPVVeNPlZug40CLbYc9hgfFNbz6rLz qlh/afOqufxKmk27YjYthuNWLQfGrWqiuCWPiV05hZWF71YtEd6tWjK6W7VscLdqErZbuuS3UfLl oL5VywV9q5aN+VYtE/KtujTi23qkLDhSCj+TNlKG3ExJY+a2GjNLQc+rlgOeVy0LO69KiG4xdYMW k/EVGExdNJhyQOxVCyPsJY9U23KOKAt7r1oC9F4ZyHvV4sB7RdvZweer5oTnS287NsuUAdxXLQu3 r1oYtq+qUPtWuKJMAP6rmrh/6c3AltflIAJWCwACpnPKFsmlQAVC94AdFr6fAttHMORXdsej4iCB ItRXwwikZNlmuk1/OZBApJUDI9AuvghIIBKyMOUSdmvMADgeW2TchAv3dCSj6I4Vw//aJlraJnrI N8s0m0i+57ZU8jYaFJxkOD2UrttiuIzVEmEZq8VQGavLgzJW82EyFpqpW9WyoBur5SE3VpcDbkye BB4aju3yIB2rJSI6VssCdKxmxHMUjvfrbkhoan9bGwjSt7cpQWgJ+ALKhf+p/PY97uknydgu8NzJ ZA83/anW9Sd6pvUqMkFlkYLswmu3VP5069sM6dONL7JleFch3aw2VOf0KG9VRTP2G+6nZTyHLxDb EV7Wcp/b9Nt2Afymxor2mhK1vl/jqIXMwK/pRTDXfqH2D6fa/9M1vujIrgbAbAB3E3Lv8zYSb7oa BDJytUg1fhadYrt0Xq3RdFgOTVbyfKFY8nlV/7DtY5M/sCXDb1sjoaaNoZFPLjNLRIKslgkEKWzc pPFbRREFxm83iGg9dv/pxu7Fetz+HzGSLjlkhnAhw4OoVXcN6xFeS4KItEZZ60uP0q10kJY7TmVh SFZzQUimLTm60kdWJrxktXx0yWpxcEnlcQlORir4NHExsWzs6b/yxPV1piEJqbeehL5eI/4PmMD+ KDb/dobpJBcaZbU0MMpqGhalXA2sfd7L+rzF4QRtdko8m5Dk036kggFKwvKs5oXyTNuoKgbiiSLK iOEZ2sLKBOK5wr1QZCo3DKi20ZTmQNVPpwRsHutwSh4jJoABuhobpigCqD1t2dMDu2thgdovWDON MQnoBLVbwPcf3oTIJcn79Xb8scwNdd+vMWiICihQXpr7BrHJZHGydBLs24CFW8TouR+b55Hm5ywH RrRaGopotQwQ0WpJGKLVfBCiqz8Ssrb0Clh64oinbuklnvBMMvUeayfPSkJxrZYH4lotF8O1Wg6E a7U4gmuy8+2x3O8vC9u1Wh60a7UkZNdqCcCu1bJwXaslwrpWc6C6pusBm96K471WS4J7rZaD9lrN Bfaq7RauJ42lJg1xit88UJV+iD9p7nii3ARh3NwVGhMe6F1gJYC8u46qLKhCIl+DrkK+dA1JKvM0 qDLLoRhjexcHMQYyYQzjteYU1ByRoMOwWGV+jiR9eSb0JRWqed1IRVNZyDQo1hzhyYKSmMtiK3eb QUnrdsuRSEvPNgMNqieYEYm0mJyUXKgVSXsHr5bITLaYzkRGLUZdZO4wE28wtngSWfNbK61dU83v Djx4rcexxBvkrIUT+BfI58hVrVKzE8/Byq014okbW6MYgApv6d0mHemjGFBS2pfUwMa/EJMYs2Yu j5Te72EYPqZ6/f7gzZfOw4bma6tAQjYoxriJsOBfAA9c5kCsqMbLIHDAquy9o//mFLQPaVfKPgDf iw1w1yDnXPo2TR8srqQp8cFqPcTfbZCfAmRMnFlJoBi6ba1n4+c2COLq+nnwg8hKXmxQ2loP0Wsb 5LAlz5n5Up9ydKxEbLJUvc4EBZ0N+FlX2Z+3D77QJ4Z6iuypoKFPl9XQs46WOSS7hrr4ogFVkJCl tZ5AOW0QBEf1t60fFVQSZ9iiVNfhhQZ5EaBiY3TK7128T9QOAAdtBPUtCJgpySYCctIS5LcNcnzv Smhi3KYg2jpKd9axxsS7L7ARs7S+dbVjPtn1zYOhqBJQZUVqpGoD3zcIYkP629oLd+iOkw6OIqoR oi82yP5XbOKup4lNyEy3hbtltrBwBZjL+XBLM6S9Bvml1fgiwfBgrG58Qcw6EGfjC0OWA9sCxcog 4KD/l2lmUGaZmbEU3KAuVzQnKLngeP3MK11lx6/t5cz2skyuiAm9rdSKtsnMOXz2LAFOxBbTlpRA T6It9H66HY/6Ew3jw8nTq72soDfIDzcXPya9etYf/0qHMcjaTQUSkc6jLs/mGP7m9S1VVOwexz+T h087j54lvf0DjpN3bl5hq9Eveoev6Zi480Xvu87A/F8ohxaH/niuatoa0qk16anVtDafbXtpu+4S mbuEljEUOkUoX6jqHDNRmPYlDE4lpNvnics9BVRt3A/cf5/3J/GYb6Zj3ieRG4p+CZ4GzBIB+wzx NUaryREWky/w3CO0rUcfcWmBWdF5vABPPg+ua0CpgPc/UdMBEmCNIYCcloW5k9hF2cUtlAk6n2X6 COZK5zzN5tGsP4eQS8Zdg8wgDTqyJpImwKVQO4aYHefT9RRyZM/FYeQGbtDARhLtKvTNgUhMAb7O DyM6P0pSMouZjFToX0w/onh4O00QMYFHM4Abtj/vX837s2uev28wvh1GijfMWDWGTZ5rVovYK0Jj q8hI9r+Io/GlJAeS4cFymKlLZl+gK3dYn2I5sH8IG0Y3tC78dLLNv+JvrkA/ZGpPRwdFg6onOhhs rOQXfR5EM0yeOcFoWbn1zDcsMR0IM+TZIpWTk9FOLCEKu0RqIJlycDqg9sWcx2XKKsVW3hlJVRI6 k9T5aRmWEu5CBFJyZBUEQOE5W0ASvLNEoLp0nFOdYczXk7GOhHI4uQLdTO2TAC2C2A2wj3gz4mAD VIUw5xBTN1Al+nQWofcQFIbtHGLLSzbm0cfpB+Ue9LXaCLf4cYORzuKskjEdQuP8Q8e1GUgD4TJ9 lDrEE4wwskb2Hjw/L/ms7Z+Ro7Maz+iEroofD4mE3To7OTg6PP+F7B+/MB8cHv9wdHx4eHp0/IOk db5/9h/k5cnpwSF5cXRGR/Wj12cEEvj+vH96un98fnR4Rs3bf7w5PTw7Iyen5Oj1m1dHhy8alOrB q7cvKCny/dtzSe745Jy8Onp9dH5Iyz6hLPwiCP1Cedk/R4benh2Sk5ecN1r2631I+Et+PDw9PDom Px+9emXQo+8Ay4dI7fTohx/PkRP4xbnRmAXCrw9PD36kP/e/P3p1RAs+OZX0Xh6dH0NNXgIB8mb/ 9Pzo4O2r/VPy5u3pm5OzQ9GMYJwNYJN8HA2vtOnH27zMXr5lIByig4JzOULnMp0AJgMRLMXResZ3 RoJHkVAGLlvt0PZmXLUZ/B9G5fW+Nhzuv9yVA/+ZrsuWKyMZ//lR98mjRxL/mf4L+M+dh2v853u5 AB7dC7pIsl4/yfXXN1ULayrnpdYm31RdqL3HDcSoSqXCYQmf4usdqN83Vd97KQB6zkfZewqU6IHb 44xkB9oLgeshmawAe7zUwqB6jPdlQPUwZz874YpElkLVUxVAGhxWL6FyuYH1mFRLANZDQgiuR8iS yHpIwoOuR7Ig67VqUtOWAdTDT7Nj47U8hS0DhxcsVgO5a+ldKCOuHR828FMb0o6Ty7G+9i6wgYyA sdM5LAhix/RoSjLi2PmB7JBIcSw72TkgkfRSeHbfsNgxlaKESyoPjF0Ix45JinJTDMoOyfiA6t51 3mfHqWNUdKw6C6ouCWruXfe9JpilUebYrPdNlU/MztzHZ9fUyfXdG9gQ7bz/pvq/ApN7yixqz8rG lJwfzA5l46CbcXKdVggdhrQy/ke2kVK3ZebDz/y9RukhUtpuhfJFZ6f0CCk9bLknTvVUilkoPeaU Oqlp2rJS6iYmDMrC0xNOabtAtgdpqxlZH0j+RnuKlB55RK0d7s1Ct7PFKXXCBzqz8ccpAVJy0jGU LJS6SOlJK1NschJ3HdZNnra8Iap55N5h3eRZS5+Fc7cbUmLdpLPV8kfVZafaeSz1SQV+LcfTE0nJ 3hVbnlJoKyErpadicljmv3ImlO4qJhQ6/PtHf81ALQj9hXTKAP9iVlk++C8ZMahb3IVRuJhhl47D xcus7KbAb/W8zOXH1TLsVh+yloxt0MWRB+XKwLhi1mkJOFdIqChwEhLR0a6WxrpCSgI2iZAw3hUG oPlhq5iK5ASu8iJX8TUAlXxu7CrW9XIAJgRaQS5kloGwMpqBLzqWBrH6ukPw9iqG4G7LMJvDa+HM IFGiMxRFieI9SuJEcdbKQIESXaw4DBRSYlBQBYCgkIoAg9LQoPJjQbG+koAHlYAGxQVcAtiTcIPk hnsy8J4YFacOSyA+Man4UZ+8mE9e0Cekkgr8lAL7xJo6AP1UxMwrd6x5uIqxhq6s/Qtru2sXgVli bV0C0BJTv4xQSz6sJeYSknn6CQbw5kBNUphJbLzKj5sk3FIlgCJJf11hWCTu/i+IjIRUikIjIRFs FgfkKB/EkZg2S0AwYqPMkhhGVK5s2lRARkvBGNmmPO+Q0oBPQB0yMIdExy4MKYRkNNXLDyrEWSkF M4jTmrK5uhBCkPAR6CBBAfL5AYIEcS0zTzpGkFl6EXwgUbwJcSL2PB9mnu7KmdIerWJKe9hK9PBy WRbDwZH6XwoSDlJKw8JJBMNhQ5iYZ/Oh4fiwcNjs5sfDYYNzKwusDV+ppkLbpADbiJ36bOA2AWgb IeQwvI3mASmGXiPNFJH+emn8GrHUd5KRZkOwwc8TUGyo3uxq6cx6NnoN607p+xxccqTX45kUxY3k VNDiHSeVonjgzwNoP9VzAaqCd1MSQ2uRKUvl+fN8nyHXn/NVtoSEPfXdLuZz1m7Iqhr36N20lHs9 BKTZ1RLumVTbDtndtln4rpNKundfU8fjFe2mog6zTqB0KZissiRFDaet/BNrqRhLbFWF4yK9hAyW uzx9pU/FQUa2mnMtTVV3Agdx/D1FZIfsWakjd2XeSPOL3baXnd22p9a7ZspI4dkvDHnDpwYOe7M0 6I2cq5yokrRt6fWg/6cc9Bf3MOCXM8Q/+Rcd4v9cg22eUTUEoxMaZ/WaaTg4vST4HH0Q1r/xaXpJ 4/fSYDh82zgzGo7jMFka6kbs5PBQxwJgN9pGiQF4kxPuhq2mbcgbNg8VCWqSYlYRTeuJ6ytMQRKO Y8UTUDlTz9N/0anna2jVn2PqutcFwZJwOMyWn6YD4gQQcfiSwhw/kzFx/ggbo89W0VkfuV5kLXiV t1kR3BkxAwtO8iHPmDsCxXBmhGJmgprxb4RkgZlRO1WCA20vJAMsjGiXhFhgzlxgYg+AudzHvF4U 2sUcMZ0Ra9eBdTEf60OeOToZpMQN4DaDI6/k3sxPSWz9a0y9uZr/67gtvuo0bd71qHhPgtDsOgg0 7tepbpFO0Cr12qWcpVxWQglGQnEAGWYjYJqSQhAyks7i0zQ3iIxAkWGLPlWNzDgy+GEClkxWJBlu 8Vhh0F9j2FvJ6bDHrcTTLrpSFcRUQUL4VQZUFR+sCnOF2NAqeYBVbAoBZUqGVkEiWeBVUrBVdOsu iK/C5V8IPoX1BBmZsDyAChIyQVSWglBBOjaMigaikh1FhTWojqSyDI4KUnGxVHIgqXDJJKGpJGKp WPWQNnRxuBSTck7AFJkGSwzldwUwU5CGxE3Jg5ryFdePfOhdyTmqJ60sxwP1EdiDSyKnJRdEhM9c XhCRIiK9P7Gv5OzE05bvLKVXzEtheTCxF8by4INSCMvjz9B8KwlHf9ZSZzJFo6XhM6xa28sS2EqC HYMHdf+nSW8l8T7qYDIXlzwdSoiGAtEgtUx4Dfaq04VvoCuU7w/e0M7TwDZAoAaC6AwE0RkEG4C0 wGgILIQGkXgGlCUPyADQ4eAAehCzuGgdsiTrpwz+vH0Ahl/DpiDbCbL0N8huOk6ATUHgBvRUPc86 vJ56Tn0qJJEVH2slktrT/xn55wP1TEwMLyp41gHSd6gMTlX9ddPTz+tV6IqmEjnZkWmZQh2nbh9f /DiKdqmTKYLLbgEuuxqX0vdKtDTlxExTTlSacmKlKX/RsgsXictzIaTZRDhgGu8MkGbc0LJnkn3Q kl2eqNmXWkb4R951Qy9aGWL+zrPK7MmkMtzhaWcY4ISdLNl410qHzax6N+813jdyW7Pk1nifZ7Hm 5bBM1SQp3fT9jLcrCb4JJV3glS8jgxSxU8MtlYuZ7XGUkIeZEZoXzcHMFnrAR4H8y0gEczAXzb3M Fx8s/3L2vMtm4mXuMjKSLy+TdFnzaFrM50u4zHdhvUmXsyRbZvVJSbicnGgZSaQnWw4nWebOlxyJ lr0JltlQxJMsy15VOJsydxIUyKQc7uG5UyYzx1nxdMmMocKpkpHM92/Pi6RJRhpaquSlUiSzycpJ k5yeHhlnTzMxMm8uX/7jwxz5j82eKXIf3+/6g0cEwX+e/K8AuvK4+6z1OR4vmd03/UrM/9vpdLsP n/zb1pPuk61HDx8+edKl73e2tx+v8//ex7X7FzBuK/84e3XOhlgt1APiL8D8pvqBDnV+Bo0OvT+e v37FTGL2r2b/DDbRbHLtTrKRZBtu6uRYvlU2yrOpCnIB0nGT2scT/UW+X0MHVdol73b0R8BEc2u7 2X1KUoxSvRpDcPb253MgS6ch5gCDc5R4bBfP24qzcwOAvGFnAoWFEZONBa8Inb0gCKRFXo4+syQz cK7hM4twYukZZLkVxuvDZqebndfXU0hxBw1BqNE0u+WT4j/wjvTlyWKaTVwm7NJ+vhMv7sYRNc7o kCQ21ce+XXVYyLSpZrTPhWLo+/H8+sgSa+7VYA1ONUkAQQnSfTpNS+L0XqtP+bqOsAB8qNGsqO9u YmSKWrY7bFEYNyUeWJNar8DzAsurVNgXcf/zVJU0GoxZRALc9bDNS7mD1FUZcHTkqms+uJTjpUu2 Qq0tMC0hTfTteNFkaX8iKAPqQ7DCBHkiULZegWALfIZQAbcs1Z68/dlW0V6NUquRiEM87tVG8bT5 9OmjZ80OS89lkaE06BAgzbF4eiPDuPg9mABFzlc0nHgKEzbLvebJMsg57enUnqyLCBTKRpfOLpTi JWwRUQs4iuTKHxSBymh6Ox8wVegR1FCDJ26nwxlhkfKT7ZnHcG62H+CP7P6dFvt3QQz90zHbTOI7 7mBRD/Zqd1Fca5EDdkaf9qb5HBKAQZ3gGDUMiNCxqVSpbamY4zLHRxzvh/N5Ph1Ae7JT03uY9BUD 15q4c7nBvq9IO3ajrfhvavxv1Cn79c133BCMN1qNOvBb33zfIPW//vftdPEdqdM/65uaY4W/Qhlg KdhQgODti+9uLqYwesoFBRsdUGRRfwhSpaMbXfIM0IVfVLS0PFpSvIR4PZKlFThj9FYlWcFuinTV a6aE356+Erm9YCYAv2orWBta+tv5+A2+XiOiNvUlcPLqItMeZwM33uiCYTyDFIcxP+4wHMHqUecG 8h8KnaWzUfNyNI8XzXEE+ctAwnR6H1zTh5RFPuDQFtirKclK0W88p+upm0an0dls1PsXA7rgu7oe /deH8c1kOvtvSvX246fPd7/WG/X97w9eHL784cejn/7j1evjkzf/5/Ts/O3//fkfv/wnFSavhpc5 KCCBKWQglUCTcpxCiKrDoL/gFaq3WvXGc/7RpiXm8+hmNu6LHHgs1dQcwizUdjok9uAm9XAx1Ac1 bcAFZhecFuFciaTqIngN0Vr4PYRpoRXAD/sQQNFcSFaAw922TlJJxClkjkgPNSRG9bYXoLjbhoc5 6KLvkZFdzFWVK4An99dvtzqPt75DwDSY7xDDDqjgdn4TshbxrvAc4A6gBdmR1wUPZ6sgzFpB2rpb JEQePoSMDFFMP+gzN2p7NqUrhHGbtgQ1mETrWKx4eVHMUG1pRtTqkcwEaPs5byG7F3NkWien1UFW Av9i9Uit0gBBw5epkMMj70OeAhowmDasB/PoCmL16u4TSPCwqbVPRbVO5mpNbyeLeaBmQc1JqFyA vqFE+dvgegrIx0k8unCQb+CjHcn6RS8X+1hiAtdZ2I7AWM7LNtsbCLNtAVr+ZhT2e6hfmCxhvfpF WuR2PspbsbenRxmq9ZtWQmptgIscdcGpQjLr0WxRAeC/bQ54WUd3iImq4eMKToOUVd09LZbEaExA TCV8B1Ydi3WEeK7ZjC6qeapVvopltr/yheJM6Z/hhIhUmXIlw+sDXE2izwvMAGqmhsR4Ngz64iXV Y8LxauXszIod0FWMLFUaEnE0X+xzfFu5ftIlAWsf7oCezqgtBVjXXCQ8gwHZBQn2slTxb++g3I3N v+zVVW3r74UdUuHrImCKe47BqQCJ3fAPWj08yIqWuTI+TH2npiZYQFJlkut+BIRVzTXVE+yo3YtY bIvFVtlh8tJzZC5OsytnxOtSUd3t+aI/v4oWoqv5zJu+T/2JeQUKvBxd3c6jWin22OWcLkVE10oW FF1dvhpNmOnG3oV1V9O3DgWgdLW+gGj6DW7J8pHDKMWquGpVjMyxD3+RcXQJ24fj25uJamTBPpjD uFRnDMG7B/iq0jZwe+yAca2Vy+uOabgsdnhVMfstai/Yrwh8EhpI1QvSYILPvXTlxmfPi4HGvlYv mSS4LG2ud9u+KhauNy4An49m1MqWmzkvTvdfnhtVBG+SVbNTcbyfNt4Bx8zZIX7ZsUKYs7MmpJer /pVA9c0RCIuhA/Ix2PqGQHwf45O/jhffJTEtqNFG/+vV4jubVS9T5jQa4lNAfrFtNuseHajrGWtw Ir7ZCQ+KlDjA4dTc0YgEOj2+LmUxwTMLo1+jJrp/NyxuN70uQJI+KqQKsFLxiY4OXHQ6Op5mlFC4 O2gCsLsExK9dTed3e/WLwYy2xfcHb5LVWzKVND5kKhDGRlriy1+O7qvEeDGkBZ6dv1iywIpbmure iUs7k5NGfYeu3czCNlVp9pABo5J/tCThISNb72S5FPS+ye/k6Jlv2Rf33i85p6vrlfJWoOqVA96e VkBfmtHGv3o1hWPZ5slcvST/oIBzmL9dJOpnkAFE+LsDsTFtyyAA9lOYJj2+tU8SrRxmz7pmjhSO Zeng+7ap43f9SFeZqUBSSM/j2/nEmhdtOSX21OejyWgx6o9j9K8IcptheVkyEyaEVcXp/Ork8qU4 2a9Um/uD5Zn/JgTq0v/f2ZlMh9TybOuet/bz/gVgcnhU3pQCp+r9lvxljzyw2BG2T5qMfAT9kqnY y2wlJumAy2TfhdoJlLj9HMFHsaXY7zu6Ujal4xkfHZXWtNNaIXINj8xlsWG5s921T6Phgi5JHj/+ 9xq5mM7punWvtlUjg2g8njFcjb1ah/2GMYz/Vr3cGdqdyUyEzDT7H/ujMRS6Ucd9UdSUZhwt6pue ETa8Mopu4IBZn7Jas+c2Eh6YB0p3zdI3HqgFCzaBkmolne48ga42PFiEdU1LGuor2jRufp1Z1Ljt nCzqIuLOKHKTi4wizyh2m3ay2C3RLi39Sibp49Y/8laG8D2fZhG+wURY9k7TZpC9RTqb6OFKlX4l i/SVxRksacWy1aRZWJi6+EqSXoKAPLY5brtocwvbflI+PwjEIgtwNGmevuHoo+0ipzPFhAzG/Tje q+HrIa8NewjzMHxC/48Sc62usEnKkp/YTkRg97rTs3Gf5X7qDKevLNH7CastdOK11ewNTGy2AnH+ rM1mmssv5AqWG8Lcc5f0LoQIKB+xYUg9UNEpe/W7KK7rU3aSt9HwGHKHb1a/5kg5ZbkP1kAkoAyj gfstFV8L3m3hSxwbA13otP6TO+mCkp+HXLd8gx4ByJV4htEMkKJ5pgR8iLFvRkyEzTu89u45vrdX p88Wd3UI5KYi3mB3N9+zql2Mp4MPEDAiV7lBfzBrdeODrKI02IFwR2p41cMcDMfKfE3ihrareLVS Bmes7WIPZ7vTsRwBos+LWqqwKD/Tca8Mpljsk2TqNicj0Ga34wR1iwEUEkNBNijBTRUFUlC/2oua HJ6yKNasaKsBA47QBBfjUUY28MViei3KHC5CISLw6jk0Hy7ahiIf0e5wmJFLfDErlzej4XBc0mYP DtI9PiUFasemQawaTlFy5itSMMYt3FyIeqxCq2bzaMUlyO3QmvDgeL0UbOtPM+M8i1PXYH8uPgs1 C3vseFNdSswZekSX2u3nyFH99OVBPUSYewIe6JGBDUXinUbiffs5ft6otxafF/XNfMy8g1MOi7gJ VieEPQJFNo95jVPbu3U5OKUTulpnpdFl47hhp3rr71lcc5H4LfiKKSl9CV2pWGGhZMN2uj5g9dhs kDoxwjutUriEXdnYTquK0QBOddWxSm3WNbSx4jhyKrxv2JFumGobLOvFdGY1G51tneVqn7fcb8/Z QYXfw55rr7tbdDafI5LJ27+IgfWf0pOW37GdYcEN7/TtarYvdJloIX+JwvF6YZnNroUtVkJeLIeW Pmx4XLUeSpUEV4ki5o2wSrgqqWFTqSQUH3K5YPhHwUzaCLkqwsRsYz9x4ecr0DX7TflWvL7ZpCvZ Yc6bkYUqSvd5YFvGqbKtqM7zwBihamR5MJLLTHYqL10Xx00QcoRYIxheYcqmds0AuxIi8Tf/skct cdrWpEk6tV5DxqzpuxAVe/9IfW58jXt/YYWoVOx50p0p86l9+lBhvunp5TzY0BwagLFcQYNuUHNf ii5d8UrSPJuJVaiZJqGgTtyjSpGUfm0L1ieVYBVDe0wV/R2rE4oHjgXIDKIxpvndeMDs2E0CETJk i098gmZN6d4DM4LOaXI2fWqLlX6v1hDGtV8yybpGv6plKqrmMdsSVCoh7MByqPrtBGXphjem8lgM uMrH7VjUMPyJVWa/W3Ls8Quj5bP6HckGFjHiYIXoGP638E44ksOVO6+/0S5BHQ4JPtDs2hZpKuc+ N6xK/lPRwqF5+LN37Zm2+oxrmpGe6kMVEZuaLjhu/9tQsKamvpalLMrvq/VZy+SQFXjd6alEYcqj wE0WudTAlZ7a8s2yeNe2B3Is4S8H3P+xuBkrJqO+k7Yau3vWsYe9jHZ2ZZf5d1mWbMyzPYhju+um Ob8P4tidx3bbSFq/SyXKeKflAqZEzx6gQ+56FvZrFJH8AXdD5fgCY/at0ByNx902bwOr7awentAj FsopZnkLQLuPWQipoUo+gfNAeeaHfEM/tCPN/TEOpoPJChqRs51iRM14Rp/hpbd+0179XY19cuZP 6wpeP5YjSueGV66cJ+nl8oYb8ZeUlBM2dAwRZxOvIVSYoyB/MqRY2Nnh1Daz7iIZI+AyQ2CCt8A4 0xMWFnjlMemwqY2p4Sp4zstTdbIHinTd8Zs5OahQO/O6m0BFzb3X2+HZ2GPhpLWtSBPOfUQPhIR+ VyLydxND74LWofmaMBBbfPbWODeNWOO27mVhLizJm8mg5uFK96lrK3V3VejYp9K0SqBpu6i8reSz Qtkt3hI9rXGKePo/UyvgHQu7ex8cn4Uz2+PdDnci07HXbv/tHZf7Hl8rCKevXER8a68iQudw3CEH t9VhBmsrq0b96ZYstTa+nfV24xs6VPSy+zZxBbSMP9M3MFEzgRXfBl7gXX2UWvLIEW/WxQZr2j9W 2+YbVMdTKq8mHnJ7AOVu7tX5aFF3zLQz9sCz8PCu1ZBe2M/NowvCkdaB1UqmAdpnYOZygzp7FVCZ tmbrahs+Preo1gbpOp9F1/P2Qcmd3R9yzVtJwR03/fkHcjvBPhENdSCFYeKG+99qwly4pNKEgFjK NxXJkApiseiFDxaxo5jiRBFdaCxodYCG3pfg9KN/fFNNC532n8//pskIPkpjqp2fq6zzRFsNIFn5 d5j3Lp71/1gKmgXDb1FkvU3lDTDFV+xwu7b3yXxghj+5g8N4oKKoyT/Jg7n2W4Sz+pcz01j1CuUu 1AxUO+KKvkSgAQmz/YyiN8n/Jh0It3Demttv1XpOlK99Kl3cHoro7e1tiN6+4ur07WO8aiLsRchW NrxhtelsvgP23rdV0zvpEiplFTvPXqxeaS1tgZSDfsTfHtIz+HqcEyahWZYdPwkEAeoqaoYd2HPh A829tVf/qT+BZI50GvzpdnwXcIs9MP1bztyUUobIGEkL4SmOV1IM5oWHc2rRjAoXZt2VFLM/m4/G tJiTwWK6skJe90Fax9OPK6zIT7eTiBbyIhqstJAxKhdTs/QycAhaplVQseBYpEhPurKipH7R0hgW wcqK4joGHQe0bnUFCU3DKq1QdkLZcLyZRAUKkqaQsvJ+Pj05/oGc/XJ8vv8PzLv7+uT4/EevLWiv jUPW34wj3SBAk0g5gqnnWBSHe7zJP7ybGT16TlaN8WjyAVKcnp8c8ASEkA4AgAB+hbRxYwLeKj2V x0o3ABLi+z17AH1VK1Yg5BCzYAFMW4XZHtoMxkhwfyk1QWDfgM+qYgOBbx84J8eePUs4ObZlnRyz thkce81hyT0xGbJXtVW6awZoGxd+i0BTBU9ik3TNUglN7ku38rtVvS5VflxC16eBXhepUSEsBGeD CUNBhRGo0WLae7/nLirq0IWPJWCnLPQFvMqAYCA8rz5eBXEYTMSZImAMDIhB0SqIyCDRGDTZZYVl MFAZbEQGRW8JaAYvLIPGYS58hhA2g6KXAaQhFaBBUUtEasiA0qAoBeEa8kE1KII+zAYNryFTLy0H zQGvgpAOyw0qywE+4FUW6gNexaEfAPZB0SuA/6BjP5gE84JAeAAgFMEMSBBak4LxZKJC8Bku3N44 R/pAI6K8oBF4eZAjiNxwzmDAHNC6soAIULgMtguLldj/pvobrSOETzSH0WDKgCR3aO+ZUOZ+py/s XENC58BrmPOOmjri3f4AxuxML39/8uIX9iK6knbIt4gRITYNwcvZvOzfjMZ3O5Dt+GNEh+U+nWTn o/6YjuN02GlCxNal/n48+jXaIZ3t2efvsIwfO2YJ23h5vniMX+CoRflrXkfQysb9PPxUZnTYa17M o/4Hdj5hh/Q/TkdDzlQ3rdqcqYerKHw7Y+HbKyj8DSv7pj+/Gk2acIZ6h3SjG14Ovz1nomf34aPT Q89n2/Izs23xEzogvOIfWVVij1+0mJvSFMUlXh5RbPlFweuvScRRSnZWYQeyRWLJysp2udvi3LWu pws49KYz5+HtE1dRtpnEn3i7sY/3QVo7apw9E4zBkqabka2L6XiYl6l8vVyyRcdcgynmkb4npryC wk08U7mePfP3s27XP/Jo9xOrwBUMdYrdr2RmH5n9pvr8hs5YAANAzTfym+Zlb02m/CZdQ9AZ5G4H hPQ7fhaejySOispZKlw4qZMSS0D6519Mj0Q90EgA6wJr5l0166kXvDsQY7DuNQyBhAz8ujfEQ+nW opSQrl9koiB6NJsUmevCwTyz70TbN0fDjRaEPek3PkR3G3UXi6DeSIEceIACaDxA7jdFRATnhBrq C62pBCH2ufmlG+epBwg5222YX9ndgSPsEJ7fV5GrJszBap/nI/p5N3fjK1soe0miNk7LLSVpsWtq bZtm1ROgDSebYJtUHtLRfIO+Zgu3G6nwLUYnOs1pAG/rShSKtO/TW0Wv2DuWDoDDULDj+ezHXr0u lL1YM5gCSjjCJZm3Rg7wxI9x2EzN4yG3DayYRIsHsdurzqGIMkQMWaYA15QTecQON3OPENV6jQwH DBPDhtRLjur5ejBcWQOdQjojVAQdA+LHX5TCqPIZooLYxdc96wafZtdI6ihufjS3pwgklqTOYgaB ptVcgLvUGwkYLptab7mn7lK5p/5yfx0m9dBdth6TfC6I1crqMP4JD65UWqFPvCxaU6hJ23xRmQg5 t5cSPC99LaNqxvCRQPpjyPV9wHxL5A0kkMKEV6E92/TsxkfKV9kfL0WIJy2WvuRzytWHLNvIG4IG QTcvNe/pRHg7AZ/cZNPdTc6wlZzcCjyJWE8evaCmObvHIPFGMXkd3Uw1N2DWVuI5b0GZZ3w4Mj3D 6M4lFmg5jOP0gS89gfcUsyyLWk91wFLqbnUf19X4N5oQuAsuZ2xTAINjW+j0JnohY7HVxWNvSWcL fgEKKCXVUh3FOWCcztBk+kLu4ECa/bhk7gQdvpkit6PYFg5dKYoQAmc/jsoYdgb4FkKr1EoeTz/9 EesoCG0cXVq7ZxfRYAr4gLAPyLb8yNHh+UskA10QsRUIOnUB3kkQWoBARgu2z3IRkQv6GvCEqKS8 zrTLjVSV/Sq2WUj4GEclWIL9g+nlJeK2wn7fYDCdD1PKl/URWzU8umQ4jZgAubOe7RehXLD5JneE b6pxSHYhFSo+aBa2Dws7ZU43b6XWVw1yByds0+T44JC8PaYL9aPjwxeekVDSkgMGu2mWHOM+mWhY oQGxwP+U2w+HkJ0riuaIWY9jVz/+QF5OAcBnA4Sw2cB9Mkqtz/e84aehMTFXueMpuoGo3rIdQPYQ 92j743iqbU17GOvH3mq0wpUb4kCqKID3lW2v9mmZn0c3tzdQ3Xj0mWBgFC8AqsA31VmS9mGDzKMZ 4hLjlqeAVMBNG1YTjc0FKsRidBMJ1nCEH036M6o/M2rTgRCmCNDpcB1rUJ103o3ARQdF0vcH1ERl BGmJN/oeKv0KkU9wB38+vYJQn1qL+wtmztTDsyECoio3FWw2Bgy4s487n7CvuuBqxW3NuoZWO4oW l4jiCn+0O6NhUySvjDGVUi/7u3hSLAPb1kx5dt0fTj+RF9SoHiymiIG0VAVipNOCw7F+rrUXklml zW3xiCMjRhdHsK8bNM/NFPd6CYbVyUcJ5bJMswwVh7o5a9kh8SwaQISEMU4Rr1EpNzhV3ABUHTBm bicwNeBAMGfwMzF07MEtbtbj/fj26orex9kO4UpvYGRlRzp4p3khhgIefILz1A01wKAv3U54FEDL qE+CpNLlRCWfIicsnYVNoIQOP89o/8RAnDEVzHQxHUzHjmAw1gdlooYDOaEwid8Z8hZxHXrIjRJK RjHi+MfFHw3LkWleiTJk9tEgm1jjAWUNBEvEdzCW3YtMcwqlkJrxhVWqQLipETvoFOXLobK8dpAi omBLwwIjk4qAgjnkQ1hfWAUHpQ1Ob8YRBFjhVC0iwMRcCtEeUoIRYajSkuWTy8vRYKSNF4ygXB9z EOqNs/MXpLMpKyJqysPHWEwq49ZYovKmFIJokSUaNV29LWuTNt7b47O3b96cnEL4z8H++eEPJ6e/ tMTM6D8G6JiouXwmkKNaX4avFjqPSLde0b1Bd2twwWrChH3d6Z0LuPsDjqru3SS8ZUuqPsv+hn/I I1ecYnhrjvsA/9luW6ltbNemz5PppJ+QepM7DYU6iK8nwczChJPpVZbuxdNzUzHhOUoDZ7PWMzPp mIofJiUzFAQ83/yx95SG6nJmD9ETLwTOZnjSLPh6mS7kULaxvMKfBJu+gPD/+m3n8ZPvUtfAXqdx brXTvi5JbPpTn76y49+lSuzUr6qJihXQUS1LRunSuDCJBDNEuCpu7lE420ah/BwPBJyEvptvbKtX BKKFqJTuxBdD8YXxvWTbOGojlFZyZx+4ARKi9IperLGjokB5K2bZFU/hPJTEKRoDSlh5skBZotlW ArQxoYpaZKtTUugMSKCyCXn0k6Z3OWs757398/Vlfxxrc6/9EZun1TN1Yhuf9Hav52L+5FFOlPTo 1whxr2DhH+E5JiM9lDgDZX+X9RxUtybPUNNHLNKLlveoZiGp6LsLLrYHzyxhbJPh+Wx1JpsFdUqy gwjM0ZrMnCx+e5jZ3qrpSoKRLjquy+nLg5rQC/q3PLLNgVzo2xdO2g3I1KaR4OGNoWHAgaVF0sb4 s1Dp/2G30FRyv9B0QBQusAT5sWA9R37+xnMqa3QsMM7Iwav9szOAQZh86AKWvBAFv8GleH5yYODL 8/SuNra7uUFqnoNn+5GVHCfg3Qw5TldiuUIyH3S/jaOzuxtKNxYifxca8CHtiWYwvQ+ca7Xms1Ay mHf6BrukJsd631xXYBdRQwn1JK9AQNCsIuOnQuKNB/Bdo94wIcO8FgYtHiBfZe5SmQ//IqI1jnRS ViZBGT/gBSR4gIQF8EB4subls7m6YTObA1Y1sEhLhlS10v9rtfWBTQaP1aqnyXvT+drigWr9lUrd nuZTVtyZhwTTjPbrsE+NVd47TEjZ07sjnj1WCQ9F/MvN7XgxmsFMzZxee7X9Vkf/L3QI3TswZCwr ZPZmOJyeJi3MatkTwctX4LPiG4+cN/TDMTHJRzy5EZxspLKkxgOBw4PkcnR1O4/Eh1pss5zdnESD Keesnfffdd7nCR1qzVr2mOqKffFPxrjoAIkp0ZQfCI8uxddRtOj92/paX+trfa2v9bW+1tf6Wl/r a32tr/W1vtbX+lpf62t9ra/1tb7W1/paX+trfa2v9bW+1tf68l//Hz6sPbAA4AEA ------=_NextPart_000_0010_01C120AE.D2140410-- From w3c-dist-auth-request@w3.org Thu Aug 9 03:18:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16435 for ; Thu, 9 Aug 2001 03:18:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA22894; Thu, 9 Aug 2001 03:14:45 -0400 (EDT) Resent-Date: Thu, 9 Aug 2001 03:14:45 -0400 (EDT) Resent-Message-Id: <200108090714.DAA22894@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA22874 for ; Thu, 9 Aug 2001 03:14:35 -0400 (EDT) Received: from inet-mail4.oraclecorp.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA00916 for ; Thu, 9 Aug 2001 03:14:36 -0400 Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail4.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7977dt09141 for ; Thu, 9 Aug 2001 00:07:39 -0700 (PDT) Received: from oracle.com (ikirnos-pc-xdsl.us.oracle.com [152.68.16.218]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f797E3324336 for ; Thu, 9 Aug 2001 01:14:04 -0600 (MDT) Message-ID: <3B72387D.29EABA74@oracle.com> Date: Thu, 09 Aug 2001 00:15:09 -0700 From: Ilya Kirnos X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5245 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit (apologies if this is a duplicate) Stefan Eissing wrote: > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, August 06, 2001 1:13 AM > > To: w3c-dist-auth@w3.org > > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > > The full proposal I advocate is as follows: > > > > Delete all references to the term "lock null resource". > > > > Instead, in the LOCK semantics, add the following: > > > > "If a LOCK request is applied to an unmapped URL, the server > > MUST automatically precede the LOCK request with the creation > > of a resource at the request URL. > > This automatically created resource has the same behavior as > > a resource created by a PUT with a zero length body. > > In particular, it is never automatically deleted when it is > > UNLOCK'ed. Note that this changes the behavior defined in > > RFC-2518, which stated that the resource MUST be automatically > > deleted if it is unlocked before it has been explicitly updated > > (e.g. by a PUT)." > > > > I believe that this reference to the old 2518 semantics is sufficient. > > I fully agree and support the proposal. > > //Stefan This sounds good to me as well. -ilya From w3c-dist-auth-request@w3.org Thu Aug 9 06:39:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20452 for ; Thu, 9 Aug 2001 06:39:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA15035; Thu, 9 Aug 2001 06:35:37 -0400 (EDT) Resent-Date: Thu, 9 Aug 2001 06:35:37 -0400 (EDT) Resent-Message-Id: <200108091035.GAA15035@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA14840 for ; Thu, 9 Aug 2001 06:35:11 -0400 (EDT) Received: from w3cmail.inria.fr (w3cmail.inria.fr [193.51.208.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA29980 for ; Thu, 9 Aug 2001 06:35:10 -0400 Received: from sophia.inria.fr by w3cmail.inria.fr (8.11.1/8.10.0) with ESMTP id f77InsZ02597 for ; Tue, 7 Aug 2001 20:49:54 +0200 Received: from adobe.com by sophia.inria.fr (8.11.1/8.10.0) with ESMTP id f77Erx722194 for ; Tue, 7 Aug 2001 16:54:01 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host smtp-relay-1.adobe.com [192.150.11.1] claimed to be adobe.com Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id f77EooL16438; Tue, 7 Aug 2001 07:50:50 -0700 (PDT) Received: from mail-hamburg.eur.adobe.com (mail-hamburg [130.248.122.254]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f77EoQ224449; Tue, 7 Aug 2001 07:50:26 -0700 (PDT) Received: from adobe.com (warncke_h_pc [130.248.122.95]) by mail-hamburg.eur.adobe.com (8.11.4/8.11.4) with ESMTP id f77EoAI01791; Tue, 7 Aug 2001 16:50:11 +0200 (MET DST) Message-ID: <3B700022.682B1778@adobe.com> Date: Tue, 07 Aug 2001 16:50:10 +0200 From: Hartmut Warncke X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stefan Eissing CC: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: GoLive, Host and Destination Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5248 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan, Stefan Eissing wrote: > I stumbled today about different behaviours when > it comes to treatment of Host and Destination headers, > which I'd like to get your point of view on. > > GoLive (5.0 tryout) does send a Host header in request, > however it omittes the port part. So, if you have a server > localhost:8080, GoLive will send a Host header "Host: localhost". > > However in Destination headers, GoLive uses the correct URLs, e.g. > Destination: http://localhost:8080/test.html > > Now, my Servlet checks these headers on a COPY/MOVE and responds > with a 502 (Bad Gateway), as source and destination do not match. > > I checked with mod_dav: same behaviour: > I checked with IIS: works. IIS seems to disregard the host part > of the destination URL and performs the MOVE/COPY. > > Now, you can look at it two ways: > a) Well, nobody can move to a destination on a different server, > so ignoring the host part in Destination is Ok. > b) Non-matching host parts is an error and should be reported as such. > > What do you think? How is your server handling this? > > //Stefan > > PS. I don't know if there is a newer version of GoLive where the > host header is fixed. Anyone can verify or comment on that? No, there is no newer GoLive version, GoLive 5.0 is the current version. I will check what I can arrange with the Host header in the future, Best, Hartmut From w3c-dist-auth-request@w3.org Thu Aug 9 08:46:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22096 for ; Thu, 9 Aug 2001 08:46:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA07075; Thu, 9 Aug 2001 08:42:07 -0400 (EDT) Resent-Date: Thu, 9 Aug 2001 08:42:07 -0400 (EDT) Resent-Message-Id: <200108091242.IAA07075@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA06930 for ; Thu, 9 Aug 2001 08:41:48 -0400 (EDT) Received: from w3cmail.inria.fr (w3cmail.inria.fr [193.51.208.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA21673 for ; Thu, 9 Aug 2001 08:41:47 -0400 Received: from mail.gmx.net by w3cmail.inria.fr (8.11.1/8.10.0) with SMTP id f78BbXZ13493 for ; Wed, 8 Aug 2001 13:37:34 +0200 X-Authentication-Warning: w3cmail.inria.fr: Host pop.gmx.net [194.221.183.20] claimed to be mail.gmx.net Received: (qmail 24509 invoked by uid 0); 8 Aug 2001 11:35:30 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail10) with SMTP; 8 Aug 2001 11:35:30 -0000 From: "Julian Reschke" To: "Dan Brotsky" , "WebDAV Working Group" Date: Wed, 8 Aug 2001 13:35:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0024_01C1200E.FC578670" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5249 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C1200E.FC578670 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I've made some minor editorial changes, and added wording which should take care of issues 1) and 2). I'm attaching the draft as XML/HTML/TXT and the diffs from the last version. Regards, Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky > Sent: Monday, June 25, 2001 9:24 PM > To: WebDAV Working Group > Subject: RE: Proposal for marshalling property type information > > > I also like Julian's proposal and would be glad to see it > incorporated into 2518. But there are a few questions related to > live properties that I'm hoping Julian and others would comment on: > > 1. I work on a number of servers that have specialized live > ("computed" in the deltaV sense) properties for workflow tracking. > It seems that we could use the extended PROPFIND to indicate to > clients the datatype of those properties, but Julian only shows an > example where the client has indicated the datatype. Were live > properties expected to obey the same extension rule? If so we might > want to clarify this and add an example. > > 2. Some of my servers implement "type-restricted" live properties > which are essentially dead properties whose values are restricted to > a certain datatype. These servers will reject PROPPATCH requests > that use the wrong datatype whether or not the client has declared a > datatype in the PROPPATCH. Julian's proposal shows an example of a > 422 response when the PROPPATCH-declared datatype doesn't match the > datatype of the value; I would also like to use such a response when > the value's datatype doesn't match the PROPFIND-shown (and enforced) > datatype. How does this strike people? > > dan > -- > Daniel Brotsky, Adobe Systems > tel 408-536-4150, pager 877-704-4062 > 2-way pager email: > ------=_NextPart_000_0024_01C1200E.FC578670 Content-Type: application/x-gzip; name="draft-reschke-webdav-property-datatypes-00.tar.gz" Content-Disposition: attachment; filename="draft-reschke-webdav-property-datatypes-00.tar.gz" Content-Transfer-Encoding: base64 H4sIAOQicTsAA+xc7XPbNtLvV2em/wOOH2p7zqIsOc6LKytWbad2a9m+WGkuvbm5oUhIQk2RKgHa UW6e//3ZXQAkSMm2nPRy99wTdVJLIF4W+/LbxQJglAUj1ci4DCfXvHHLh1Fw05hl6Yxnat6IAhWo +YzLxva2/2Eaf/NJn+3W9vazp0+/2YbP82f0F0pa9Ht7e7e187z9zfbznZ2n7Xar1YLn7e1Wq/0N 2/604R73yaUKMsa++S3j99b7mYvkS9DzhT+dVyDWhlTzmMsJ54qhuPfXFf+gmh9kvM4mGR/tr2ej sP2s/dKHIrXOXnW/fdL509HF4eD95TGDZ+zq/dXguM88Wy9SkYeVXuFDlYb73pxL71VRJOdT6Fc6 xVgqZtm+N8rjuL3dfuaxKA3Pgynf96KVlRQHXeuMsjRR8I3BZ62jhIp598jWYqM0Y+/48Kj3CzN9 CC47TV0Nmq+tdYJcTaCWSIQSQQxk/uSz177HZJ4lRNEbTYvHkFpd9FMeiyCBasw+NJ2l2ThIxMdA iTRhwXCY8Zt9b5xxngznCqbfLb+zH6fDk07TbWEpiiKYvzSTsp+1ziwF/Y3rxWsdqaBT1b0K4o/T IEngZyAlZ63ddqdpnlXb6O5Coebdfs6hAc86TfrZyfgYCTl/12mar50wjXj36YvW7kuohN8XO2MM auWJyubdH3kGRMyxqi6o1AZqm8U01nCyfBqIuPsbMdQ3Yj8oueRHvNPUddY0d5ole+gXic+M0gH9 4GwKGjHZ93r5GAzeY3MegKq1AYU81iRtbjSg5W2aXY+zNJ913x3/gAryDgpEMmY/YmGnWT5njYYz i04wRA6HqttBvg4mQjI546EYiVDLHeyJJ5FkasKt8h0JaCOGueIR6xHFONJlloK9pDFYDfv2icxn szRTzOg4VoDOrOqzmyDOgR9lIx7zKU+UZEHGoXnERyKB7qGvGGw7jIV+mERM8uyGZ5bMORGG9sHS EQuKEbaorkq/fSJQh/JQuTOYcqA6YpdvLi5fn54f4TAZV2Ajll4OJgTmNiUe+A6/mkqLCv8UfEA+ wegKuQe2n+NMGHzPk1hMBbAJJhrzANRYAi9ZmE71XGFYJMrpqcJRnMEvMFXoHn9uaOI32a2RLQmU BYp1OGASA3cw5mrfQ/1S6d7tTtiIoN8GKtXB7Y4Pxul1l5WCTkL77ha7nYhwwqbBnA05+y0lCQzn RDTRA3yTMhhzdivUBDBl+BsHvn77xIOvMoQJAK7AnB4mByDxd5C/MgS8Ml3tl/1076tvCPa10Rjd BR6GuURmSS0MkLa2hRq/QMGCLJyIG5gdMO/tm7M9mEOV6IlSs71mMwYCpK8HbfZ0I9m8zIexCJsV Cpte9/Ft7Dxq8FOoG00OaWsWZopeomndBP6Yiigi+Mf/OhK4iNpIPmHfO08VaXAQs8M0uQGlQ/aQ g6OuBsCkaz5HDoGJe/23VwNvS/9l5xf0/c3xX96evjk+wu9XJ72zs+KLqQHdwO+Lt2emCn4rGx9e 9PvH50e6fb/33tOG6V1cDk4vzntnHhiaNhzop7AdlBEo0hDNEPB8BsaJwgLr4lo/ImzW+eCK7M3r Q4jCXiIs+sgyVZkl9DJlXoE/Bm48MPsRgomxxL/2z+wj+A3KISLk2Qj8LAoF4CUApxvmMUReJdKM yOOCH0hCXow8EuM8Q7l0oAlqYLfzp78dHvUGvb+h2IDkEIQIvcc8GYM1QTSTgL8Gfd3TyP73v3dB 7qYtdlv2uGRW5YwQdyQwCKlyII9qecXsiJeEsTgxYKbVnFbbb7XQgBa5u9t6cQd3kW8ZBzEBVGiN wx7A/YGzQ7ibpQkBHhBmGHmThsEQ+TgveUxggyRjXCJnQai/MWuNt7e31q7QATZh1CsawiOEfg0T xhhFoEzIK4DvIm3jH4LpDOLEQteqLg6oovpA/0h8YN4Huedhh6AUKFTLSmhXEPY9djVDixQhR5We 29YhhFKgtygCxCcPWaOp3GNX5IhAiNJjG1X+/vWKHPomg6gtNaIBOjm4uiAmlinjIXQcGIkMsRdJ B0pwfBzIGhB4VhALPHNaoU1hVewsEiNQe9SDYkYW/SeB/CQZNKwF/OHCEHdJI4bZ8ezxQjHa2zQq 312GnKcQ7qVRTmUFXjK2JEAa5iIG8MSmEwobIGC1ckaQuAH9Js2mSawaRQH5ETldN5BqYGRCBlvG /z6rmmMvhq7y8aSIk6YQNxa9oJIY3NHMqsRjW0wo6/5JTbgUWTCMCYxnGIlAV7oqAogMAwRCU3A7 4dBhCh4YGtjwC6QNRdxOHSexLnW4RvW1pF0iEL90LKbDP6yhwz/SafOdQAssAUJrrCTGSYouA6Xj BG5bIBzlzMlORQXX8CO6CQCsxhQ4CuqRSJqmYB1zHe9Y0mqQd6EJT+F/GRhMEm3pppIrhQ0TfutI iLhqNNDlKMkRFjfEFVYPOgEIUuiKIi0cjJjjs56RK3VYnQf2Z6NQtyOYcDpTEIh+hPhTpRlO2UgH KMR6pGsmTgAPJynahAfaNWizxq5xQSI3fXZlVItcpFUtySmqgqZIGsHYUvquk/Q2KedsFCdKqSW4 iiATEmM4ivWhYyhf0WYvgKgbAbzXpJr+HestbKO6ip4bQoyMADcUzYOmZwqnwJZJEMfa/ED5rRXh qiNxA4ctNCxcNUJTcHcovDkDTMqh9ZxQWAoEQLIJGjcW1zrQGQNTQWfTFBYLGMVmmuM+c7wIu4SY gLX3WJEXIHSse5M2epPCjwSomuSSaeiC8Qj4eoLYB4UNAdYeBlJoP4PSjckaFhQU9Kd0Lz6r4dDR UqUm4zZxAgyWS81nx1ExDxt5YNrpFJ8gYc7sS7f0OI+0dpo43Wy5+oci+R2ko0MQGsDAl4lszNBI CThdWrxFejoL/EVnoGDgYh0p2YbV0h2ocKeoNrdsPKb9Is37EZP16lEZCOcmFcDiJOEhLtsg0gL7 GKaSXPJyzJFgHnEEviyeG50g+SNfBIIkAgVGcYRgNV0wUE7ey2fA7jJW3rK6XteFJFUMl3YQzGi/ HsNiyYFOhyfYhTHbOyNTZsMDpwdERBgZm2Nghz43Gde5VaAqOgoyER0koxGn06FIipi2kCvaKUCz VVNUFBzD6EpNT5Au4xrnuon2HYWAZY0gWLhxjT9L1xwWlSgeoBmDZeTTIXQJNGY8QATdI2XD5Sij NOm+J+fTYRoTIlJ+sTtw3a9APXYFMDfrfGJNw4pCwvwgXg8JofVSVTtumoivZ0G5klr/yNtJAN0P ufaVxvyB9DRplJBsskg4eWMHzIonTyKASIwCKXy0bgvVT7dfHJ7Urja0jt+0qQU2xcV1PuiyNzg8 MQki3VHgqmFN+frHg5OLo38UDWl9ZGnoUC6g6yDjve7rECKJsQnv65R4QGcIIeKSEQudOR1Vwym7 1MOI3rioEmVR8yIdXRPebtkQzTEEHYovRhMSeg7ROoq4Iqqt/rAz8h5KR7WLYZ5PKwSL0FuUZtIJ Payv14gkOiAe7dY4RW/LCQhBLCFYhfaxRf/YViukziAYALBulW3cJ0+Lxr4O9ivsAP6nksIDQEWh DAbCCgTDJs0gDT46UNbzFtIJ101WUrjYSGYXx+mtDndHgYhpOibjhbiLP3X/2NcYLBTjJa7hcySU U6GYWbFIwrkvWbGbeRnAF0mEyxkozkN0FqM8hp6U0U9CLxMWmsyaBh5iM9JESUKlrKitVjn6libL lVM7O5itnAFk6c7SaM42tOJN0fmYQBMmasg1udqA9d+eDU6vBr3B2ytcHKoc47KIW2QK2Hex+n6a x0rop9+N1ffFWDTQZsGbRYM81itVEwcVjKmansnKdED9g+kwNhsK3e4bLb9O03mwLBUElUtjbw6D zJ+oacxOBoPLZstvUYWTVKo9hr5/lKY+eBYqPdQRaGMAnN5jeuNrGlcenVFuaY99gA/OEGHxaM8K IZ/RDgNlnvaOTO7JJh91KUhy/xGBVr3xw21rTX6tt4DJNgnwgyySzY87L/3dbc9uYMBcpLsfZObm 7tJ0ft3LOOXeo0It911A6Y5gqcI7zbKe01+z2iH+Lga0D0tO1pN2bsrubjXRyriKnlidYO3t56yP Wt24IrX+PHVw7OP/ti5Yw64oBG4Dd51+jAUVloZipDp1LUKOVDTJ6MKDGgX+o644VlmJyV1Hjtvs 4mfSKv3E3WhapALLqnPEEkd89ymgDhFMyo1WplsPYLWFaK+csFd4CqnjBR2jWW8CDzlwBQMOE6ml qV5GyXw4FQqXfEsXHncs8O+HZHSVbtD2FY7//Sb4+XCsvkLxw1D8nw+NK2Pg03abvU2gIiUpMKY+ htWlmi9FRXcqeitwRmBxZKNhDFNpzVCqlIuabpsF1fpDoZYxF2srEb3BrSEPA7vZUWRZ9MLF09t4 OCGzWxbEor7GMst+u6zRq6q7sggSlmm42OBZBq3CNNELZ53zTMMwz2wkbrWI1RbkSAi/oZQ9pVCT 1IHy20CWq+q9yoaoSY0Hds0GToZLvYpUenLVlAO21YlJykJBOygOROImGZw104qp4cVQvhLJI40Z X0xR4bxIrZDv4OKirz7mfh/zhRzGr3thDsHF9Ku7+NdH7v9FvuZLx9v3OAECIfBHkd6jdILoCJAe MQf3ydgE/umdQtxmjHmxi6qxqjQE2hwF/uE2aAWaa3CmNzHM9mot+UIJkbsA9VGpSzpUZzKXJTOK J8CQIudaHr2rTs2lu5rSp62qJIZwAVwEtxmpUYoOQW8iFt4NBgIqVkyEl2PT+SfcrS2OSVDO3tk/ YBul+ybxJlpnoBEMLwUsfrhe+UR8FIDGlL1v3p0iX5d1IlARaNv4jnyls/mhe3TowvMf5Q5XEANK RXN2y+PY5vI366nq1XJhVo5NOlL0B3pEUo4v5xCBB1ENNz8V86rgAwXl+S4UQdN55uKWAzRlD/YX kvdf55gexeAvvfj94k7MKVqiNV3iuO249oxV2z64rm4tD5QWQ6VH+85/TaqKTlqZs2KY97+VZbqp dmLIU1nOvcrBIXtsBocO04zOyi31LXanv5rICie40+N4FyASu7LHm2pLscqGUnliwGenSh+EKenH XpY7uWI73EwBkdarix2Pz8qFbaWK36C1kcb6VdzGp/l7PKejxFDEsFJHLCCPFyycLl44LFdsWwlz vk7vp5kDU9WrAFtQMaMWOFc8Q0VRhj1mh4yLi8N0gyPi9hT8bjwv1qLSPdmkZYt9lVvY9pAsxWd6 EWjvGuiUpdvBUrkRbbSN/PBm18YMT0SmuQQSMUGqnbBWQVoL4+mKIHHHrHRa71CyHCyscJ211f+h mQiyO7jFGMCeDqvKxGyqYTV92oeIL7eGibL7ydgIRngSE9bkW3qEsv6Q4zk2e8Ia+yoNpHFqD5eV J13KU6i0V+/uZwIahIrIM+qfZ3i4cNNnF0B/ITc9HbI7cy5wGT8xeHRtqJxMYYHDeRmVbNBxNJNF 0ZGtRMmZE2U6G16c7awymBIZ9qgQsWfIJwEqQkbzyhN9Js5SgJ3ReCgqEdNJlGEKqwRbsZzEZk3m 9mTeQzLngs6fRHhy/B5pb7FyP5uO/1TPJNa39E/SWzywTBsLtA9/K+IYjNvsDSxsMdc2lUv7As5r KcBT7GcYhNflRZ/6sgVUq8inuNu5Dx3wxZ17rRb2ktsdSMbMwV+cbypBi8ozv3fiqt3qBzYLUCr8 Rx2J2rgaQ1c9ldw7761M5D1YS/2ElX62QNXQEjWRqmxt71nZtuWZJbZhJDHmCR5Tx4tCYI56RUv9 GDjGY/9gveZQBLhVueJ8D9PZPBPjiSpmOaAzHUW+1FwYAL6zY7DxNFv9eDesgzidysQz16TGnzuI DnyKCzlrHVRbPTxdM+HAX7rpVy2yR3vWzQ2Wdd3EXvLR10Dt/UusxH7mc7zgF8n17s/F7R1CEn0d AOoQ4J5am3ujz9iREzoDc4yda6MLd0bXr/z14sLo+g9ZEIF018sLo+tXYaoUsw+wi8q9z5Mgu8EE 8ttEIBZRLr92MdS5FVpeBLVXP1s7u9usH0jps94NHigrrn3aGoewqslENOZLnvV7bLvd2nlRPHLu aHZmE1C+boP9ucWetZ6zpy932c6LZ0+hCj3AW2B0O7Nhr2mWFzSdy5nuxcz1Pp56Xtf3MtdbL18+ X4eqJqcIiy4edH/U1oGxLvyC0ms+R5F1zd9O0xZgi/Kil7XqU3OcuFgeMaxxXV72sNdEjCIg6tNR XkyygwcE46V+bPrJKIIsMv6uZ/CZuTlS9pWCb9fpjTCYCYWohTcaNdoUV7ZK/+a0NqefjUvWJ0or V7qAhNPjwWv34oq5DIHHk1OT1TGdjnOAqxhHoX6Ks0sQ4M/SLFAmGTObZBjNJSARmt+Qj0WSlH5G ZMVwe2RpNvVRLtGq9+K++z1P1feYj9HftpwSvOlWLbUX5qqldGNuSZEdcaEbfZFuWdmyIYtrdvaB JbH33pYUpzXtM3sFT/8qruM87hKe7RJhCcHLQKPJJzmhCc6x2I4yB9ZCu74qNAYTdnj/woFdR2Wp lxjxqwgZitu2iYkc9XH7rHLZx7k/6V6eBKeAm1GnEMwzA3aHl+s6mAFbfrqub1gv1IK5FrUIsHW9 ZoHo3eUAj6f4vfoVUycbMXjTBAB50QRxNvDlBvgDsGxbp9gq7qB7jPlTvRYFBLrOZ+wMFkc53u3Y gGE2Wcvfvg/jBzWMn7sAPxBTRmUL2D7gH9Bl4qoPw5tzriSAAr8b4A2gqiF0d6CK1pg2uR9jFyj+ yaX4Mkhj4ZL8E+6B6tIFovsizFIJMPYgmb9BL7PgYGobfAKZhz7ru5ReQWgx5Nm40Q//ksOKxiWa 6rKFGgsTKD0p6v1pDBiY0iKLHYLOB+OUhIGyYceAhnRv7JQoUtDwwVmHUzkNfz/IRejzKH/kfI/d yfaDuBoqHN+gfsbLwoSrPGFaMnOp+FQ+SCbYvT/Fvg54IJUv82RV8dTHLl5m8W7n0OtCJAVu5B34 Fly+UXiN147y6ePClv7pAGxwiI4ozfQ+NqZJclwYX4UCgWBJuLL7dBcEF06SNE7Hc3b1ew7Y5daj N1k4AQ/9ZvbVFv1e8WoLpt9tgcFP+W6L4k0Wb6/cl1gsxkR/Zjokau/usPaz1o4TEo2CkBa+bqUX bPflSximfFbETkpMh3F5UZ/K4GGeiW4F8kJdAcuRIIe1yyMt7zUfZsCduX0JBsKjeQlGAeoLYE0i NmCt8XdVrMYLufdiNUC0vuHcaDWXQXT9zlbLvQB8HzafACa4VjWYgB7JtAIdJzwBJbvCbT/z8AHU gJVLMsyz8eRBO5uogzAdy1AAGvhB6OfXj4SEo4pv4Rzj45Lyo+BGREwXL9B8AU46fhixqA+f+jhI qcknIHW/hlyg7hUv2M8zcFrMPlmgFW9IbqKNwyoXFOcieZjuKXV5MM0/TtNPoPi8QjHun8YynVT0 4jwNJsx5tED1WYqbMkcYRKUzCp0OTfgMTx+cAHb/j7L7gxh7+wrD/59guB/Ml7yGaFUEvmo9AoHb KyNweyUEdm/N3gfAlz77pYJhIqui72WQx1CF6QcLNvZzIIAL7JLeHoU3XfU7Qk44pot1AoZd4WG6 B+0NB/J/8Wmcg+uZK8wVMaNXQ7lJCgshdy49WEdfs+LJ3dEzTQKwLtZR6A/9B6kPsOvpJ8TTX5Hi K1Lom3irIMW6SbsvTZzSDjYzy2XcqkU5L3/3RqNh3hh1Hza8d+3pxzSGlZdrTe99ZgoXDKmmnauv qt5NhOITHlQGOvZZWf5ZY1UQ4nUgPlYW1j2f6bLPGqMSzx4CFtcyyj4zhZ81SiXw/Ak3IyqofeQz U/iYUdxkr12COPnel0W+9/7UUiVphMq6RLmdX7Jb7iiYbQR4Ogrh77/7zZv/GZ/VX61JR3M+aYz7 3//6fKfdel68/7W9/Rzf/9p+tvP1/a9f4kPvf2U3+vWI+17L3/YYN8mvfU/ItPHixe7LRst71e3Q aULzgrXFQBKNuPkB63hQFeC0+7g3r3boUKl+/6xHR7ZCKb3uk96Tfz5Zw9+NiIdmgbWH7zrgT/7n SW9vkgLxS6vQ3Tnc56B6+DqrG/5gxR8ujv63vW/rbuNI0pxX4Kz/QzasaZC9uBCgrjSJFk1RNj0S qSWpdXt09AACRRIjEMCgQEm02/9Fb/s3NyPyfqsLqkDZ0yifVhN1iYyMjMyMjIyM7xd4aUDtkvkO +Zbp6Hc4hFzSYal52afT/t0OuY7GH6PFaNBvkP6cjpsNEvcncRMGrEvt9Xj0a7RDOtuzz99R6j92 dNrbeLkvP4aX4Sbw1LyOYOdWv52Dj8qsfxU1qdHX/9DE4JIdls8EmekmVpQz87DsUrezlLpdcqlv oNAbuggaTZrj6JKKsxvdsBL43TmTMt6m758eOl9siy/M9qNvn+9//wrft6oAj160oC8wFRUfXuLl 1nrLW2teVa3ytqbBuaYrqsiL6YwWSVcHfLvfZmkLWWrRFQo4uRVHLkOfuNJNMDyMPfD2QQ+/g5Rm 0jh6xhiiev6hm4Wdi+l4mI+ZXN2Us0NtDI2Zx3jdAzMeweDIqGvOs2fe/tLteocMdTuJca48qDF4 u5KZacpj9flNNBxBjrfRZEF+U8GvrcmU3xuO4tm4f7cDUvmdfgLLvDsY8dtsmoDzEnSywFOLg3E/ ptML/7ZGeZ3TzrNXo9PSIBqPZyydn/wNETT4m65yPo2GsFzapo+YAOh09qhGsHp7NR7/sruY0/8N ycUVinSvxocg+d4AHA3zGu9T6reHOv2bMk8nrll/IhinulPrfaH/fqG1pPdpJekbF/O2+RrvgjU4 c7MYwj9zD2ustR3W/BXt7fZZsvbat9TAbS2mgxo5eLV/drZXw/4FvIri+Y0v5yfA5wUY6jojbWwL 0SS8uMeP/z3cHB2rOTpK0oLbbfhcVo31qpqUB46Rtd5xhHHMZt7tL4y1vLQwZ7tIxv7FlXMuYkfH 54enx4fn5MXp/svzJTlSKcyLsqMHrZMKpGfJbshD9hbj+yVrw3KpQ0R7p8zqVA7oKvBqOr/bMZg8 UrHC/fGSHBdl8/DzbEQlvEPEAhYq3y2BGdHhcJwYjj7ag5Y+dOCcUEu3qvnoQ6lRc7zTY+dRZBzr 6+hmSsffTm931sOk++d21nVaIgvujBbNF6BchMfS4uv4T6UymqBjAIIgsXnAnYRxrX16E7O2ykzi ZyIz8hb8Al8TXeVhzm5sZySKVM1SWfCUyD2ugrV45Ip4mRxOqKUWReCBYvXpxx8gORZlaANiozYb GDwKwWM8LyH8NHKaxy38UsXXsOxy7BnmrmJZhaXXy8NWP/bVoRWsGHZb7Xt2RJ2dSb/pfx7d3N6w hJOfmfOEkQf2eTJWdvJ22ICzFOP+AP6iH08v4ukYA40u7ng1NB5ZSr7F6CbijGGDjyb9GSgQneQX GLIEYZAOzzFRjkPaHSMwCaBE+v5gtIiQHi1PpOajcpxg8jEc1lmu3CtweNZaDLlhpmlgRPB0Ia3v 4HaOBwbt4kVuUYx9xsTzDDFCTH3asnQULS5xYQp/tDujYVNEL8WtBZ16e9nfhekxkV2ro5xd94fT T+QFJpee4kn9ZRiPkUyLLalTXgiwSJvV4g1jySMcyCDw2hjJFAE6MMigYQg4G4ETX44W6tHGwSZG +clueDYdUPbuyAZMC5stsk9LO4VXY5iJ8fB/i/vjWDH7XNCSfFngGcWwM8qDzigDOUM7X40NAHIq CzajMGqGUOElADP6S6NlOGAZSVwUxslgfUt0rUIQGVW7y68cHKPvIGMIdcIaUY6u5866C9aVaNbD GBOBwd9eL9H+gEu0Pt/zE/RwTD3HdqKqyY8Xx2xwBQq3Y5YdnGp/jf8hLVP2/YXFJT+a0erg4dd+ 74scjNBU8gCjKHmGaNGKdW1aOlRAOoXtWm/bpuBPXO6n5eZ/fWiTS0okm87gQxAY/cemmpYNMwvl LlB2BJiU1C0L1W2g6gi1rJQ/6RzQ/vEorQ20jBgZCEITPEpuAiMJQzrJx7XeY4fHhFO86RSf1HpP PF0h7VBdOuGntd5Th7B78C2d0LNa75lbZ24Bpn8OgfedLV8VnZNjYWJqQ7fW+382rVP5MEyAbUTL r5mdU4/JPgu/qDIYutDXA3WAjn3/Eha9ygyGxTUajxad9u24V63+8SfYrz2Lweykz2T2nNNSzR2a ciiJKjXO/GRaM0qq3SsHqaskoK78OF1S7BKjix/DXPb0Yq33jpN6z2xcXF4kSbErpVgYCayaCQiM sVSF7Cy0YHB0pkB+oXcTc7bgZ+GqPPRUZXn4r2oA/ctoMzzTzNtsiXgq3lyUStbmeiTrmAdarLoC ZLFqycBi1RJwxRJhxWTDsRMMrNESzyLQ5qHvYtP48ceqJcKPVVeNPlZug40CLbYc9hgfFNbz6rLz qlh/afOqufxKmk27YjYthuNWLQfGrWqiuCWPiV05hZWF71YtEd6tWjK6W7VscLdqErZbuuS3UfLl oL5VywV9q5aN+VYtE/KtujTi23qkLDhSCj+TNlKG3ExJY+a2GjNLQc+rlgOeVy0LO69KiG4xdYMW k/EVGExdNJhyQOxVCyPsJY9U23KOKAt7r1oC9F4ZyHvV4sB7RdvZweer5oTnS287NsuUAdxXLQu3 r1oYtq+qUPtWuKJMAP6rmrh/6c3AltflIAJWCwACpnPKFsmlQAVC94AdFr6fAttHMORXdsej4iCB ItRXwwikZNlmuk1/OZBApJUDI9AuvghIIBKyMOUSdmvMADgeW2TchAv3dCSj6I4Vw//aJlraJnrI N8s0m0i+57ZU8jYaFJxkOD2UrttiuIzVEmEZq8VQGavLgzJW82EyFpqpW9WyoBur5SE3VpcDbkye BB4aju3yIB2rJSI6VssCdKxmxHMUjvfrbkhoan9bGwjSt7cpQWgJ+ALKhf+p/PY97uknydgu8NzJ ZA83/anW9Sd6pvUqMkFlkYLswmu3VP5069sM6dONL7JleFch3aw2VOf0KG9VRTP2G+6nZTyHLxDb EV7Wcp/b9Nt2Afymxor2mhK1vl/jqIXMwK/pRTDXfqH2D6fa/9M1vujIrgbAbAB3E3Lv8zYSb7oa BDJytUg1fhadYrt0Xq3RdFgOTVbyfKFY8nlV/7DtY5M/sCXDb1sjoaaNoZFPLjNLRIKslgkEKWzc pPFbRREFxm83iGg9dv/pxu7Fetz+HzGSLjlkhnAhw4OoVXcN6xFeS4KItEZZ60uP0q10kJY7TmVh SFZzQUimLTm60kdWJrxktXx0yWpxcEnlcQlORir4NHExsWzs6b/yxPV1piEJqbeehL5eI/4PmMD+ KDb/dobpJBcaZbU0MMpqGhalXA2sfd7L+rzF4QRtdko8m5Dk036kggFKwvKs5oXyTNuoKgbiiSLK iOEZ2sLKBOK5wr1QZCo3DKi20ZTmQNVPpwRsHutwSh4jJoABuhobpigCqD1t2dMDu2thgdovWDON MQnoBLVbwPcf3oTIJcn79Xb8scwNdd+vMWiICihQXpr7BrHJZHGydBLs24CFW8TouR+b55Hm5ywH RrRaGopotQwQ0WpJGKLVfBCiqz8Ssrb0Clh64oinbuklnvBMMvUeayfPSkJxrZYH4lotF8O1Wg6E a7U4gmuy8+2x3O8vC9u1Wh60a7UkZNdqCcCu1bJwXaslwrpWc6C6pusBm96K471WS4J7rZaD9lrN Bfaq7RauJ42lJg1xit88UJV+iD9p7nii3ARh3NwVGhMe6F1gJYC8u46qLKhCIl+DrkK+dA1JKvM0 qDLLoRhjexcHMQYyYQzjteYU1ByRoMOwWGV+jiR9eSb0JRWqed1IRVNZyDQo1hzhyYKSmMtiK3eb QUnrdsuRSEvPNgMNqieYEYm0mJyUXKgVSXsHr5bITLaYzkRGLUZdZO4wE28wtngSWfNbK61dU83v Djx4rcexxBvkrIUT+BfI58hVrVKzE8/Byq014okbW6MYgApv6d0mHemjGFBS2pfUwMa/EJMYs2Yu j5Te72EYPqZ6/f7gzZfOw4bma6tAQjYoxriJsOBfAA9c5kCsqMbLIHDAquy9o//mFLQPaVfKPgDf iw1w1yDnXPo2TR8srqQp8cFqPcTfbZCfAmRMnFlJoBi6ba1n4+c2COLq+nnwg8hKXmxQ2loP0Wsb 5LAlz5n5Up9ydKxEbLJUvc4EBZ0N+FlX2Z+3D77QJ4Z6iuypoKFPl9XQs46WOSS7hrr4ogFVkJCl tZ5AOW0QBEf1t60fFVQSZ9iiVNfhhQZ5EaBiY3TK7128T9QOAAdtBPUtCJgpySYCctIS5LcNcnzv Smhi3KYg2jpKd9axxsS7L7ARs7S+dbVjPtn1zYOhqBJQZUVqpGoD3zcIYkP629oLd+iOkw6OIqoR oi82yP5XbOKup4lNyEy3hbtltrBwBZjL+XBLM6S9Bvml1fgiwfBgrG58Qcw6EGfjC0OWA9sCxcog 4KD/l2lmUGaZmbEU3KAuVzQnKLngeP3MK11lx6/t5cz2skyuiAm9rdSKtsnMOXz2LAFOxBbTlpRA T6It9H66HY/6Ew3jw8nTq72soDfIDzcXPya9etYf/0qHMcjaTQUSkc6jLs/mGP7m9S1VVOwexz+T h087j54lvf0DjpN3bl5hq9Eveoev6Zi480Xvu87A/F8ohxaH/niuatoa0qk16anVtDafbXtpu+4S mbuEljEUOkUoX6jqHDNRmPYlDE4lpNvnics9BVRt3A/cf5/3J/GYb6Zj3ieRG4p+CZ4GzBIB+wzx NUaryREWky/w3CO0rUcfcWmBWdF5vABPPg+ua0CpgPc/UdMBEmCNIYCcloW5k9hF2cUtlAk6n2X6 COZK5zzN5tGsP4eQS8Zdg8wgDTqyJpImwKVQO4aYHefT9RRyZM/FYeQGbtDARhLtKvTNgUhMAb7O DyM6P0pSMouZjFToX0w/onh4O00QMYFHM4Abtj/vX837s2uev28wvh1GijfMWDWGTZ5rVovYK0Jj q8hI9r+Io/GlJAeS4cFymKlLZl+gK3dYn2I5sH8IG0Y3tC78dLLNv+JvrkA/ZGpPRwdFg6onOhhs rOQXfR5EM0yeOcFoWbn1zDcsMR0IM+TZIpWTk9FOLCEKu0RqIJlycDqg9sWcx2XKKsVW3hlJVRI6 k9T5aRmWEu5CBFJyZBUEQOE5W0ASvLNEoLp0nFOdYczXk7GOhHI4uQLdTO2TAC2C2A2wj3gz4mAD VIUw5xBTN1Al+nQWofcQFIbtHGLLSzbm0cfpB+Ue9LXaCLf4cYORzuKskjEdQuP8Q8e1GUgD4TJ9 lDrEE4wwskb2Hjw/L/ms7Z+Ro7Maz+iEroofD4mE3To7OTg6PP+F7B+/MB8cHv9wdHx4eHp0/IOk db5/9h/k5cnpwSF5cXRGR/Wj12cEEvj+vH96un98fnR4Rs3bf7w5PTw7Iyen5Oj1m1dHhy8alOrB q7cvKCny/dtzSe745Jy8Onp9dH5Iyz6hLPwiCP1Cedk/R4benh2Sk5ecN1r2631I+Et+PDw9PDom Px+9emXQo+8Ay4dI7fTohx/PkRP4xbnRmAXCrw9PD36kP/e/P3p1RAs+OZX0Xh6dH0NNXgIB8mb/ 9Pzo4O2r/VPy5u3pm5OzQ9GMYJwNYJN8HA2vtOnH27zMXr5lIByig4JzOULnMp0AJgMRLMXResZ3 RoJHkVAGLlvt0PZmXLUZ/B9G5fW+Nhzuv9yVA/+ZrsuWKyMZ//lR98mjRxL/mf4L+M+dh2v853u5 AB7dC7pIsl4/yfXXN1ULayrnpdYm31RdqL3HDcSoSqXCYQmf4usdqN83Vd97KQB6zkfZewqU6IHb 44xkB9oLgeshmawAe7zUwqB6jPdlQPUwZz874YpElkLVUxVAGhxWL6FyuYH1mFRLANZDQgiuR8iS yHpIwoOuR7Ig67VqUtOWAdTDT7Nj47U8hS0DhxcsVgO5a+ldKCOuHR828FMb0o6Ty7G+9i6wgYyA sdM5LAhix/RoSjLi2PmB7JBIcSw72TkgkfRSeHbfsNgxlaKESyoPjF0Ix45JinJTDMoOyfiA6t51 3mfHqWNUdKw6C6ouCWruXfe9JpilUebYrPdNlU/MztzHZ9fUyfXdG9gQ7bz/pvq/ApN7yixqz8rG lJwfzA5l46CbcXKdVggdhrQy/ke2kVK3ZebDz/y9RukhUtpuhfJFZ6f0CCk9bLknTvVUilkoPeaU Oqlp2rJS6iYmDMrC0xNOabtAtgdpqxlZH0j+RnuKlB55RK0d7s1Ct7PFKXXCBzqz8ccpAVJy0jGU LJS6SOlJK1NschJ3HdZNnra8Iap55N5h3eRZS5+Fc7cbUmLdpLPV8kfVZafaeSz1SQV+LcfTE0nJ 3hVbnlJoKyErpadicljmv3ImlO4qJhQ6/PtHf81ALQj9hXTKAP9iVlk++C8ZMahb3IVRuJhhl47D xcus7KbAb/W8zOXH1TLsVh+yloxt0MWRB+XKwLhi1mkJOFdIqChwEhLR0a6WxrpCSgI2iZAw3hUG oPlhq5iK5ASu8iJX8TUAlXxu7CrW9XIAJgRaQS5kloGwMpqBLzqWBrH6ukPw9iqG4G7LMJvDa+HM IFGiMxRFieI9SuJEcdbKQIESXaw4DBRSYlBQBYCgkIoAg9LQoPJjQbG+koAHlYAGxQVcAtiTcIPk hnsy8J4YFacOSyA+Man4UZ+8mE9e0Cekkgr8lAL7xJo6AP1UxMwrd6x5uIqxhq6s/Qtru2sXgVli bV0C0BJTv4xQSz6sJeYSknn6CQbw5kBNUphJbLzKj5sk3FIlgCJJf11hWCTu/i+IjIRUikIjIRFs FgfkKB/EkZg2S0AwYqPMkhhGVK5s2lRARkvBGNmmPO+Q0oBPQB0yMIdExy4MKYRkNNXLDyrEWSkF M4jTmrK5uhBCkPAR6CBBAfL5AYIEcS0zTzpGkFl6EXwgUbwJcSL2PB9mnu7KmdIerWJKe9hK9PBy WRbDwZH6XwoSDlJKw8JJBMNhQ5iYZ/Oh4fiwcNjs5sfDYYNzKwusDV+ppkLbpADbiJ36bOA2AWgb IeQwvI3mASmGXiPNFJH+emn8GrHUd5KRZkOwwc8TUGyo3uxq6cx6NnoN607p+xxccqTX45kUxY3k VNDiHSeVonjgzwNoP9VzAaqCd1MSQ2uRKUvl+fN8nyHXn/NVtoSEPfXdLuZz1m7Iqhr36N20lHs9 BKTZ1RLumVTbDtndtln4rpNKundfU8fjFe2mog6zTqB0KZissiRFDaet/BNrqRhLbFWF4yK9hAyW uzx9pU/FQUa2mnMtTVV3Agdx/D1FZIfsWakjd2XeSPOL3baXnd22p9a7ZspI4dkvDHnDpwYOe7M0 6I2cq5yokrRt6fWg/6cc9Bf3MOCXM8Q/+Rcd4v9cg22eUTUEoxMaZ/WaaTg4vST4HH0Q1r/xaXpJ 4/fSYDh82zgzGo7jMFka6kbs5PBQxwJgN9pGiQF4kxPuhq2mbcgbNg8VCWqSYlYRTeuJ6ytMQRKO Y8UTUDlTz9N/0anna2jVn2PqutcFwZJwOMyWn6YD4gQQcfiSwhw/kzFx/ggbo89W0VkfuV5kLXiV t1kR3BkxAwtO8iHPmDsCxXBmhGJmgprxb4RkgZlRO1WCA20vJAMsjGiXhFhgzlxgYg+AudzHvF4U 2sUcMZ0Ra9eBdTEf60OeOToZpMQN4DaDI6/k3sxPSWz9a0y9uZr/67gtvuo0bd71qHhPgtDsOgg0 7tepbpFO0Cr12qWcpVxWQglGQnEAGWYjYJqSQhAyks7i0zQ3iIxAkWGLPlWNzDgy+GEClkxWJBlu 8Vhh0F9j2FvJ6bDHrcTTLrpSFcRUQUL4VQZUFR+sCnOF2NAqeYBVbAoBZUqGVkEiWeBVUrBVdOsu iK/C5V8IPoX1BBmZsDyAChIyQVSWglBBOjaMigaikh1FhTWojqSyDI4KUnGxVHIgqXDJJKGpJGKp WPWQNnRxuBSTck7AFJkGSwzldwUwU5CGxE3Jg5ryFdePfOhdyTmqJ60sxwP1EdiDSyKnJRdEhM9c XhCRIiK9P7Gv5OzE05bvLKVXzEtheTCxF8by4INSCMvjz9B8KwlHf9ZSZzJFo6XhM6xa28sS2EqC HYMHdf+nSW8l8T7qYDIXlzwdSoiGAtEgtUx4Dfaq04VvoCuU7w/e0M7TwDZAoAaC6AwE0RkEG4C0 wGgILIQGkXgGlCUPyADQ4eAAehCzuGgdsiTrpwz+vH0Ahl/DpiDbCbL0N8huOk6ATUHgBvRUPc86 vJ56Tn0qJJEVH2slktrT/xn55wP1TEwMLyp41gHSd6gMTlX9ddPTz+tV6IqmEjnZkWmZQh2nbh9f /DiKdqmTKYLLbgEuuxqX0vdKtDTlxExTTlSacmKlKX/RsgsXictzIaTZRDhgGu8MkGbc0LJnkn3Q kl2eqNmXWkb4R951Qy9aGWL+zrPK7MmkMtzhaWcY4ISdLNl410qHzax6N+813jdyW7Pk1nifZ7Hm 5bBM1SQp3fT9jLcrCb4JJV3glS8jgxSxU8MtlYuZ7XGUkIeZEZoXzcHMFnrAR4H8y0gEczAXzb3M Fx8s/3L2vMtm4mXuMjKSLy+TdFnzaFrM50u4zHdhvUmXsyRbZvVJSbicnGgZSaQnWw4nWebOlxyJ lr0JltlQxJMsy15VOJsydxIUyKQc7uG5UyYzx1nxdMmMocKpkpHM92/Pi6RJRhpaquSlUiSzycpJ k5yeHhlnTzMxMm8uX/7jwxz5j82eKXIf3+/6g0cEwX+e/K8AuvK4+6z1OR4vmd03/UrM/9vpdLsP n/zb1pPuk61HDx8+edKl73e2tx+v8//ex7X7FzBuK/84e3XOhlgt1APiL8D8pvqBDnV+Bo0OvT+e v37FTGL2r2b/DDbRbHLtTrKRZBtu6uRYvlU2yrOpCnIB0nGT2scT/UW+X0MHVdol73b0R8BEc2u7 2X1KUoxSvRpDcPb253MgS6ch5gCDc5R4bBfP24qzcwOAvGFnAoWFEZONBa8Inb0gCKRFXo4+syQz cK7hM4twYukZZLkVxuvDZqebndfXU0hxBw1BqNE0u+WT4j/wjvTlyWKaTVwm7NJ+vhMv7sYRNc7o kCQ21ce+XXVYyLSpZrTPhWLo+/H8+sgSa+7VYA1ONUkAQQnSfTpNS+L0XqtP+bqOsAB8qNGsqO9u YmSKWrY7bFEYNyUeWJNar8DzAsurVNgXcf/zVJU0GoxZRALc9bDNS7mD1FUZcHTkqms+uJTjpUu2 Qq0tMC0hTfTteNFkaX8iKAPqQ7DCBHkiULZegWALfIZQAbcs1Z68/dlW0V6NUquRiEM87tVG8bT5 9OmjZ80OS89lkaE06BAgzbF4eiPDuPg9mABFzlc0nHgKEzbLvebJMsg57enUnqyLCBTKRpfOLpTi JWwRUQs4iuTKHxSBymh6Ox8wVegR1FCDJ26nwxlhkfKT7ZnHcG62H+CP7P6dFvt3QQz90zHbTOI7 7mBRD/Zqd1Fca5EDdkaf9qb5HBKAQZ3gGDUMiNCxqVSpbamY4zLHRxzvh/N5Ph1Ae7JT03uY9BUD 15q4c7nBvq9IO3ajrfhvavxv1Cn79c133BCMN1qNOvBb33zfIPW//vftdPEdqdM/65uaY4W/Qhlg KdhQgODti+9uLqYwesoFBRsdUGRRfwhSpaMbXfIM0IVfVLS0PFpSvIR4PZKlFThj9FYlWcFuinTV a6aE356+Erm9YCYAv2orWBta+tv5+A2+XiOiNvUlcPLqItMeZwM33uiCYTyDFIcxP+4wHMHqUecG 8h8KnaWzUfNyNI8XzXEE+ctAwnR6H1zTh5RFPuDQFtirKclK0W88p+upm0an0dls1PsXA7rgu7oe /deH8c1kOvtvSvX246fPd7/WG/X97w9eHL784cejn/7j1evjkzf/5/Ts/O3//fkfv/wnFSavhpc5 KCCBKWQglUCTcpxCiKrDoL/gFaq3WvXGc/7RpiXm8+hmNu6LHHgs1dQcwizUdjok9uAm9XAx1Ac1 bcAFZhecFuFciaTqIngN0Vr4PYRpoRXAD/sQQNFcSFaAw922TlJJxClkjkgPNSRG9bYXoLjbhoc5 6KLvkZFdzFWVK4An99dvtzqPt75DwDSY7xDDDqjgdn4TshbxrvAc4A6gBdmR1wUPZ6sgzFpB2rpb JEQePoSMDFFMP+gzN2p7NqUrhHGbtgQ1mETrWKx4eVHMUG1pRtTqkcwEaPs5byG7F3NkWien1UFW Av9i9Uit0gBBw5epkMMj70OeAhowmDasB/PoCmL16u4TSPCwqbVPRbVO5mpNbyeLeaBmQc1JqFyA vqFE+dvgegrIx0k8unCQb+CjHcn6RS8X+1hiAtdZ2I7AWM7LNtsbCLNtAVr+ZhT2e6hfmCxhvfpF WuR2PspbsbenRxmq9ZtWQmptgIscdcGpQjLr0WxRAeC/bQ54WUd3iImq4eMKToOUVd09LZbEaExA TCV8B1Ydi3WEeK7ZjC6qeapVvopltr/yheJM6Z/hhIhUmXIlw+sDXE2izwvMAGqmhsR4Ngz64iXV Y8LxauXszIod0FWMLFUaEnE0X+xzfFu5ftIlAWsf7oCezqgtBVjXXCQ8gwHZBQn2slTxb++g3I3N v+zVVW3r74UdUuHrImCKe47BqQCJ3fAPWj08yIqWuTI+TH2npiZYQFJlkut+BIRVzTXVE+yo3YtY bIvFVtlh8tJzZC5OsytnxOtSUd3t+aI/v4oWoqv5zJu+T/2JeQUKvBxd3c6jWin22OWcLkVE10oW FF1dvhpNmOnG3oV1V9O3DgWgdLW+gGj6DW7J8pHDKMWquGpVjMyxD3+RcXQJ24fj25uJamTBPpjD uFRnDMG7B/iq0jZwe+yAca2Vy+uOabgsdnhVMfstai/Yrwh8EhpI1QvSYILPvXTlxmfPi4HGvlYv mSS4LG2ud9u+KhauNy4An49m1MqWmzkvTvdfnhtVBG+SVbNTcbyfNt4Bx8zZIX7ZsUKYs7MmpJer /pVA9c0RCIuhA/Ix2PqGQHwf45O/jhffJTEtqNFG/+vV4jubVS9T5jQa4lNAfrFtNuseHajrGWtw Ir7ZCQ+KlDjA4dTc0YgEOj2+LmUxwTMLo1+jJrp/NyxuN70uQJI+KqQKsFLxiY4OXHQ6Op5mlFC4 O2gCsLsExK9dTed3e/WLwYy2xfcHb5LVWzKVND5kKhDGRlriy1+O7qvEeDGkBZ6dv1iywIpbmure iUs7k5NGfYeu3czCNlVp9pABo5J/tCThISNb72S5FPS+ye/k6Jlv2Rf33i85p6vrlfJWoOqVA96e VkBfmtHGv3o1hWPZ5slcvST/oIBzmL9dJOpnkAFE+LsDsTFtyyAA9lOYJj2+tU8SrRxmz7pmjhSO Zeng+7ap43f9SFeZqUBSSM/j2/nEmhdtOSX21OejyWgx6o9j9K8IcptheVkyEyaEVcXp/Ork8qU4 2a9Um/uD5Zn/JgTq0v/f2ZlMh9TybOuet/bz/gVgcnhU3pQCp+r9lvxljzyw2BG2T5qMfAT9kqnY y2wlJumAy2TfhdoJlLj9HMFHsaXY7zu6Ujal4xkfHZXWtNNaIXINj8xlsWG5s921T6Phgi5JHj/+ 9xq5mM7punWvtlUjg2g8njFcjb1ah/2GMYz/Vr3cGdqdyUyEzDT7H/ujMRS6Ucd9UdSUZhwt6pue ETa8Mopu4IBZn7Jas+c2Eh6YB0p3zdI3HqgFCzaBkmolne48ga42PFiEdU1LGuor2jRufp1Z1Ljt nCzqIuLOKHKTi4wizyh2m3ay2C3RLi39Sibp49Y/8laG8D2fZhG+wURY9k7TZpC9RTqb6OFKlX4l i/SVxRksacWy1aRZWJi6+EqSXoKAPLY5brtocwvbflI+PwjEIgtwNGmevuHoo+0ipzPFhAzG/Tje q+HrIa8NewjzMHxC/48Sc62usEnKkp/YTkRg97rTs3Gf5X7qDKevLNH7CastdOK11ewNTGy2AnH+ rM1mmssv5AqWG8Lcc5f0LoQIKB+xYUg9UNEpe/W7KK7rU3aSt9HwGHKHb1a/5kg5ZbkP1kAkoAyj gfstFV8L3m3hSxwbA13otP6TO+mCkp+HXLd8gx4ByJV4htEMkKJ5pgR8iLFvRkyEzTu89u45vrdX p88Wd3UI5KYi3mB3N9+zql2Mp4MPEDAiV7lBfzBrdeODrKI02IFwR2p41cMcDMfKfE3ihrareLVS Bmes7WIPZ7vTsRwBos+LWqqwKD/Tca8Mpljsk2TqNicj0Ga34wR1iwEUEkNBNijBTRUFUlC/2oua HJ6yKNasaKsBA47QBBfjUUY28MViei3KHC5CISLw6jk0Hy7ahiIf0e5wmJFLfDErlzej4XBc0mYP DtI9PiUFasemQawaTlFy5itSMMYt3FyIeqxCq2bzaMUlyO3QmvDgeL0UbOtPM+M8i1PXYH8uPgs1 C3vseFNdSswZekSX2u3nyFH99OVBPUSYewIe6JGBDUXinUbiffs5ft6otxafF/XNfMy8g1MOi7gJ VieEPQJFNo95jVPbu3U5OKUTulpnpdFl47hhp3rr71lcc5H4LfiKKSl9CV2pWGGhZMN2uj5g9dhs kDoxwjutUriEXdnYTquK0QBOddWxSm3WNbSx4jhyKrxv2JFumGobLOvFdGY1G51tneVqn7fcb8/Z QYXfw55rr7tbdDafI5LJ27+IgfWf0pOW37GdYcEN7/TtarYvdJloIX+JwvF6YZnNroUtVkJeLIeW Pmx4XLUeSpUEV4ki5o2wSrgqqWFTqSQUH3K5YPhHwUzaCLkqwsRsYz9x4ecr0DX7TflWvL7ZpCvZ Yc6bkYUqSvd5YFvGqbKtqM7zwBihamR5MJLLTHYqL10Xx00QcoRYIxheYcqmds0AuxIi8Tf/skct cdrWpEk6tV5DxqzpuxAVe/9IfW58jXt/YYWoVOx50p0p86l9+lBhvunp5TzY0BwagLFcQYNuUHNf ii5d8UrSPJuJVaiZJqGgTtyjSpGUfm0L1ieVYBVDe0wV/R2rE4oHjgXIDKIxpvndeMDs2E0CETJk i098gmZN6d4DM4LOaXI2fWqLlX6v1hDGtV8yybpGv6plKqrmMdsSVCoh7MByqPrtBGXphjem8lgM uMrH7VjUMPyJVWa/W3Ls8Quj5bP6HckGFjHiYIXoGP638E44ksOVO6+/0S5BHQ4JPtDs2hZpKuc+ N6xK/lPRwqF5+LN37Zm2+oxrmpGe6kMVEZuaLjhu/9tQsKamvpalLMrvq/VZy+SQFXjd6alEYcqj wE0WudTAlZ7a8s2yeNe2B3Is4S8H3P+xuBkrJqO+k7Yau3vWsYe9jHZ2ZZf5d1mWbMyzPYhju+um Ob8P4tidx3bbSFq/SyXKeKflAqZEzx6gQ+56FvZrFJH8AXdD5fgCY/at0ByNx902bwOr7awentAj FsopZnkLQLuPWQipoUo+gfNAeeaHfEM/tCPN/TEOpoPJChqRs51iRM14Rp/hpbd+0179XY19cuZP 6wpeP5YjSueGV66cJ+nl8oYb8ZeUlBM2dAwRZxOvIVSYoyB/MqRY2Nnh1Daz7iIZI+AyQ2CCt8A4 0xMWFnjlMemwqY2p4Sp4zstTdbIHinTd8Zs5OahQO/O6m0BFzb3X2+HZ2GPhpLWtSBPOfUQPhIR+ VyLydxND74LWofmaMBBbfPbWODeNWOO27mVhLizJm8mg5uFK96lrK3V3VejYp9K0SqBpu6i8reSz Qtkt3hI9rXGKePo/UyvgHQu7ex8cn4Uz2+PdDnci07HXbv/tHZf7Hl8rCKevXER8a68iQudw3CEH t9VhBmsrq0b96ZYstTa+nfV24xs6VPSy+zZxBbSMP9M3MFEzgRXfBl7gXX2UWvLIEW/WxQZr2j9W 2+YbVMdTKq8mHnJ7AOVu7tX5aFF3zLQz9sCz8PCu1ZBe2M/NowvCkdaB1UqmAdpnYOZygzp7FVCZ tmbrahs+Preo1gbpOp9F1/P2Qcmd3R9yzVtJwR03/fkHcjvBPhENdSCFYeKG+99qwly4pNKEgFjK NxXJkApiseiFDxaxo5jiRBFdaCxodYCG3pfg9KN/fFNNC532n8//pskIPkpjqp2fq6zzRFsNIFn5 d5j3Lp71/1gKmgXDb1FkvU3lDTDFV+xwu7b3yXxghj+5g8N4oKKoyT/Jg7n2W4Sz+pcz01j1CuUu 1AxUO+KKvkSgAQmz/YyiN8n/Jh0It3Demttv1XpOlK99Kl3cHoro7e1tiN6+4ur07WO8aiLsRchW NrxhtelsvgP23rdV0zvpEiplFTvPXqxeaS1tgZSDfsTfHtIz+HqcEyahWZYdPwkEAeoqaoYd2HPh A829tVf/qT+BZI50GvzpdnwXcIs9MP1bztyUUobIGEkL4SmOV1IM5oWHc2rRjAoXZt2VFLM/m4/G tJiTwWK6skJe90Fax9OPK6zIT7eTiBbyIhqstJAxKhdTs/QycAhaplVQseBYpEhPurKipH7R0hgW wcqK4joGHQe0bnUFCU3DKq1QdkLZcLyZRAUKkqaQsvJ+Pj05/oGc/XJ8vv8PzLv7+uT4/EevLWiv jUPW34wj3SBAk0g5gqnnWBSHe7zJP7ybGT16TlaN8WjyAVKcnp8c8ASEkA4AgAB+hbRxYwLeKj2V x0o3ABLi+z17AH1VK1Yg5BCzYAFMW4XZHtoMxkhwfyk1QWDfgM+qYgOBbx84J8eePUs4ObZlnRyz thkce81hyT0xGbJXtVW6awZoGxd+i0BTBU9ik3TNUglN7ku38rtVvS5VflxC16eBXhepUSEsBGeD CUNBhRGo0WLae7/nLirq0IWPJWCnLPQFvMqAYCA8rz5eBXEYTMSZImAMDIhB0SqIyCDRGDTZZYVl MFAZbEQGRW8JaAYvLIPGYS58hhA2g6KXAaQhFaBBUUtEasiA0qAoBeEa8kE1KII+zAYNryFTLy0H zQGvgpAOyw0qywE+4FUW6gNexaEfAPZB0SuA/6BjP5gE84JAeAAgFMEMSBBak4LxZKJC8Bku3N44 R/pAI6K8oBF4eZAjiNxwzmDAHNC6soAIULgMtguLldj/pvobrSOETzSH0WDKgCR3aO+ZUOZ+py/s XENC58BrmPOOmjri3f4AxuxML39/8uIX9iK6knbIt4gRITYNwcvZvOzfjMZ3O5Dt+GNEh+U+nWTn o/6YjuN02GlCxNal/n48+jXaIZ3t2efvsIwfO2YJ23h5vniMX+CoRflrXkfQysb9PPxUZnTYa17M o/4Hdj5hh/Q/TkdDzlQ3rdqcqYerKHw7Y+HbKyj8DSv7pj+/Gk2acIZ6h3SjG14Ovz1nomf34aPT Q89n2/Izs23xEzogvOIfWVVij1+0mJvSFMUlXh5RbPlFweuvScRRSnZWYQeyRWLJysp2udvi3LWu pws49KYz5+HtE1dRtpnEn3i7sY/3QVo7apw9E4zBkqabka2L6XiYl6l8vVyyRcdcgynmkb4npryC wk08U7mePfP3s27XP/Jo9xOrwBUMdYrdr2RmH5n9pvr8hs5YAANAzTfym+Zlb02m/CZdQ9AZ5G4H hPQ7fhaejySOispZKlw4qZMSS0D6519Mj0Q90EgA6wJr5l0166kXvDsQY7DuNQyBhAz8ujfEQ+nW opSQrl9koiB6NJsUmevCwTyz70TbN0fDjRaEPek3PkR3G3UXi6DeSIEceIACaDxA7jdFRATnhBrq C62pBCH2ufmlG+epBwg5222YX9ndgSPsEJ7fV5GrJszBap/nI/p5N3fjK1soe0miNk7LLSVpsWtq bZtm1ROgDSebYJtUHtLRfIO+Zgu3G6nwLUYnOs1pAG/rShSKtO/TW0Wv2DuWDoDDULDj+ezHXr0u lL1YM5gCSjjCJZm3Rg7wxI9x2EzN4yG3DayYRIsHsdurzqGIMkQMWaYA15QTecQON3OPENV6jQwH DBPDhtRLjur5ejBcWQOdQjojVAQdA+LHX5TCqPIZooLYxdc96wafZtdI6ihufjS3pwgklqTOYgaB ptVcgLvUGwkYLptab7mn7lK5p/5yfx0m9dBdth6TfC6I1crqMP4JD65UWqFPvCxaU6hJ23xRmQg5 t5cSPC99LaNqxvCRQPpjyPV9wHxL5A0kkMKEV6E92/TsxkfKV9kfL0WIJy2WvuRzytWHLNvIG4IG QTcvNe/pRHg7AZ/cZNPdTc6wlZzcCjyJWE8evaCmObvHIPFGMXkd3Uw1N2DWVuI5b0GZZ3w4Mj3D 6M4lFmg5jOP0gS89gfcUsyyLWk91wFLqbnUf19X4N5oQuAsuZ2xTAINjW+j0JnohY7HVxWNvSWcL fgEKKCXVUh3FOWCcztBk+kLu4ECa/bhk7gQdvpkit6PYFg5dKYoQAmc/jsoYdgb4FkKr1EoeTz/9 EesoCG0cXVq7ZxfRYAr4gLAPyLb8yNHh+UskA10QsRUIOnUB3kkQWoBARgu2z3IRkQv6GvCEqKS8 zrTLjVSV/Sq2WUj4GEclWIL9g+nlJeK2wn7fYDCdD1PKl/URWzU8umQ4jZgAubOe7RehXLD5JneE b6pxSHYhFSo+aBa2Dws7ZU43b6XWVw1yByds0+T44JC8PaYL9aPjwxeekVDSkgMGu2mWHOM+mWhY oQGxwP+U2w+HkJ0riuaIWY9jVz/+QF5OAcBnA4Sw2cB9Mkqtz/e84aehMTFXueMpuoGo3rIdQPYQ 92j743iqbU17GOvH3mq0wpUb4kCqKID3lW2v9mmZn0c3tzdQ3Xj0mWBgFC8AqsA31VmS9mGDzKMZ 4hLjlqeAVMBNG1YTjc0FKsRidBMJ1nCEH036M6o/M2rTgRCmCNDpcB1rUJ103o3ARQdF0vcH1ERl BGmJN/oeKv0KkU9wB38+vYJQn1qL+wtmztTDsyECoio3FWw2Bgy4s487n7CvuuBqxW3NuoZWO4oW l4jiCn+0O6NhUySvjDGVUi/7u3hSLAPb1kx5dt0fTj+RF9SoHiymiIG0VAVipNOCw7F+rrUXklml zW3xiCMjRhdHsK8bNM/NFPd6CYbVyUcJ5bJMswwVh7o5a9kh8SwaQISEMU4Rr1EpNzhV3ABUHTBm bicwNeBAMGfwMzF07MEtbtbj/fj26orex9kO4UpvYGRlRzp4p3khhgIefILz1A01wKAv3U54FEDL qE+CpNLlRCWfIicsnYVNoIQOP89o/8RAnDEVzHQxHUzHjmAw1gdlooYDOaEwid8Z8hZxHXrIjRJK RjHi+MfFHw3LkWleiTJk9tEgm1jjAWUNBEvEdzCW3YtMcwqlkJrxhVWqQLipETvoFOXLobK8dpAi omBLwwIjk4qAgjnkQ1hfWAUHpQ1Ob8YRBFjhVC0iwMRcCtEeUoIRYajSkuWTy8vRYKSNF4ygXB9z EOqNs/MXpLMpKyJqysPHWEwq49ZYovKmFIJokSUaNV29LWuTNt7b47O3b96cnEL4z8H++eEPJ6e/ tMTM6D8G6JiouXwmkKNaX4avFjqPSLde0b1Bd2twwWrChH3d6Z0LuPsDjqru3SS8ZUuqPsv+hn/I I1ecYnhrjvsA/9luW6ltbNemz5PppJ+QepM7DYU6iK8nwczChJPpVZbuxdNzUzHhOUoDZ7PWMzPp mIofJiUzFAQ83/yx95SG6nJmD9ETLwTOZnjSLPh6mS7kULaxvMKfBJu+gPD/+m3n8ZPvUtfAXqdx brXTvi5JbPpTn76y49+lSuzUr6qJihXQUS1LRunSuDCJBDNEuCpu7lE420ah/BwPBJyEvptvbKtX BKKFqJTuxBdD8YXxvWTbOGojlFZyZx+4ARKi9IperLGjokB5K2bZFU/hPJTEKRoDSlh5skBZotlW ArQxoYpaZKtTUugMSKCyCXn0k6Z3OWs757398/Vlfxxrc6/9EZun1TN1Yhuf9Hav52L+5FFOlPTo 1whxr2DhH+E5JiM9lDgDZX+X9RxUtybPUNNHLNKLlveoZiGp6LsLLrYHzyxhbJPh+Wx1JpsFdUqy gwjM0ZrMnCx+e5jZ3qrpSoKRLjquy+nLg5rQC/q3PLLNgVzo2xdO2g3I1KaR4OGNoWHAgaVF0sb4 s1Dp/2G30FRyv9B0QBQusAT5sWA9R37+xnMqa3QsMM7Iwav9szOAQZh86AKWvBAFv8GleH5yYODL 8/SuNra7uUFqnoNn+5GVHCfg3Qw5TldiuUIyH3S/jaOzuxtKNxYifxca8CHtiWYwvQ+ca7Xms1Ay mHf6BrukJsd631xXYBdRQwn1JK9AQNCsIuOnQuKNB/Bdo94wIcO8FgYtHiBfZe5SmQ//IqI1jnRS ViZBGT/gBSR4gIQF8EB4subls7m6YTObA1Y1sEhLhlS10v9rtfWBTQaP1aqnyXvT+drigWr9lUrd nuZTVtyZhwTTjPbrsE+NVd47TEjZ07sjnj1WCQ9F/MvN7XgxmsFMzZxee7X9Vkf/L3QI3TswZCwr ZPZmOJyeJi3MatkTwctX4LPiG4+cN/TDMTHJRzy5EZxspLKkxgOBw4PkcnR1O4/Eh1pss5zdnESD Keesnfffdd7nCR1qzVr2mOqKffFPxrjoAIkp0ZQfCI8uxddRtOj92/paX+trfa2v9bW+1tf6Wl/r a32tr/W1vtbX+lpf62t9ra/1tb7W1/paX+trfa2v9bW+1tf68l//Hz6sPbAA4AEA ------=_NextPart_000_0024_01C1200E.FC578670 Content-Type: application/octet-stream; name="diffs" Content-Disposition: attachment; filename="diffs" Content-Transfer-Encoding: quoted-printable 19c19 < --- > 90,91c90 < instance of dates). Servers that support searching can also take = advantage < of known data types when doing comparisons and sorting. --- > instance of dates). 115c114 < WebDAV and for properties of type --- > WebDAV and related standards and = properties of type 122,132d120 < < Note that a particular property can be typed for a number of reasons: < < The property is a live property with server-defined semantics = and < value space. < The property may have been set using a non-WebDAV protocol that = the < server understands in addition to WebDAV. < The type may have been specified in an extended PROPPATCH = method < as defined in . < =20 < 135c123 <
--- >
169c157 < --- > 216c204 < --- > 234c222 < Does not parse as = xs:boolean --- > Does not parse as = xsd:boolean 243,292d230 < < Note that similar error conditions can occur in the standard WebDAV = protocol < even though no data type was specified: for instance, when a client = tries to set < a live property for which only a certain value space is allowed. < <
<=20 <
<
< >>Request < < < < t < < < < ]]>
<
< >>Response < < < http://www.foo.com/bar.html < < < HTTP/1.1 200 OK < < < < ]]>
< < In this case the request succeeded, but the server did not know how = to < handle the data type "Z:custom". Therefore no data type information = was < returned in the response body. < 304c242 < The property's data type MUST not be defined in --- > The property's data type MUST not defined in ------=_NextPart_000_0024_01C1200E.FC578670-- From w3c-dist-auth-request@w3.org Thu Aug 9 15:33:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03633 for ; Thu, 9 Aug 2001 15:33:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA01862; Thu, 9 Aug 2001 15:28:40 -0400 (EDT) Resent-Date: Thu, 9 Aug 2001 15:28:40 -0400 (EDT) Resent-Message-Id: <200108091928.PAA01862@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA01798 for ; Thu, 9 Aug 2001 15:28:26 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA13687 for ; Thu, 9 Aug 2001 15:28:26 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA464074; Thu, 9 Aug 2001 15:25:50 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f79JK5787726; Thu, 9 Aug 2001 15:20:05 -0400 Importance: Normal To: "Lisa Dusseault" Cc: "Clemm, Geoff" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 9 Aug 2001 15:11:56 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/09/2001 03:27:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5250 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: It sounds like we all agree with Geoff's wording. Lisa did make an interesting observation below though. << This means that LOCK can return 201, which is important to distingusih between LOCK of an unmapped URL (I can go ahead and put my content) and LOCK of URL that somebody else just created (I should NOT send my content before checking). >> Do we want to enhance Geoff's explanation or add a comment along the lines of Lisa's observation? Or just make sure we mention 201 where we list potential error codes for LOCK requests? J. From w3c-dist-auth-request@w3.org Fri Aug 10 04:31:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01381 for ; Fri, 10 Aug 2001 04:31:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA08321; Fri, 10 Aug 2001 04:26:57 -0400 (EDT) Resent-Date: Fri, 10 Aug 2001 04:26:57 -0400 (EDT) Resent-Message-Id: <200108100826.EAA08321@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA08299 for ; Fri, 10 Aug 2001 04:26:43 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA20651 for ; Fri, 10 Aug 2001 04:26:43 -0400 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 10 Aug 2001 10:26:07 +0200 From: "Stefan Eissing" To: "Jason Crawford" , "Lisa Dusseault" Cc: "Clemm, Geoff" , Date: Fri, 10 Aug 2001 10:26:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5251 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit For me, an addition to the Status Codes (currently Sec. 8.10.7) would suffice. A la 201 (Created) - The lock request succeeded by creating a new resource and the value of the lockdiscovery property is included in the body. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Thursday, August 09, 2001 9:12 PM > To: Lisa Dusseault > Cc: Clemm, Geoff; w3c-dist-auth@w3.org > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > > It sounds like we all agree with Geoff's wording. > > Lisa did make an interesting observation below though. > > << > This means that LOCK can return 201, which is important to distingusih > between LOCK of an unmapped URL (I can go ahead and put my content) and > LOCK > of URL that somebody else just created (I should NOT send my > content before > checking). > >> > > Do we want to enhance Geoff's explanation or add a comment along the lines > of Lisa's observation? Or just make sure we mention 201 where we list > potential error codes for LOCK requests? > > J. > > > > From w3c-dist-auth-request@w3.org Fri Aug 10 06:20:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02655 for ; Fri, 10 Aug 2001 06:20:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA11417; Fri, 10 Aug 2001 06:15:57 -0400 (EDT) Resent-Date: Fri, 10 Aug 2001 06:15:57 -0400 (EDT) Resent-Message-Id: <200108101015.GAA11417@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA11392 for ; Fri, 10 Aug 2001 06:15:51 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA28864 for ; Fri, 10 Aug 2001 06:15:51 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id LAA16834 for ; Fri, 10 Aug 2001 11:15:47 +0100 (BST) Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id LAA06998 for ; Fri, 10 Aug 2001 11:15:47 +0100 (BST) Received: from eurgbrbh03.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 10 Aug 2001 11:14:57 +0100 Received: from gbrwgcpf01.wgc.uk.xerox.com (gbrwgcpf01.wgc.gbr.xerox.com [13.200.2.141]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id QSHF0H4L; Fri, 10 Aug 2001 11:15:44 +0100 Received: by gbrwgcpf01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Aug 2001 11:15:47 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB776728760D@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: w3c-dist-auth@w3.org Date: Fri, 10 Aug 2001 11:15:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5252 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: Since the general consesus of the list is to do away with LNRs as we know them, if you can't beat em, join em :-) It makes sense for 201 to be the response for LOCKing an unmapped URL. This was discussed a while ago. I think Jim said he would add this to the issues list. Jim ? Regards Shaun Hall Xerox Europe > -----Original Message----- > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > Sent: 10 August 2001 09:26 > To: Jason Crawford; Lisa Dusseault > Cc: Clemm, Geoff; w3c-dist-auth@w3.org > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > For me, an addition to the Status Codes (currently Sec. 8.10.7) > would suffice. A la > > 201 (Created) - The lock request succeeded by creating a new resource > and the value of the lockdiscovery property is included in the body. > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > Sent: Thursday, August 09, 2001 9:12 PM > > To: Lisa Dusseault > > Cc: Clemm, Geoff; w3c-dist-auth@w3.org > > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > > > > > > > > It sounds like we all agree with Geoff's wording. > > > > Lisa did make an interesting observation below though. > > > > << > > This means that LOCK can return 201, which is important to > distingusih > > between LOCK of an unmapped URL (I can go ahead and put my > content) and > > LOCK > > of URL that somebody else just created (I should NOT send my > > content before > > checking). > > >> > > > > Do we want to enhance Geoff's explanation or add a comment > along the lines > > of Lisa's observation? Or just make sure we mention 201 > where we list > > potential error codes for LOCK requests? > > > > J. > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Aug 10 12:28:42 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07523 for ; Fri, 10 Aug 2001 12:28:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA00346; Fri, 10 Aug 2001 12:24:14 -0400 (EDT) Resent-Date: Fri, 10 Aug 2001 12:24:14 -0400 (EDT) Resent-Message-Id: <200108101624.MAA00346@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA00307 for ; Fri, 10 Aug 2001 12:24:07 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37127.rational.com [192.229.37.127]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA00997 for ; Fri, 10 Aug 2001 12:24:00 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 10 Aug 2001 12:33:04 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 12:33:04 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103DED629@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 10 Aug 2001 12:33:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5253 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I think that adding 201 to the list of status codes returned by LOCK is the right approach. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, August 09, 2001 3:12 PM To: Lisa Dusseault Cc: Clemm, Geoff; w3c-dist-auth@w3.org Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC It sounds like we all agree with Geoff's wording. Lisa did make an interesting observation below though. << This means that LOCK can return 201, which is important to distingusih between LOCK of an unmapped URL (I can go ahead and put my content) and LOCK of URL that somebody else just created (I should NOT send my content before checking). >> Do we want to enhance Geoff's explanation or add a comment along the lines of Lisa's observation? Or just make sure we mention 201 where we list potential error codes for LOCK requests? J. From w3c-dist-auth-request@w3.org Fri Aug 10 15:02:42 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09950 for ; Fri, 10 Aug 2001 15:02:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08550; Fri, 10 Aug 2001 14:58:39 -0400 (EDT) Resent-Date: Fri, 10 Aug 2001 14:58:39 -0400 (EDT) Resent-Message-Id: <200108101858.OAA08550@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA08524 for ; Fri, 10 Aug 2001 14:58:30 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA16299 for ; Fri, 10 Aug 2001 14:58:30 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA449122 for ; Fri, 10 Aug 2001 14:55:54 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7AIo8o48534 for ; Fri, 10 Aug 2001 14:50:08 -0400 Importance: Normal To: w3c-dist-auth@w3.org Cc: jamsden@us.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 10 Aug 2001 14:41:13 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/10/2001 02:57:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: rfc2518 issue: LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5254 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: It sounds like we're winding down on the locknull discussions, so here's the next issue.... Jim Amsden brought up the following issue. I don't have a record of us resolving it, so let's do that. The specification requires a lock to be refreshed if any method is executed, by anybody, on a locked resource. This can cause some performance problems. More importantly, the semantics of this refresh do not seem to be right -- why should a random GET by a third party cause all locks to be refreshed? The text in question seems to be: The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. In section 9.8 of RFC2518. Also... contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). in section 8.10.8 seems to be alluding to the same behavior. Do we want to change 2518? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Aug 10 15:16:26 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10159 for ; Fri, 10 Aug 2001 15:16:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA13360; Thu, 9 Aug 2001 06:26:21 -0400 (EDT) Resent-Date: Thu, 9 Aug 2001 06:26:21 -0400 (EDT) Resent-Message-Id: <200108091026.GAA13360@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA13183 for ; Thu, 9 Aug 2001 06:25:58 -0400 (EDT) Received: from w3cmail.inria.fr (w3cmail.inria.fr [193.51.208.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA28636 for ; Thu, 9 Aug 2001 06:25:59 -0400 Received: from sophia.inria.fr by w3cmail.inria.fr (8.11.1/8.10.0) with ESMTP id f77JLHZ06059 for ; Tue, 7 Aug 2001 21:21:17 +0200 Received: from inet-mail4.oraclecorp.com by sophia.inria.fr (8.11.1/8.10.0) with ESMTP id f771wq719196 for ; Tue, 7 Aug 2001 03:58:53 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host inet-mail4.oracle.com [148.87.2.204] claimed to be inet-mail4.oraclecorp.com Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail4.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f771j9t09132 for ; Mon, 6 Aug 2001 18:45:09 -0700 (PDT) Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f771pVg23659 for ; Mon, 6 Aug 2001 19:51:31 -0600 (MDT) Message-ID: <3B6F49F0.79D63B5@oracle.com> Date: Mon, 06 Aug 2001 18:52:49 -0700 From: Ilya Kirnos X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5246 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan Eissing wrote: > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, August 06, 2001 1:13 AM > > To: w3c-dist-auth@w3.org > > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > > The full proposal I advocate is as follows: > > > > Delete all references to the term "lock null resource". > > > > Instead, in the LOCK semantics, add the following: > > > > "If a LOCK request is applied to an unmapped URL, the server > > MUST automatically precede the LOCK request with the creation > > of a resource at the request URL. > > This automatically created resource has the same behavior as > > a resource created by a PUT with a zero length body. > > In particular, it is never automatically deleted when it is > > UNLOCK'ed. Note that this changes the behavior defined in > > RFC-2518, which stated that the resource MUST be automatically > > deleted if it is unlocked before it has been explicitly updated > > (e.g. by a PUT)." > > > > I believe that this reference to the old 2518 semantics is sufficient. > > I fully agree and support the proposal. > > //Stefan This sounds good to me as well. -ilya From w3c-dist-auth-request@w3.org Fri Aug 10 15:24:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10281 for ; Fri, 10 Aug 2001 15:24:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA13468; Thu, 9 Aug 2001 06:26:42 -0400 (EDT) Resent-Date: Thu, 9 Aug 2001 06:26:42 -0400 (EDT) Resent-Message-Id: <200108091026.GAA13468@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA13284 for ; Thu, 9 Aug 2001 06:26:11 -0400 (EDT) Received: from w3cmail.inria.fr (w3cmail.inria.fr [193.51.208.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA28711 for ; Thu, 9 Aug 2001 06:26:11 -0400 Received: from mail.gmx.net by w3cmail.inria.fr (8.11.1/8.10.0) with SMTP id f78CXKZ13950 for ; Wed, 8 Aug 2001 14:33:20 +0200 X-Authentication-Warning: w3cmail.inria.fr: Host pop.gmx.net [194.221.183.20] claimed to be mail.gmx.net Received: (qmail 2209 invoked by uid 0); 8 Aug 2001 12:31:19 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail10) with SMTP; 8 Aug 2001 12:31:19 -0000 From: "Julian Reschke" To: Date: Wed, 8 Aug 2001 14:31:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: Possible bug mod_dav 1.0.2 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5247 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I was doing interop tests and encountered the following problem: a) Set a dead property with no namespace, for instance by: 123 This works, no error is reported. b) A PROPFIND however returns XML formatted like this: /test/UTF8.TXT 123 2001-08-08T12:14:01Z 32 Wed, 08 Aug 2001 12:14:01 GMT "c5077-20-3b712d09" F text/plain HTTP/1.1 200 OK Note the invalid namespace declaration xmlns:ns1="", which is correctly rejected by MSXML and AElfred (Saxon), but sadfully accepted by Xerces [1]. Also note that the prefix isn't actually used in the property, so maybe this can easily be fixed by not creating the namespace declaration at all. [1] From w3c-dist-auth-request@w3.org Fri Aug 10 15:36:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10532 for ; Fri, 10 Aug 2001 15:36:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA09930; Fri, 10 Aug 2001 15:32:26 -0400 (EDT) Resent-Date: Fri, 10 Aug 2001 15:32:26 -0400 (EDT) Resent-Message-Id: <200108101932.PAA09930@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA09910 for ; Fri, 10 Aug 2001 15:32:10 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA21583 for ; Fri, 10 Aug 2001 15:32:06 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA121046 for ; Fri, 10 Aug 2001 14:29:30 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7AJVZr103724 for ; Fri, 10 Aug 2001 15:31:35 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jim Amsden" Date: Fri, 10 Aug 2001 15:24:46 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 08/10/2001 03:31:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: rfc2518 issue: LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5255 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: And there's the issue associated with lock owner (not the owner element of the lock discovery which is a lock owner display name). Should the locked resource be accessed by any principal who has the lock token, or only the principal that issued the LOCK method to create the lock token. If any user can issue a PROPFIND to get the DAV:lockdiscovery and therefore the lock token, and then use that lock token to do anything to the locked resource, the usefulness of WebDAV locking would be limited. On the notion of refreshing locks, users create, refresh, and release locks. The less the server does on their behalf the better. Having timeouts on locks is fine, but let's keep it simple. A user locks a resource with a timeout that generally represents how long they expect to keep the lock and therefore limit access to the resource by others. To have this timeout reset on every successful method invocation would make lock timeouts very non-deterministic and much more difficult for users to predict what will happen when. I think locks timeouts should only be refreshed when the user says to refresh them. Jason Crawford To: w3c-dist-auth@w3.org 08/10/2001 cc: jamsden@us.ibm.com 02:41 PM From: Jason Crawford/Watson/IBM@IBMUS Subject: rfc2518 issue: LOCK_REFRESH_BY_METHODS(Document link: Jim Amsden) It sounds like we're winding down on the locknull discussions, so here's the next issue.... Jim Amsden brought up the following issue. I don't have a record of us resolving it, so let's do that. The specification requires a lock to be refreshed if any method is executed, by anybody, on a locked resource. This can cause some performance problems. More importantly, the semantics of this refresh do not seem to be right -- why should a random GET by a third party cause all locks to be refreshed? The text in question seems to be: The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. In section 9.8 of RFC2518. Also... contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). in section 8.10.8 seems to be alluding to the same behavior. Do we want to change 2518? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Aug 10 16:32:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11198 for ; Fri, 10 Aug 2001 16:32:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA12701; Fri, 10 Aug 2001 16:25:44 -0400 (EDT) Resent-Date: Fri, 10 Aug 2001 16:25:44 -0400 (EDT) Resent-Message-Id: <200108102025.QAA12701@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA12681 for ; Fri, 10 Aug 2001 16:25:39 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA00807 for ; Fri, 10 Aug 2001 16:25:39 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Fri, 10 Aug 2001 21:25:37 +0100 Received: from cs.bris.ac.uk (lama [137.222.102.207]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id VAA11992 for ; Fri, 10 Aug 2001 21:24:34 +0100 (BST) Message-ID: <3B744302.F49F8771@cs.bris.ac.uk> Date: Fri, 10 Aug 2001 21:24:34 +0100 From: Bita Shadgar Organization: Bristol Computer Science Dept X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Servlet programming with jakarta-slide Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5256 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Dose anybody know how can program servlet with jakarta-slide which uses PropfindMethod , ProppatchMethod and MkcolMethod. I wote a servlet with Get which is like this : /** * SimpleServlet.java */ import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import org.apache.slide.webdav.*; public class SimpleServlet extends WebdavServlet { /** * Handle the HTTP GET method by building a simple web page. */ public void doGet (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { super.service( request, response); PrintWriter out; String title = "Simple Servlet Output"; // set content type and other response header fields first response.setContentType("text/html"); // then write the data of the response out = response.getWriter(); out.println(""); out.println(title); out.println(""); out.println("

" + title + "

"); out.println("

This is output from SimpleServlet by WebDAV."); out.println(""); out.close(); } } Any idea will be appeciated. Thanks indeed. Bita. P.S : I tried to get my answer via the slide mailing list many times. However I have not got answer yet. From w3c-dist-auth-request@w3.org Fri Aug 10 17:19:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11735 for ; Fri, 10 Aug 2001 17:19:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA15800; Fri, 10 Aug 2001 17:15:35 -0400 (EDT) Resent-Date: Fri, 10 Aug 2001 17:15:35 -0400 (EDT) Resent-Message-Id: <200108102115.RAA15800@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA15738 for ; Fri, 10 Aug 2001 17:15:26 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37127.rational.com [192.229.37.127]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA11719 for ; Fri, 10 Aug 2001 17:15:27 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 10 Aug 2001 17:24:29 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 17:24:29 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103DED712@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 10 Aug 2001 17:24:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5257 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Jim. Timeouts should only be reset by an explicit request to do so, not as a side-effect of a request that uses the lock token. Cheers, Geoff -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, August 10, 2001 3:25 PM To: w3c-dist-auth@w3c.org Subject: Re: rfc2518 issue: LOCK_REFRESH_BY_METHODS And there's the issue associated with lock owner (not the owner element of the lock discovery which is a lock owner display name). Should the locked resource be accessed by any principal who has the lock token, or only the principal that issued the LOCK method to create the lock token. If any user can issue a PROPFIND to get the DAV:lockdiscovery and therefore the lock token, and then use that lock token to do anything to the locked resource, the usefulness of WebDAV locking would be limited. On the notion of refreshing locks, users create, refresh, and release locks. The less the server does on their behalf the better. Having timeouts on locks is fine, but let's keep it simple. A user locks a resource with a timeout that generally represents how long they expect to keep the lock and therefore limit access to the resource by others. To have this timeout reset on every successful method invocation would make lock timeouts very non-deterministic and much more difficult for users to predict what will happen when. I think locks timeouts should only be refreshed when the user says to refresh them. Jason Crawford To: w3c-dist-auth@w3.org 08/10/2001 cc: jamsden@us.ibm.com 02:41 PM From: Jason Crawford/Watson/IBM@IBMUS Subject: rfc2518 issue: LOCK_REFRESH_BY_METHODS(Document link: Jim Amsden) It sounds like we're winding down on the locknull discussions, so here's the next issue.... Jim Amsden brought up the following issue. I don't have a record of us resolving it, so let's do that. The specification requires a lock to be refreshed if any method is executed, by anybody, on a locked resource. This can cause some performance problems. More importantly, the semantics of this refresh do not seem to be right -- why should a random GET by a third party cause all locks to be refreshed? The text in question seems to be: The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. In section 9.8 of RFC2518. Also... contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). in section 8.10.8 seems to be alluding to the same behavior. Do we want to change 2518? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat Aug 11 20:19:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09934 for ; Sat, 11 Aug 2001 20:19:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA10437; Sat, 11 Aug 2001 19:53:25 -0400 (EDT) Resent-Date: Sat, 11 Aug 2001 19:53:25 -0400 (EDT) Resent-Message-Id: <200108112353.TAA10437@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA10413 for ; Sat, 11 Aug 2001 19:53:16 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA02723 for ; Sat, 11 Aug 2001 19:53:16 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA180976; Sat, 11 Aug 2001 19:50:40 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7BNisP65682; Sat, 11 Aug 2001 19:44:54 -0400 Importance: Normal To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sat, 11 Aug 2001 19:51:02 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/11/2001 07:52:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5258 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hey Geoff... Could you make an explicit proposal as to how the spec should change? BTW... I don't care if the server choses to do this or not. I doubt refreshing the lock creates a functional problem since I doubt a client would be written to wait for a time out and choke if it didn't unlock the resource. OTOH, I don't see the point in encouraging servers to refresh the lock either. If a server developer/administrator discovers a reason that this refreshing policy is good, they can use it, but we don't need to encourage it since it might be pointless and costly. So my recommendation would be to silent on this... or perhaps somehow express flexibility. Anyway, perhaps you could suggest what change to 2518 you'd like... :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sun Aug 12 22:18:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21941 for ; Sun, 12 Aug 2001 22:18:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA08944; Sun, 12 Aug 2001 22:17:07 -0400 (EDT) Resent-Date: Sun, 12 Aug 2001 22:17:07 -0400 (EDT) Resent-Message-Id: <200108130217.WAA08944@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA08924 for ; Sun, 12 Aug 2001 22:17:03 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37127.rational.com [192.229.37.127]) by tux.w3.org (8.9.3/8.9.3) with SMTP id WAA04197 for ; Sun, 12 Aug 2001 22:17:04 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 12 Aug 2001 22:26:18 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 12 Aug 2001 22:26:18 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103DED832@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sun, 12 Aug 2001 22:26:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5259 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'd just delete the paragraph in 9.8 that states: The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. The last sentence is redundant, since it is already specified in the LOCK semantics. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Saturday, August 11, 2001 7:51 PM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS Hey Geoff... Could you make an explicit proposal as to how the spec should change? BTW... I don't care if the server choses to do this or not. I doubt refreshing the lock creates a functional problem since I doubt a client would be written to wait for a time out and choke if it didn't unlock the resource. OTOH, I don't see the point in encouraging servers to refresh the lock either. If a server developer/administrator discovers a reason that this refreshing policy is good, they can use it, but we don't need to encourage it since it might be pointless and costly. So my recommendation would be to silent on this... or perhaps somehow express flexibility. Anyway, perhaps you could suggest what change to 2518 you'd like... :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Aug 14 06:39:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25761 for ; Tue, 14 Aug 2001 06:39:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA15992; Tue, 14 Aug 2001 06:34:39 -0400 (EDT) Resent-Date: Tue, 14 Aug 2001 06:34:39 -0400 (EDT) Resent-Message-Id: <200108141034.GAA15992@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA15970 for ; Tue, 14 Aug 2001 06:34:25 -0400 (EDT) Received: from www.pspl.co.in (www.pspl.co.in [202.54.11.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA10929 for ; Tue, 14 Aug 2001 06:34:23 -0400 Received: from gaurishankar (gateway.pspl.co.in [203.199.147.2]) by www.pspl.co.in (8.11.0/8.11.0) with SMTP id f7EAVYY14563 for ; Tue, 14 Aug 2001 16:01:34 +0530 Reply-To: From: =?iso-8859-1?Q?Medha_Atr=E9?= To: "WebDAV" Date: Tue, 14 Aug 2001 16:08:06 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Copying to a locked destination Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5260 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, I am using Neon libraries. I did not find any method which takes a lock token to COPY resource to a locked resource. How do I submit a lock-token while copying a resource to a locked destination ? Regards. Medha Atré ~~~~~~~~~~~~~~~~~~~~~ Associate Member of Tech. Staff Persistent Systems Pvt. Ltd. Pune, India Ph : +91-20-5678900 (Ext. 295) ~~~~~~~~~~~~~~~~~~~~~ From w3c-dist-auth-request@w3.org Tue Aug 14 07:32:36 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27003 for ; Tue, 14 Aug 2001 07:32:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA17316; Tue, 14 Aug 2001 07:29:12 -0400 (EDT) Resent-Date: Tue, 14 Aug 2001 07:29:12 -0400 (EDT) Resent-Message-Id: <200108141129.HAA17316@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA17296 for ; Tue, 14 Aug 2001 07:28:51 -0400 (EDT) Received: from www.pspl.co.in (www.pspl.co.in [202.54.11.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA15137 for ; Tue, 14 Aug 2001 07:28:51 -0400 Received: from gaurishankar (gateway.pspl.co.in [203.199.147.2]) by www.pspl.co.in (8.11.0/8.11.0) with SMTP id f7EBQ1Y15904; Tue, 14 Aug 2001 16:56:01 +0530 Reply-To: From: =?iso-8859-1?Q?Medha_Atr=E9?= To: "Steve Lau" Cc: "WebDAV" Date: Tue, 14 Aug 2001 17:02:33 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <001701c124b0$3bcf9b30$f8c47bca@dcpholdings.com> Subject: RE: Copying to a locked destination Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5261 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, We are trying to build a test harness for Webdav server's compliance testing using Neon libraries. Do you have any idea how to submit a lock-token while copying a resource to a locked destination ? I did not see any copy method in Neon's libraries which provides this facility. Medha Atré ~~~~~~~~~~~~~~~~~~~~~ Associate Member of Tech. Staff Persistent Systems Pvt. Ltd. Pune, India Ph : +91-20-5678900 (Ext. 295) ~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Steve Lau [mailto:iiop@hotmail.com] Sent: Tuesday, August 14, 2001 4:30 PM To: medha_atre@persistent.co.in Subject: Re: Copying to a locked destination Hi, are you building webdav system with java ? Steve ----- Original Message ----- From: "Medha Atré" To: "WebDAV" Sent: Tuesday, August 14, 2001 6:38 PM Subject: Copying to a locked destination Hello, I am using Neon libraries. I did not find any method which takes a lock token to COPY resource to a locked resource. How do I submit a lock-token while copying a resource to a locked destination ? Regards. Medha Atré ~~~~~~~~~~~~~~~~~~~~~ Associate Member of Tech. Staff Persistent Systems Pvt. Ltd. Pune, India Ph : +91-20-5678900 (Ext. 295) ~~~~~~~~~~~~~~~~~~~~~ From w3c-dist-auth-request@w3.org Tue Aug 14 10:21:48 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05682 for ; Tue, 14 Aug 2001 10:21:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA24170; Tue, 14 Aug 2001 10:20:51 -0400 (EDT) Resent-Date: Tue, 14 Aug 2001 10:20:51 -0400 (EDT) Resent-Message-Id: <200108141420.KAA24170@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA24147 for ; Tue, 14 Aug 2001 10:20:46 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA01668 for ; Tue, 14 Aug 2001 10:20:47 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA349174; Tue, 14 Aug 2001 10:18:09 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7EECMA113492; Tue, 14 Aug 2001 10:12:22 -0400 Importance: Normal To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Tue, 14 Aug 2001 01:15:30 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/14/2001 10:20:13 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5262 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: Sounds good to me Geoff. Do we have any other comments? Agreement? ----------------------------------------------------------------------------------------------------------- I'd just delete the paragraph in 9.8 that states: The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. The last sentence is redundant, since it is already specified in the LOCK semantics. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Aug 14 14:07:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12043 for ; Tue, 14 Aug 2001 14:07:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA06775; Tue, 14 Aug 2001 14:06:44 -0400 (EDT) Resent-Date: Tue, 14 Aug 2001 14:06:44 -0400 (EDT) Resent-Message-Id: <200108141806.OAA06775@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA06717 for ; Tue, 14 Aug 2001 14:06:29 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA29213 for ; Tue, 14 Aug 2001 14:06:29 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA396994 for ; Tue, 14 Aug 2001 14:03:52 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7EHw5K67394 for ; Tue, 14 Aug 2001 13:58:05 -0400 Importance: Normal To: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Tue, 14 Aug 2001 14:01:41 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/14/2001 02:05:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id OAA06717 Subject: RE: rfc2518 issue: LOCK_NULL_STATUS_CREATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5264 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'm marking the following issue: What status code should be returned when a lock null resource is created ? 200 OK or 201 Created? A related issue is what status code should be returned by a PUT or MKCOL on a lock-null resource? MKCOL is defined to be 201, PUT could be 200 or 201 (201 seems like a slightly better choice). ...as resolved by our apparent consensus on the addition of the following wording for a status code for LOCK requests... 201 (Created) - The lock request succeeded by creating a new resource and the value of the lockdiscovery property is included in the body. Discussion in the thread that includes the following posting by Stefan... http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0129.html ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Aug 14 14:07:26 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12057 for ; Tue, 14 Aug 2001 14:07:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA06746; Tue, 14 Aug 2001 14:06:38 -0400 (EDT) Resent-Date: Tue, 14 Aug 2001 14:06:38 -0400 (EDT) Resent-Message-Id: <200108141806.OAA06746@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA06715 for ; Tue, 14 Aug 2001 14:06:28 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA29211 for ; Tue, 14 Aug 2001 14:06:29 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA351386 for ; Tue, 14 Aug 2001 14:03:51 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7EHw4K67392 for ; Tue, 14 Aug 2001 13:58:04 -0400 Importance: Normal To: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Tue, 14 Aug 2001 14:01:31 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/14/2001 02:05:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5263 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: Okay all... I've just entered this issue as resolved. The resolution consists largely of what is suggested in the following posting by Geoff. http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0107.html The following other issues as resolved by virtue of the fact that we no longer have LNR's... COPY_OVER_WRITE_LOCK_NULL LOCK_NULL_SLASH_URL NULL_RESOURCE_CLARIFY I'll list the 201 status response discussion and consensus as a resolution of the LOCK_NULL_STATUS_CREATION issue shortly. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Aug 14 14:50:26 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12829 for ; Tue, 14 Aug 2001 14:50:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08673; Tue, 14 Aug 2001 14:47:42 -0400 (EDT) Resent-Date: Tue, 14 Aug 2001 14:47:42 -0400 (EDT) Resent-Message-Id: <200108141847.OAA08673@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA08652 for ; Tue, 14 Aug 2001 14:47:37 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA01289 for ; Tue, 14 Aug 2001 14:47:37 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA444428; Tue, 14 Aug 2001 14:44:59 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7EIdBK112524; Tue, 14 Aug 2001 14:39:12 -0400 Importance: Normal To: "John Hall" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Tue, 14 Aug 2001 14:46:04 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/14/2001 02:47:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Behavior of PUT on unlocked resource with invalid IF header ... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5265 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: John, I'm sending this to the 2518 working group rather than Delta-V since it doesn't seem Delta-V specific. (I've included your note below.) My opinion is that... The spec should not use the IF header for token presentation to the server. The IF header should only be used for client initiated assertion checking. The current use of IF for dual purposes just causes confusion (like I think your note indicates) and impedes our ability to potentially extend it later. We should transition to some other header for token presentation to the server. Or perhaps I just misunderstand the IF header and someone needs to clearly define it. :-) Do we have other people with opinions on this? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "John Hall" @w3.org on 08/14/2001 01:56:04 PM Sent by: ietf-dav-versioning-request@w3.org To: cc: Subject: Behavior of PUT on unlocked resource with invalid IF header ... If we reject it, then a client could detect that their previously active lock had expired. So ... I'm wondering if the spec should require the rejection. I'm also wondering if my implementation should reject it even in the spec is silent. -----Original Message----- From: ietf-dav-versioning-request@w3.org [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Jim Amsden Sent: Sunday, August 12, 2001 5:24 PM To: ietf-dav-versioning@w3.org Subject: RE: Comments regarding locking & auto-checkin... John asks: Is a PUT supposed to be rejected if the IF header provided specifies an invalid lock token and the resource is not locked? The if header would likely be ignored since the resource isn't locked and there's no token to check. But servers could implement this as a failed If header since it doesn't match the resource. Looks like a clarification might be needed in the spec. From w3c-dist-auth-request@w3.org Tue Aug 14 16:23:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14420 for ; Tue, 14 Aug 2001 16:23:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15495; Tue, 14 Aug 2001 16:21:44 -0400 (EDT) Resent-Date: Tue, 14 Aug 2001 16:21:44 -0400 (EDT) Resent-Message-Id: <200108142021.QAA15495@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA15440 for ; Tue, 14 Aug 2001 16:21:25 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA11846 for ; Tue, 14 Aug 2001 16:21:24 -0400 Received: from [216.36.75.57] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 4464074; Tue, 14 Aug 2001 13:15:47 -0700 From: "Lisa Dusseault" To: "Webdav WG" Cc: Date: Tue, 14 Aug 2001 13:20:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: Notes from DAV meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5266 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I haven't received the actual notes yet from the notetaker (hint, nudge) but here's what I wrote down from the WebDAV meeting last week in London. Note these are incomplete. Lots of progress made; various threads to pick up and continue on the list. Reported By Lisa Dusseault The slides I threw up on RFC2518 issues are available at http://www.sharemation.com/~milele/public/dav/WebDAVWG-London.ppt. (WebDAV-compatible repository) DASL revival discussion ----------------------- Issue raised by Jim Amsden whether robust SQL-like language specified in the draft was too complex. Implementors seemed to think this wasn't a problem. Mention of XML Query - whether it may be mature enough to use. Issue with that -- doesn't solve the same problems (e.g. filtered collection content listings) Should schema discovery be cut or fixed? e.g. just limited to one resource at a time? Have a way to specify allowed searches on all dead properties? Is it required to be able to do body/content searches -- not required -- filtered collection listings primary importance Larry Masinter noted DASL is not in the DAV charter -- thus DASL can't be revived in the DAV WG. Either restart DASL WG or handle outside the scope of a WG. DAV WG charter discussion ------------------------- Some items remain in DAV WG charter, not currently dealt with: advanced collection, bindings, registry. Is there any interest in actually working on these issues? RFC 2518 Issues list -------------------- The rest of the WG discussed various RFC2518 issues, brought up by the interop or previously. Consensus was reached on a number of issues -- if the mailing list does not raise new objections, we should record these for 2518. - Finding Root of Repository - Consensus around: Client should not rely on finding DAV: support in response to OPTIONS / request Clients may attempt to find the root of the repository but they must not fail if the root is not at '/' Client implementors need to speak up on the list if they need a new way to find the root of the repository. - Source property not implemented - The source property is better than the Translate header (used by Microsoft) because (a) it can name a separate resource that can be separately addressed by ACLs, (b) it can include several HREFs when a dynamic page is generated by more than one source file. Suggestion from Peter (?) source property is part of the general problem of identifying releationships between resources, like bindings. Resolution - bring up on the list. - Lock null resources - The WG had consensus on simplifying the way LOCK is used to create resources: (a) LOCK on unmapped URL will create a zero-length regular resource (MIME type needs to be decided) (b) MKCOL will not work on a resource created this way (c) A resource created this way will not disappear when unlocked (d) A resource created this way is a normal zero-length resource, thus no special behaviour for GET Suggestions for MIME-type included new mime-type, application/octet-stream, text/plain. - Lock Permissions - Consensus around: Users other than lock creators MAY be able to UNLOCK a resource by discovering and using the correct lock token. Servers should never allow users other than lock creaters to update a locked resource, even if they use the correct lock token. Servers should always require the correct lock token to ensure intentionality. - If Header - Jim Amsden promised to post If header grammar - XML 'lang' attribute placement - Consensus to put the lang attribute only on the 'prop' element. - Reliance on MIME type vs file extension - Consensus that clients should use MIME type in preference to file extension - Trailing slash - Consensus: (a) Servers SHOULD put trailing slash after collection names when producing them. (b) Servers SHOULD allow requests to collections even if trailing slash is missing (c) Servers can use the Content-Location header to clarify the proper URL for a collection, in the response to any request that did not include the proper trailing slash. (d) The trailing slash convention is good. Possibly strengthen language so that it's more than just a convention. - Date Formats - Consensus: Spec is not broke; implementations should take more care in handling the TWO date formats required for DAV property values. - Lock Owner - Consensus: (a) WHen client provides value for lock owner, server should preserve this value and not modify or overwrite it. When client does not provide a value, Server MAY provide a helpful value. Idea: RFC2518 maybe should add "lock creator" value to lock information, in order to reduce confusion, and specify that lock creator is server-calculated (protected) Lisa From w3c-dist-auth-request@w3.org Tue Aug 14 20:07:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17660 for ; Tue, 14 Aug 2001 20:07:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA21063; Tue, 14 Aug 2001 17:39:58 -0400 (EDT) Resent-Date: Tue, 14 Aug 2001 17:39:58 -0400 (EDT) Resent-Message-Id: <200108142139.RAA21063@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA20957 for ; Tue, 14 Aug 2001 17:39:41 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA20626 for ; Tue, 14 Aug 2001 17:39:41 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 14 Aug 2001 17:48:20 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 17:48:18 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E257C@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Tue, 14 Aug 2001 17:48:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Notes from DAV meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5267 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: Everthing here looks fine to me, except for: - Trailing slash - Consensus: (a) Servers SHOULD put trailing slash after collection names when producing them. (b) Servers SHOULD allow requests to collections even if trailing slash is missing (c) Servers can use the Content-Location header to clarify the proper URL for a collection, in the response to any request that did not include the proper trailing slash. (d) The trailing slash convention is good. Possibly strengthen language so that it's more than just a convention. I vigorously oppose this approach. All these "SHOULDs" and "cans" are unnecessary. A simple statement of the form: Trailing slashes MUST be ignored, e.g. the URL "http://xxx/yyy/" MUST identify the same resource as "http://xxx/yyy". is sufficient and will avoid the confusion and interoperability problems that will result from the alternative approach. This was discussed at length on the mailing list about a year ago, and no implementation was identified that depended on /yyy being a different resource from /yyy/. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Aug 15 04:46:19 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11038 for ; Wed, 15 Aug 2001 04:46:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA14180; Wed, 15 Aug 2001 04:45:55 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 04:45:55 -0400 (EDT) Resent-Message-Id: <200108150845.EAA14180@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA14156 for ; Wed, 15 Aug 2001 04:45:49 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA09008 for ; Wed, 15 Aug 2001 04:45:48 -0400 Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id JAA108414 for ; Wed, 15 Aug 2001 09:26:10 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7F8jH0141380 for ; Wed, 15 Aug 2001 09:45:17 +0100 To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Wed, 15 Aug 2001 09:21:40 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 15/08/2001 09:43:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: LOCK_NULL_STATUS_CREATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5268 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: BTW: Jim W. objected when I made this suggestion a couple of months ago. (http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0302.html) He is, of course, free to change his mind Regards, Tim Jason wrote: > I'm marking the following issue: > > What status code should be returned when a lock null > resource is created ? 200 OK or 201 Created? A related > issue is what status code should be returned by a PUT > or MKCOL on a lock-null resource? MKCOL is defined to > be 201, PUT could be 200 or 201 (201 seems like a > slightly better choice). > > ...as resolved by our apparent consensus on the addition > of the following wording for a status code for LOCK requests... > > 201 (Created) - The lock request succeeded by creating a > new resource and the value of the lockdiscovery property > is included in the body. > > > Discussion in the thread that includes the following > posting by Stefan... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0129.html > From w3c-dist-auth-request@w3.org Wed Aug 15 04:54:33 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11090 for ; Wed, 15 Aug 2001 04:54:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA14391; Wed, 15 Aug 2001 04:54:21 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 04:54:21 -0400 (EDT) Resent-Message-Id: <200108150854.EAA14391@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA14371 for ; Wed, 15 Aug 2001 04:54:13 -0400 (EDT) Received: from apollo.eurgw.xerox.com (apollo.ext.eurgw.xerox.com [212.137.33.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA09485 for ; Wed, 15 Aug 2001 04:54:07 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by apollo.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA10932 for ; Wed, 15 Aug 2001 09:54:01 +0100 (BST) Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id JAA19706 for ; Wed, 15 Aug 2001 09:53:33 +0100 (BST) Received: from eurgbrbh03.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 15 Aug 2001 09:52:41 +0100 Received: from gbrwgcpf01.wgc.uk.xerox.com (gbrwgcpf01.wgc.gbr.xerox.com [13.200.2.141]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id QSHGH4AT; Wed, 15 Aug 2001 09:53:30 +0100 Received: by gbrwgcpf01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Aug 2001 09:53:33 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB7767287614@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: Webdav WG Date: Wed, 15 Aug 2001 09:53:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Notes from DAV meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5269 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: Bits snipped. Lets kill these things before they go any further IMHO... > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: 14 August 2001 21:21 > To: Webdav WG > Cc: minutes@ietf.org > Subject: Notes from DAV meeting > > > > I haven't received the actual notes yet from the notetaker > (hint, nudge) but > here's what I wrote down from the WebDAV meeting last week in > London. Note > these are incomplete. Lots of progress made; various threads > to pick up and > continue on the list. [Bits snipped] > RFC 2518 Issues list > -------------------- > > - Lock Permissions - > > Consensus around: Users other than lock creators MAY be able > to UNLOCK a > resource by discovering and using the correct lock token. Assuming your are referring to "ordinary" users i.e. not say when an Administrator removes a lock because an employee has left the company sort of thing: I strongly disagree with this. It should not be allowed at all. I know locks can disappear at any time, but it could cause problems for example - the original lock creator has a document locked and has made changes but not PUT them back. Supposing the new lock creator UNLOCKs the document, LOCKs it and keeps the lock for days, weeks etc. The new lock creator makes changes to the document, re-PUTs it and UNLOCKs it. The original lock creator still has their copy of the document with their changes, but cannot re-PUT them for all this time (weeks?). What are they suppose to do? They could discard their changes or after the new lock creator has UNLOCKed the document, the original lock creator may then be able to PUT their changes in (after weeks?). But then, there could be merge type problems or lost update type problems if they discarded their changes because they get fed up waiting, had to switch their client machine off etc. > Servers should > never allow users other than lock creaters to update a locked > resource, even > if they use the correct lock token. I know what this statement is meant to mean, but one could say this 2nd statement contradicts the 1st because the new lock creator is not the original lock creator. After all, look at the confusion "null resource" caused. > - Lock Owner - > > Consensus: > (a) WHen client provides value for lock owner, server should > preserve this > value and not modify or overwrite it. When client does not > provide a value, > Server MAY provide a helpful value. Not sure what the server could provide here or how helpful it would be. What were people thinking of e.g. IP address of the client ? Agree with the first sentence though. > Idea: RFC2518 maybe should add "lock creator" value to lock > information, in > order to reduce confusion, and specify that lock creator is > server-calculated (protected) Disagree with this. There is no need to introduce a new property. Also, this is an implementation detail and may give sensitive information away e.g. an OS account name, which might be retrieved say with PROPFIND or returned in a (failed) LOCK request. The lock owner property is sufficient as it can contain contact information e.g. tel no, email addy etc. Clients should be using this when issuing LOCK requests. Fix the clients, don't change the RFC. > > Lisa > Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Wed Aug 15 06:38:43 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12032 for ; Wed, 15 Aug 2001 06:38:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA17245; Wed, 15 Aug 2001 06:29:04 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 06:29:04 -0400 (EDT) Resent-Message-Id: <200108151029.GAA17245@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA17225 for ; Wed, 15 Aug 2001 06:28:59 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA16342 for ; Wed, 15 Aug 2001 06:28:59 -0400 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id LAA200984; Wed, 15 Aug 2001 11:19:09 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7FASBg118434; Wed, 15 Aug 2001 11:28:13 +0100 To: w3c-dist-auth@w3.org Cc: minutes@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Wed, 15 Aug 2001 11:24:41 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 15/08/2001 11:26:14 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id GAA17225 Subject: IETF-51 WebDAV WG meeting minutes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5270 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit WebDAV Working Group Meeting (1:30pm Monday August 6th, 2001) IETF'51 London, England Lisa Dusseault standing in for Jim Whitehead as Chair. - Lisa D. presented the agenda and it was approved by the group. - Discussion started with DASL. Lisa D. is taking over the role of editor, and has tried to contact previous authors without much success. Lisa D. made a call for participants on the DASL spec. - Larry M. asked if the XML query language from W3C is sufficient for DASL. Lisa thinks it is solving a different problem and that an SQL-like syntax is more appropriate for DASL. - Should include discovery so that the server can answer which properties it supports searches over. Nobody stood up for schema discovery. - How about search over content? Should be in scope of the working group, but should it be a requirement of DASL? - IETF process ? should DASL be part of the WebDAV WG or be in a separate WG or be an independent submission? People agreed that it should not be part of the WebDAV WG. ACLs were in the WebDAV WG charter, DASL isn't. - Question: What remains to do in the WebDAV WG charter? Advanced collections, redirect references, properties registry doc., ordered collections, and raising DAV to a draft standard. - This remaining work is probably just lacking an editor/champion. The WG should push them forward or drop them if there is no interest in the work being done. - Larry M. presented the WebDAV Inter-op report. 58 people, 20 organizations, 35 implementations, (17 clients, 18 servers of which 5 open source). - Participants had agreed not to publish the results for individual tests. - Not many implementations inter-operated completely without any issues. - The event made good progress towards inter-op., some teams made fixes in real time either on-site or in collaboration with development teams 'back home'. - Proposed a virtual inter-op meeting in late-September, say a four hour test window and a telephone conference call. - Mailing list for inter-op discussions is interop@webdav.org, which is by invitation. - Found common inter-op problems, maybe these can be distilled into an implementers' guide. - Little, if any, DeltaV testing took place. - Typical problems include security, URI encoding problems, etc. misunderstandings in the spec. - Inter-op testing uncovered some required features were missing. Many servers did not implement LOCK, and many clients required it. - Some inter-op problems were HTTP issues, such as authentication, multiple authentication headers. - Missing, unused, untested features included DAV:source property (nobody used or implemented it), content-language being reflected in the DAV:getcontentlanguage property. It was noted that the source property should be removed unless there are min. two independent interoperable client and server implementations of it. Jim A. pointed out that the DAV:source property is simply a dead property containing an HREF, there should be nothing difficult to implement it. Translate header was used in place of the source property by some implementations. It is a Boolean switch to tell the server whether to interpret the resource or not. - John S. asked if people had considered using simple URL mangling to indicate the source, such as in PHP's .phps - Poor support for the lang attribute on properties. Maybe it is not used because there is some ambiguity over it in the specification? - The "property behavior" element in MOVE/COPY may not have been tested. - Discovering the root of the repository. Some clients relied upon "OPTIONS /" to respond with DAV information, although servlet implementations would require at least a URL segment. So should clients not rely on "/" being in DAV-space? Clients may use other means of determining the root of the repository. One suggestion [from the floor] was to use the authentication realm. - Security issues included those who use authorization headers from one request with subsequent requests on the same connection. - Cookies in WebDAV. Some servers require that client support cookies, i.e. for session look-up rather than re-authentication. Clients should not be expected to support cookies, but in these circumstances clients should support cookies if they expect performant servers. This is material for the implementer's guide. - Lock-null resources. LOCK followed by PUT, and LOCK followed by MKCOL are both required to be supported according to the spec., but no clients required the LOCK followed by MKCOL behavior. Consider dropping this from the spec. - LOCK followed by UNLOCK should cause the lock-null resource to disappear. Varying implementations were seen. - Support for "If-None-Match: ?" is unknown. - Discussion of status code when creating a lock-null resource, should it be 200 or 201? - Maybe lock-null resources should have a discrete MIME-type to distinguish it as a special resource. However, some server platforms don't remember the MIME-types but rely on the file extensions. - Lock permissions. Lock operations by non-lock creator. Should there be a principal in ACLs that allows 'lock stealing'? Servers should only allow privileged UNLOCK. - If: header confusion. Issues surrounding the size of the header value when dealing with deep collections, and combination problems. When combining values does it mean logical AND or OR? Jim A. to post grammar for the If: header onto the list. - URL escaping ? how to deal with href illegal characters eg., "?/New Folder", are they XML escaped or URL escaped or both, and in what order, e.g. UTF-8 encoding and HEX encoding. Recommended to take a look at Donald's refs to DSIG document on canonicalization. - (At this point the curtain falls and nearly crushes Lisa)! - Where does the xml:lang attribute go? Does anyone care? Maybe should state that implementations should support it anywhere as XML generators may move it up to the root. No objections to putting the lang attribute on the DAV:prop element. - Servers should return URLs with a trailing slash when referring to collections, however, clients should not rely on it. Consider making the standing convention stronger? - Note that URLs returned in a multi-status may be relative to the content-location returned in the response ? should be in the implementer's guide. - Date format: page 27 of the RFC2518 stands. Implementations should follow the spec in this regard. - Lock owner information. Should servers take the information passed by the client, or use information they know based on the client's authenticated principal? Agreed that the server should take the information passed by the client, and maybe augment the lock token information with "creator" as well. - Should clarify which properties are live and which are protected. - Meeting closed at 5:30pm. From w3c-dist-auth-request@w3.org Wed Aug 15 07:37:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13660 for ; Wed, 15 Aug 2001 07:37:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA18707; Wed, 15 Aug 2001 07:36:39 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 07:36:39 -0400 (EDT) Resent-Message-Id: <200108151136.HAA18707@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA18686 for ; Wed, 15 Aug 2001 07:36:34 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA21306 for ; Wed, 15 Aug 2001 07:36:33 -0400 Received: (qmail 7381 invoked by uid 0); 15 Aug 2001 11:36:32 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail06) with SMTP; 15 Aug 2001 11:36:32 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Wed, 15 Aug 2001 13:36:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Notes from DAV meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5271 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, thanks for the summary. > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, August 14, 2001 10:21 PM > To: Webdav WG > Cc: minutes@ietf.org > Subject: Notes from DAV meeting > > > > I haven't received the actual notes yet from the notetaker (hint, > nudge) but > here's what I wrote down from the WebDAV meeting last week in > London. Note > these are incomplete. Lots of progress made; various threads to > pick up and > continue on the list. > > Reported By Lisa Dusseault > > The slides I threw up on RFC2518 issues are available at > http://www.sharemation.com/~milele/public/dav/WebDAVWG-London.ppt. > (WebDAV-compatible repository) A few notes regarding the slides: - Lock Null Resources: LOCK -> PUT is used by MS Office when doing a "save as..." - XML escaping: servers and clients need to process response bodies using a conforming, namespace aware XML parser. CDATA can appear everywhere where text content is expected (not only in properties) - xml:lang: should stick to the definitions in Canonical XML (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#DocSubsets): attributes in the xml namespace are inherited from parents. I'd rather not have WebDAV invent different rules - allprop: recommend adopting the proposal using a element as child of . > DAV WG charter discussion > ------------------------- > > Some items remain in DAV WG charter, not currently dealt with: advanced > collection, bindings, registry. > Is there any interest in actually working on these issues? Yes. We have implemented ordered collections and redirect references. I think I remember of having redirect references and BINDs added to the core protocol, is this still under consideration? > - Source property not implemented - > > The source property is better than the Translate header (used by > Microsoft) > because (a) it can name a separate resource that can be > separately addressed > by ACLs, (b) it can include several HREFs when a dynamic page is generated > by more than one source file. > > Suggestion from Peter (?) source property is part of the general > problem of > identifying releationships between resources, like bindings. Resolution - > bring up on the list. We are currently supporting the Translate header, as our back end system doesn't have a concept of different URLs for processed/unprocessed content. Furthermore, I think the current wording on is hard to understand, in particular - src/dst seem be the wrong way round, - why does .. need a element? Isn't it always identical to the resource on which the property is defined? - the documentation on src/dst in talks about a href XML element (http://www.greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_link) which doesn't exist If the intention is to have to be able to replace the Translate header, this needs more work... > - XML 'lang' attribute placement - > > Consensus to put the lang attribute only on the 'prop' element. Strongly disagree. This contradicts both the current wording in RFC2518, the definitions in the XML spec itself and specs defining XML fragment exchange (Canonical XML: ). From w3c-dist-auth-request@w3.org Wed Aug 15 09:48:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20521 for ; Wed, 15 Aug 2001 09:48:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA24147; Wed, 15 Aug 2001 09:47:16 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 09:47:16 -0400 (EDT) Resent-Message-Id: <200108151347.JAA24147@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA24034 for ; Wed, 15 Aug 2001 09:47:02 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA00894 for ; Wed, 15 Aug 2001 09:47:02 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 15 Aug 2001 09:56:12 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 09:56:12 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F4875F@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Wed, 15 Aug 2001 09:56:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Notes from DAV meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5273 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com] I agree with all of Shaun's comments, except for: > - Lock Permissions - > Consensus around: Users other than lock creators MAY be able to > UNLOCK a resource by discovering and using the correct lock > token. Assuming your are referring to "ordinary" users i.e. not say when an Administrator removes a lock because an employee has left the company sort of thing: I strongly disagree with this. It should not be allowed at all. I strongly agree with the consensus opinion. A client holding a lock already has to deal with locks being lost through timeouts. Allowing another client to effectively force the timeout is a valuable feature that does not increase the complexity of the locking client. A server can use access control to control what users have permission to force the timeout. I know locks can disappear at any time, but it could cause problems for example ... Any such problem already occurs because of timeouts, so clients have to deal with all these situations anyway. Allowing a client to force a timeout decreases the need to have an automatic server timeout, and therefore this capability will actually decrease the number of unnecessary timeouts (since the server can be written to assume that timeouts will be forced by clients that need them). > Servers should never allow users other than lock creaters to > update a locked resource, even if they use the correct lock > token. I know what this statement is meant to mean, but one could say this 2nd statement contradicts the 1st because the new lock creator is not the original lock creator. The "update" here means "update the content or dead properties". An UNLOCK does not update the content or dead properties, and therefore these two statements are consistent. The term "update" could be clarified, to make sure there is no misunderstanding. After all, look at the confusion "null resource" caused. I don't see the relationship between forced lock timeouts and null resources. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Aug 15 09:48:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20532 for ; Wed, 15 Aug 2001 09:48:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA24070; Wed, 15 Aug 2001 09:47:09 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 09:47:09 -0400 (EDT) Resent-Message-Id: <200108151347.JAA24070@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA24029 for ; Wed, 15 Aug 2001 09:47:01 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA00892 for ; Wed, 15 Aug 2001 09:47:01 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 15 Aug 2001 09:56:12 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 09:56:12 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F4875D@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 15 Aug 2001 09:56:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: LOCK_NULL_STATUS_CREATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5272 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: Note that Jim's objection was not in the new context, in which the LOCK on an unmapped URL creates a regular resource. I am sure Jim will withdraw his objection in this new context (:-). Cheers, Geoff -----Original Message----- From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com] Sent: Wednesday, August 15, 2001 4:22 AM To: w3c-dist-auth@w3.org Subject: RE: rfc2518 issue: LOCK_NULL_STATUS_CREATION BTW: Jim W. objected when I made this suggestion a couple of months ago. (http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0302.html) He is, of course, free to change his mind Regards, Tim Jason wrote: > I'm marking the following issue: > > What status code should be returned when a lock null > resource is created ? 200 OK or 201 Created? A related > issue is what status code should be returned by a PUT > or MKCOL on a lock-null resource? MKCOL is defined to > be 201, PUT could be 200 or 201 (201 seems like a > slightly better choice). > > ...as resolved by our apparent consensus on the addition > of the following wording for a status code for LOCK requests... > > 201 (Created) - The lock request succeeded by creating a > new resource and the value of the lockdiscovery property > is included in the body. > > > Discussion in the thread that includes the following > posting by Stefan... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0129.html > From w3c-dist-auth-request@w3.org Wed Aug 15 10:02:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21196 for ; Wed, 15 Aug 2001 10:02:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA25136; Wed, 15 Aug 2001 10:01:58 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 10:01:58 -0400 (EDT) Resent-Message-Id: <200108151401.KAA25136@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA25110 for ; Wed, 15 Aug 2001 10:01:44 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA03045 for ; Wed, 15 Aug 2001 10:01:44 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 15 Aug 2001 10:10:55 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 10:10:55 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F48771@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 15 Aug 2001 10:10:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IETF-51 WebDAV WG meeting minutes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5274 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com] - Question: What remains to do in the WebDAV WG charter? Advanced collections, redirect references, properties registry doc., ordered collections, and raising DAV to a draft standard. - This remaining work is probably just lacking an editor/champion. The WG should push them forward or drop them if there is no interest in the work being done. In the past, JimW has expressed interest in doing the final editing round on the advanced collection protocols (binding, redirect references, ordered collections). With the DeltaV protocol nearing completion, I would be willing to do the final editing round on the binding protocol. Anyone want to volunteer as editor for the redirect reference or ordered collection protocols, in case JimW does not have time to take care of this? Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Aug 15 10:45:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22729 for ; Wed, 15 Aug 2001 10:44:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA28539; Wed, 15 Aug 2001 10:44:34 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 10:44:34 -0400 (EDT) Resent-Message-Id: <200108151444.KAA28539@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA28519 for ; Wed, 15 Aug 2001 10:44:26 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA08135 for ; Wed, 15 Aug 2001 10:44:26 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA495950 for ; Wed, 15 Aug 2001 10:41:47 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7FEZxx89140 for ; Wed, 15 Aug 2001 10:36:00 -0400 Importance: Normal To: "Tim Ellison" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 15 Aug 2001 10:30:09 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/15/2001 10:43:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: LOCK_NULL_STATUS_CREATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5275 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: Tim, Actually Jim wasn't disagree'ing with you on what we propose here. He was additionally proposing that the first PUT after the resource is created *also* return 201. I don't think that issue is on the issues list. If Jim advocates it again, we can put it on the list. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Aug 15 11:04:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23106 for ; Wed, 15 Aug 2001 11:04:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA00091; Wed, 15 Aug 2001 11:03:28 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 11:03:28 -0400 (EDT) Resent-Message-Id: <200108151503.LAA00091@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA00071 for ; Wed, 15 Aug 2001 11:03:21 -0400 (EDT) Received: from apollo.eurgw.xerox.com (apollo.ext.eurgw.xerox.com [212.137.33.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA10288 for ; Wed, 15 Aug 2001 11:03:11 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by apollo.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id QAA22347 for ; Wed, 15 Aug 2001 16:03:09 +0100 (BST) Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id QAA02695 for ; Wed, 15 Aug 2001 16:02:39 +0100 (BST) Received: from eurgbrbh03.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 15 Aug 2001 16:01:46 +0100 Received: from gbrwgcpf01.wgc.uk.xerox.com (gbrwgcpf01.wgc.gbr.xerox.com [13.200.2.141]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id QSHG2WQ2; Wed, 15 Aug 2001 16:02:35 +0100 Received: by gbrwgcpf01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Aug 2001 16:02:37 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB7767287615@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: Webdav WG Date: Wed, 15 Aug 2001 16:02:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Notes from DAV meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5276 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: > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: 15 August 2001 14:56 > To: Webdav WG > Subject: RE: Notes from DAV meeting > > > From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com] > > I agree with all of Shaun's comments, except for: > > > - Lock Permissions - > > Consensus around: Users other than lock creators MAY be able to > > UNLOCK a resource by discovering and using the correct lock > > token. > > Assuming your are referring to "ordinary" users i.e. not say when > an Administrator removes a lock because an employee has left the > company sort of thing: > > I strongly disagree with this. It should not be allowed at all. > > I strongly agree with the consensus opinion. > > A client holding a lock already has to deal with locks being lost > through timeouts. Allowing another client to effectively force the > timeout is a valuable feature that does not increase the complexity of > the locking client. A server can use access control to control what > users have permission to force the timeout. > > I know locks can disappear at any time, but it could cause problems > for example ... > > Any such problem already occurs because of timeouts, so > clients have to > deal with all these situations anyway. Allowing a client to force > a timeout decreases the need to have an automatic server timeout, > and therefore this capability will actually decrease the number of > unnecessary timeouts (since the server can be written to assume that > timeouts will be forced by clients that need them). Supposing the server only supported infinite timed locks (which is allowed) and therefore lost locks through timeouts are not an issue. You've just bypassed the lock mechanism as we know it. In my crude example, what is the original lock creator suppose to do ? > > Cheers, > Geoff > Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Wed Aug 15 12:25:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25188 for ; Wed, 15 Aug 2001 12:25:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA07053; Wed, 15 Aug 2001 12:25:31 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 12:25:31 -0400 (EDT) Resent-Message-Id: <200108151625.MAA07053@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA07032 for ; Wed, 15 Aug 2001 12:25:26 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA19446 for ; Wed, 15 Aug 2001 12:25:26 -0400 Received: from beaver ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f7FG9sR05615; Wed, 15 Aug 2001 09:09:55 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Hall, Shaun" , "Webdav WG" Date: Wed, 15 Aug 2001 09:09:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <59697CCC6CE3D411B4CD00805FBB7767287615@gbrwgcms03.wgc.gbr.xerox.com> Subject: RE: Notes from DAV meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5277 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Shaun said: > Supposing the server only supported infinite timed locks (which > is allowed) > and therefore lost locks through timeouts are not an issue. You've just > bypassed the lock mechanism as we know it. In my crude example, > what is the > original lock creator suppose to do ? > If the server only supports infinite timed locks, it's also free to prevent anybody but the original lock creator to use the associated lock token. This proposed clarification doesn't force anything on server implementors that they don't like. It only makes clients have to be more robust in the face of locks disappearing. lisa From w3c-dist-auth-request@w3.org Wed Aug 15 13:08:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26342 for ; Wed, 15 Aug 2001 13:08:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA09980; Wed, 15 Aug 2001 13:08:06 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 13:08:06 -0400 (EDT) Resent-Message-Id: <200108151708.NAA09980@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA09915 for ; Wed, 15 Aug 2001 13:07:53 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA24352 for ; Wed, 15 Aug 2001 13:07:53 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 15 Aug 2001 13:15:59 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 13:15:59 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E257F@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Wed, 15 Aug 2001 13:16:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Notes from DAV meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5278 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com] > From: Clemm, Geoff [mailto:gclemm@rational.com] > A client holding a lock already has to deal with locks being lost > through timeouts. Allowing another client to effectively force the > timeout is a valuable feature that does not increase the complexity of > the locking client. A server can use access control to control what > users have permission to force the timeout. Supposing the server only supported infinite timed locks (which is allowed) and therefore lost locks through timeouts are not an issue. You've just bypassed the lock mechanism as we know it. In my crude example, what is the original lock creator suppose to do ? I would strongly advise all client writer to expect timeouts (assuming you want to interoperate with existing implementations, such as those provided by Microsoft). If your lock no longer exists (either because of a timeout or an explicit unlock by another client), then your client is responsible for letting the user know that a write will possibly overwrite subsequent changes. If the resource is locked by another client, your client should give the user the option to "save as" at a different URL. The user can then look at the two resources (perhaps with the aid of a merge tool, but often not) to decide whether to merge or just overwrite the current resource. In order to update the original resource, the user can wait until it is unlocked, or if it has sufficient privileges, it can "steal" the resource back (by unlocking and then taking out its own lock). The bottom line is that clients die and leave locks in place on critical resources. A server that allows no form of automatic intervention in this case (either with automatic timeouts, or with explicit unlock overrides) is unlikely to become very popular. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Aug 15 15:12:09 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29474 for ; Wed, 15 Aug 2001 15:12:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA20655; Wed, 15 Aug 2001 15:08:04 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 15:08:04 -0400 (EDT) Resent-Message-Id: <200108151908.PAA20655@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA20472 for ; Wed, 15 Aug 2001 15:07:42 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05620 for ; Wed, 15 Aug 2001 15:07:42 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA330816 for ; Wed, 15 Aug 2001 15:05:04 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7FIxGr42328 for ; Wed, 15 Aug 2001 14:59:17 -0400 Importance: Normal To: Webdav WG X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 15 Aug 2001 15:03:28 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/15/2001 03:07:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5279 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'm posting in part to get our subject line to actually describe what we're talking about. And to express an opinion and questions and observations... I think Shaun has some points. Almost every explanation and discussion has focused on why a client should be able to deal with the lock going away. Given that, Shaun's reaction seems reasonable. We appear to be undermining some of the intent of the locks if that's all we say. I can imagine a lot of other readers of 2518's next draft scratching their head when we say people can just pick up the token and unlock the resource. Please let's not forget to include some mention of the fact that this capability is recommended to be under some sort of ACL control and it should not be possible to have one person unlock another person's resources willy-nilly and that it's not even required to support it. Note: I don't think 2518 actually requires servers to reveal the lock token in a the lock-discovery property. Do we care? I would feel a lot better about all this if we had a good explanation about strategies to deal with lock timeouts. How long should a client request the time out to be in various scenarios? What pitfalls are there? What solutions are there? What ACL strategies would work best? What refresh strategies? For example, I take out the lock. I think I'll only need it for an hour. But I have to run home and the lock times out. How must the client and server and human behave to handle that? Should the client have requested a long timeout even though it didn't expect to need that much time? I want to lock a file, grab it, give it to a non-webDAV enabled friend to edit. Then put it back on the server in a day or week or year. What if I over estimate or underestimate the time needed? What if a reboot is needed? Or we forget that we did all this or I leave the company and the company needs to get the friend's change in there. What is the best way to deal with these situations? Long timeouts? Frequest refreshs? Exposed tokens in GUI's? Lock stealing clients? Lock stealing only of your own lock? Clients that store tokens persistantly? Servers that only expose tokens to certain principals? Calls to the administrator? ACL strategies? How do these strategies vary in different environments? At the NSA? In a classroom? Often workign offline? Simply on localhost? I'm not sure if this could go in to the draft, but perhaps we could provide a checklist for client (and server?) implementations and server administrators to make sure they can handle situations like these. Or perhaps we could discover that we only need a narrow set of optional behaviors to chose from. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Aug 15 17:07:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01151 for ; Wed, 15 Aug 2001 17:07:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA03814; Wed, 15 Aug 2001 17:06:37 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 17:06:37 -0400 (EDT) Resent-Message-Id: <200108152106.RAA03814@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA03794 for ; Wed, 15 Aug 2001 17:06:33 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA20254 for ; Wed, 15 Aug 2001 17:06:33 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 15 Aug 2001 17:15:43 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 17:15:43 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB47@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Wed, 15 Aug 2001 17:15:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5280 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: Personally, I believe that any use case that assumes a long-lived lock is broken. Those use cases should be handled by access control, not locks. ACL's have no timeouts, and are principal based, which gives us a clean way of handling all the problems that have arisen when people have tried to use locks where they should be using ACL's. When you only use locks for short term reservations of a resource, all of these concerns about timeouts and locks being stolen evaporate. With the ACL draft in last call, we no longer have any reason to use locks as a poor man's ACL. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Wednesday, August 15, 2001 3:03 PM To: Webdav WG Subject: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS I'm posting in part to get our subject line to actually describe what we're talking about. And to express an opinion and questions and observations... I think Shaun has some points. Almost every explanation and discussion has focused on why a client should be able to deal with the lock going away. Given that, Shaun's reaction seems reasonable. We appear to be undermining some of the intent of the locks if that's all we say. I can imagine a lot of other readers of 2518's next draft scratching their head when we say people can just pick up the token and unlock the resource. Please let's not forget to include some mention of the fact that this capability is recommended to be under some sort of ACL control and it should not be possible to have one person unlock another person's resources willy-nilly and that it's not even required to support it. Note: I don't think 2518 actually requires servers to reveal the lock token in a the lock-discovery property. Do we care? I would feel a lot better about all this if we had a good explanation about strategies to deal with lock timeouts. How long should a client request the time out to be in various scenarios? What pitfalls are there? What solutions are there? What ACL strategies would work best? What refresh strategies? For example, I take out the lock. I think I'll only need it for an hour. But I have to run home and the lock times out. How must the client and server and human behave to handle that? Should the client have requested a long timeout even though it didn't expect to need that much time? I want to lock a file, grab it, give it to a non-webDAV enabled friend to edit. Then put it back on the server in a day or week or year. What if I over estimate or underestimate the time needed? What if a reboot is needed? Or we forget that we did all this or I leave the company and the company needs to get the friend's change in there. What is the best way to deal with these situations? Long timeouts? Frequest refreshs? Exposed tokens in GUI's? Lock stealing clients? Lock stealing only of your own lock? Clients that store tokens persistantly? Servers that only expose tokens to certain principals? Calls to the administrator? ACL strategies? How do these strategies vary in different environments? At the NSA? In a classroom? Often workign offline? Simply on localhost? I'm not sure if this could go in to the draft, but perhaps we could provide a checklist for client (and server?) implementations and server administrators to make sure they can handle situations like these. Or perhaps we could discover that we only need a narrow set of optional behaviors to chose from. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Aug 15 17:43:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01739 for ; Wed, 15 Aug 2001 17:43:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06901; Wed, 15 Aug 2001 17:37:26 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 17:37:26 -0400 (EDT) Resent-Message-Id: <200108152137.RAA06901@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA06881 for ; Wed, 15 Aug 2001 17:37:18 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA24258 for ; Wed, 15 Aug 2001 17:37:18 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 15 Aug 2001 17:45:48 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 17:45:47 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB4A@SUS-MA1IT01> From: "Clemm, Geoff" To: "WebDAV (E-mail)" Date: Wed, 15 Aug 2001 17:45:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Comments regarding locking & auto-checkin... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5281 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: John asks: Is a PUT supposed to be rejected if the IF header provided specifies an invalid lock token and the resource is not locked? Jim Amsden replies: The if header would likely be ignored since the resource isn't locked and there's no token to check. But servers could implement this as a failed If header since it doesn't match the resource. Looks like a clarification might be needed in the spec. I believe 2518 is reasonably clear on this point. Section 9.4: The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). So if you include a lock token, and it does not match the resource to which you are applying the method, the PUT must fail with a 412. Now there is some ambiguity about the meaning of "the resource to which the header is applied" and no-tag-list productions. For example, is the collection one of the resources to which the header is applied, when you delete a member of the collection? But that's a different discussion (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Aug 15 17:45:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01774 for ; Wed, 15 Aug 2001 17:45:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA07097; Wed, 15 Aug 2001 17:42:03 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 17:42:03 -0400 (EDT) Resent-Message-Id: <200108152142.RAA07097@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA07068 for ; Wed, 15 Aug 2001 17:41:47 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA24677 for ; Wed, 15 Aug 2001 17:41:47 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 15 Aug 2001 17:49:43 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 17:49:42 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB4B@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 15 Aug 2001 17:49:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Comments regarding locking & auto-checkin... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5282 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Peter Raymond [mailto:Peter.Raymond@merant.com] [Should] a more explicit error code should be returned when an If header specifies a lock which has timed-out rather than an invalid lock, I believe that at the moment a client cannot tell the difference. I believe most servers do not store "used to be locked by" information with a resource, so it would be very difficult for them to distinguish between a lock which timed out and a lock with does not exist. But in any case, why would a client really care about this distinction? Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Aug 15 18:03:09 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01979 for ; Wed, 15 Aug 2001 18:03:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA08165; Wed, 15 Aug 2001 17:53:08 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 17:53:08 -0400 (EDT) Resent-Message-Id: <200108152153.RAA08165@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA08145 for ; Wed, 15 Aug 2001 17:53:03 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA25901 for ; Wed, 15 Aug 2001 17:52:56 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 15 Aug 2001 18:01:16 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 18:01:16 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB4D@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Wed, 15 Aug 2001 17:51:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Behavior of PUT on unlocked resource with invalid IF header . .. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5283 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Jason Crawford [mailto:ccjason@us.ibm.com] My opinion is that... The spec should not use the IF header for token presentation to the server. The IF header should only be used for client initiated assertion checking. The current use of IF for dual purposes just causes confusion (like I think your note indicates) and impedes our ability to potentially extend it later. We should transition to some other header for token presentation to the server. Or perhaps I just misunderstand the IF header and someone needs to clearly define it. :-) Jason: I don't see your concern here. The semantics of the If header is quite clearly defined in 2518, and says that if none of the state lists that apply to a resource match, then the request must fail with a 412. Although as indicated in a previous message, the "applies to a resource" is not well defined for no-tagged state lists, this is a general problem with the If header, and not a particular problem for lock tokens. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Aug 15 19:12:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02725 for ; Wed, 15 Aug 2001 19:12:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA12544; Wed, 15 Aug 2001 19:09:49 -0400 (EDT) Resent-Date: Wed, 15 Aug 2001 19:09:49 -0400 (EDT) Resent-Message-Id: <200108152309.TAA12544@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA12520 for ; Wed, 15 Aug 2001 19:09:32 -0400 (EDT) Received: from inet-mail3.oraclecorp.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA32623 for ; Wed, 15 Aug 2001 19:09:32 -0400 Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail3.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7FN4WP08274 for ; Wed, 15 Aug 2001 16:04:32 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-west-130-35-170-87.us.oracle.com [130.35.170.87]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f7FN90Q14889 for ; Wed, 15 Aug 2001 17:09:00 -0600 (MDT) From: "Eric Sedlar" To: "Webdav WG" Date: Wed, 15 Aug 2001 16:13:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AB47@SUS-MA1IT01> Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5284 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The other issue, Geoff, is that people are using LOCK as a poor person's CHECKOUT, also assuming that LOCK's won't timeout. The RFC2518 revision should clearly state that LOCKs aren't to be used for this purpose. --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, August 15, 2001 2:16 PM > To: Webdav WG > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > Personally, I believe that any use case that assumes a long-lived > lock is broken. Those use cases should be handled by access control, > not locks. ACL's have no timeouts, and are principal based, which > gives us a clean way of handling all the problems that have arisen > when people have tried to use locks where they should be using ACL's. > When you only use locks for short term reservations of a resource, > all of these concerns about timeouts and locks being stolen evaporate. > > With the ACL draft in last call, we no longer have any > reason to use locks as a poor man's ACL. > > Cheers, > Geoff > > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Wednesday, August 15, 2001 3:03 PM > To: Webdav WG > Subject: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > > > I'm posting in part to get our subject line to actually describe > what we're > talking about. > > And to express an opinion and questions and observations... > > I think Shaun has some points. Almost every explanation and discussion > has focused on why a client should be able to deal with the lock going > away. Given that, Shaun's reaction seems reasonable. We appear to be > undermining some of the intent of the locks if that's all we say. I can > imagine a lot of other readers of 2518's next draft scratching their head > when we say people can just pick up the token and unlock the resource. > Please let's not forget to include some mention of the fact that this > capability is recommended to be under some sort of ACL control and it > should not be possible to have one person unlock another person's > resources > willy-nilly and that it's not even required to support it. > > Note: I don't think 2518 actually requires servers to reveal the > lock token > in a the lock-discovery property. Do we care? > > I would feel a lot better about all this if we had a good > explanation about > strategies to deal with lock timeouts. How long should a client request > the time out to be in various scenarios? What pitfalls are there? What > solutions are there? What ACL strategies would work best? What refresh > strategies? > > For example, I take out the lock. I think I'll only need it for an hour. > But I have to run home and the lock times out. How must the client and > server and human behave to handle that? Should the client have > requested a > long timeout even though it didn't expect to need that much time? > > I want to lock a file, grab it, give it to a non-webDAV enabled friend to > edit. Then put it back on the server in a day or week or year. What if I > over estimate or underestimate the time needed? What if a reboot is > needed? Or we forget that we did all this or I leave the company and the > company needs to get the friend's change in there. What is the best way > to deal with these situations? Long timeouts? Frequest > refreshs? Exposed > tokens in GUI's? Lock stealing clients? Lock stealing only of your own > lock? Clients that store tokens persistantly? Servers that only expose > tokens to certain principals? Calls to the administrator? ACL > strategies? > > How do these strategies vary in different environments? At the > NSA? In a > classroom? Often workign offline? Simply on localhost? > > I'm not sure if this could go in to the draft, but perhaps we > could provide > a checklist for client (and server?) implementations and server > administrators to make sure they can handle situations like these. Or > perhaps we could discover that we only need a narrow set of optional > behaviors to chose from. > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Thu Aug 16 05:07:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26624 for ; Thu, 16 Aug 2001 05:07:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA08965; Thu, 16 Aug 2001 05:06:01 -0400 (EDT) Resent-Date: Thu, 16 Aug 2001 05:06:01 -0400 (EDT) Resent-Message-Id: <200108160906.FAA08965@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA08945 for ; Thu, 16 Aug 2001 05:05:49 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA12633 for ; Thu, 16 Aug 2001 05:05:48 -0400 Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id JAA193470 for ; Thu, 16 Aug 2001 09:46:08 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7G953j164922 for ; Thu, 16 Aug 2001 10:05:04 +0100 To: "Jason Crawford" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Thu, 16 Aug 2001 09:55:36 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 16/08/2001 10:03:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: LOCK_NULL_STATUS_CREATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5285 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: > Actually Jim wasn't disagree'ing with you on what we propose here. He was > additionally proposing that the first PUT after the resource is created *also* > return 201. I don't think that issue is on the issues list. If Jim advocates it again, > we can put it on the list. I'd object to such a proposition since it contradicts a RFC2616 SHOULD requirement for modifying an exiting resource with PUT. Regards, Tim From w3c-dist-auth-request@w3.org Thu Aug 16 10:26:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09043 for ; Thu, 16 Aug 2001 10:26:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA01714; Thu, 16 Aug 2001 10:25:33 -0400 (EDT) Resent-Date: Thu, 16 Aug 2001 10:25:33 -0400 (EDT) Resent-Message-Id: <200108161425.KAA01714@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA01680 for ; Thu, 16 Aug 2001 10:25:23 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA12146 for ; Thu, 16 Aug 2001 10:25:23 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA73442; Thu, 16 Aug 2001 10:22:44 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GEGuY33274; Thu, 16 Aug 2001 10:16:56 -0400 Importance: Normal To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 16 Aug 2001 01:45:15 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/16/2001 10:24:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Behavior of PUT on unlocked resource with invalid IF header . .. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5286 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << From: Jason Crawford [mailto:ccjason@us.ibm.com] My opinion is that... The spec should not use the IF header for token presentation to the server. The IF header should only be used for client initiated assertion checking. The current use of IF for dual purposes just causes confusion (like I think your note indicates) and impedes our ability to potentially extend it later. We should transition to some other header for token presentation to the server. Or perhaps I just misunderstand the IF header and someone needs to clearly define it. :-) Jason: I don't see your concern here. The semantics of the If header is quite clearly defined in 2518, and says that if none of the state lists that apply to a resource match, then the request must fail with a 412. Although as indicated in a previous message, the "applies to a resource" is not well defined for no-tagged state lists, this is a general problem with the If header, and not a particular problem for lock tokens. >> If that were all it said, it would be much improved, but it also says that we use the IF header for token presentation in section 7.6: In order to prevent these collisions a lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with or the method MUST fail. And it says similar things other places in the spec. But nowhere is it defined what "submitted" means. And what if all the tokens necessary are included in the IF header, but only one of them happens to be on the proper URI? Since one matches the IF criteria, so we consider the tokens to be duly sumbitted even if they guessed the wrong URL for most of the tokens. If you use a 'not' construct, can it be considered to be submitted? What if we want to extend the spec to add more sophisticated boolean logic support to the if header to test pre-conditions? Then what does it mean to use the if header to submit a token? There is too much behavior overloaded on the IF header. Let's let the IF header do what you mentioned and use another means for submitting lock tokens to assert our ownership of locks. J. From w3c-dist-auth-request@w3.org Thu Aug 16 12:15:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14845 for ; Thu, 16 Aug 2001 12:15:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13982; Thu, 16 Aug 2001 12:15:27 -0400 (EDT) Resent-Date: Thu, 16 Aug 2001 12:15:27 -0400 (EDT) Resent-Message-Id: <200108161615.MAA13982@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA13948 for ; Thu, 16 Aug 2001 12:15:19 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA29143 for ; Thu, 16 Aug 2001 12:15:20 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 16 Aug 2001 12:24:02 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 12:24:02 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB52@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 16 Aug 2001 12:24:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Behavior of PUT on unlocked resource with invalid IF header . .. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5287 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Jason Crawford [mailto:ccjason@us.ibm.com] ... it also says that we use the IF header for token presentation in section 7.6: In order to prevent these collisions a lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with or the method MUST fail. And it says similar things other places in the spec. But nowhere is it defined what "submitted" means. I agree that this is not made clear, and should be. Let's try: "Submitted" means "appears in an operator-free If header list (e.g. no "not" operator in the list) that either is a tagged list with a URI that identifies the locked resource, or is a no-tagged list. And what if all the tokens necessary are included in the IF header, but only one of them happens to be on the proper URI? By the above definition, this would not succeed. Since one matches the IF criteria, so we consider the tokens to be duly sumbitted even if they guessed the wrong URL for most of the tokens. Not by the above definition. If you use a 'not' construct, can it be considered to be submitted? Not by the above definition. What if we want to extend the spec to add more sophisticated boolean logic support to the if header to test pre-conditions? Then what does it mean to use the if header to submit a token? The "no operator in list" wording was to eliminate this concern. There is too much behavior overloaded on the IF header. Let's let the IF header do what you mentioned and use another means for submitting lock tokens to assert our ownership of locks. I agree with your point about the If header being excessively overloaded, but for compatibility with existing implementations, I'd try to fix the problem by clarifying how lock tokens should appear in If headers, rather than defining a new header. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Aug 16 18:15:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26484 for ; Thu, 16 Aug 2001 18:15:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA13423; Thu, 16 Aug 2001 18:14:53 -0400 (EDT) Resent-Date: Thu, 16 Aug 2001 18:14:53 -0400 (EDT) Resent-Message-Id: <200108162214.SAA13423@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA13399 for ; Thu, 16 Aug 2001 18:14:42 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA07016 for ; Thu, 16 Aug 2001 18:14:42 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA118600; Thu, 16 Aug 2001 18:12:03 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GM6GY13988; Thu, 16 Aug 2001 18:06:16 -0400 Importance: Normal To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 16 Aug 2001 18:13:03 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/16/2001 06:14:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Behavior of PUT on unlocked resource with invalid IF header . .. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5288 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << I agree with your point about the If header being excessively overloaded, but for compatibility with existing implementations, I'd try to fix the problem by clarifying how lock tokens should appear in If headers, rather than defining a new header. >> And I might find that acceptable, but I'd think the long term view is that we keep it seperate and orthogonal, so I'm going to continue to advocate a seperate header. First a question though: I did a quick read of the spec last night. Can there be more than one IF: header for a given request? Proposal: Let's propose a new header (for clarity of this note, let's call it "submitted-ltokens:"). We can work out what the syntax is for that after some discussion, but we could start with something similar to what Geoff proposed in his last note. This should provide a very clean spec, but we could optionally add some text to bring attention to the fact that token presentation has changed. With that spec in place, the implementations would want to implement a transition strategy. For servers, if the submitted-ltokens header is included, the prudent servers would only check that header for the purpose of token submission purposes. If the new header is not included in the request, the prudent server would check the IF header for token submission along the vaguely specified (aka unspecified) lines of 2518. In both cases, the IF header would be checked as documented by 2518 section 9.4. For prudent clients the transition strategy would be to simply submit both the new header and the if header. This would insure that they could work with old servers and new servers. Is this reasonable? J. From w3c-dist-auth-request@w3.org Thu Aug 16 19:16:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27378 for ; Thu, 16 Aug 2001 19:16:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA16456; Thu, 16 Aug 2001 19:11:00 -0400 (EDT) Resent-Date: Thu, 16 Aug 2001 19:11:00 -0400 (EDT) Resent-Message-Id: <200108162311.TAA16456@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA16436 for ; Thu, 16 Aug 2001 19:10:55 -0400 (EDT) Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA11881 for ; Thu, 16 Aug 2001 19:10:55 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA61268 for ; Thu, 16 Aug 2001 18:08:46 -0500 Received: from d03nm008.boulder.ibm.com (d03nm008.boulder.ibm.com [9.99.140.11]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7GN9bE42798 for ; Thu, 16 Aug 2001 17:09:37 -0600 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James Woods" Date: Thu, 16 Aug 2001 16:09:32 -0700 X-MIMETrack: Serialize by Router on D03NM008/03/M/IBM(Release 5.0.8 |June 18, 2001) at 08/16/2001 05:09:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: usage of href XML element Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5289 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: Hello all, I am working on a implementaion of a webdav server. The server is going to use a database for the repository. I have one issue that I am trying to clear up. Okay, I am apologizing now if I don't explain this very well.... In the database, all the resources use a unique itemid instead of the original resource name. So for example a GET www.server.com/file1.txt will have to go through a name resolver so that the database request is used with the itemid. and a PUT www.server.com/file1.txt will place this file in the database, generating a unique itemid. This is all fine, and I had planned to just create this name resolver to handle all of this, but then I was looking at the href element. I want to use the itemid as the URI for the item, and the displayname dav property to have the client show the resource name. For example, say I do a propfind on the root collection with depth 1 PROPFIND www.server.com in the properties for one of the internal members http://www.server.com/itemid1 file1.txt Now the client uses the display name to display the file in the "explorer" view, but has the href to the actual URI for requests (GET, LOCK, etc.) This is how I think these to elements were meant to be used (or at least how they could be used). Am I correct in this, or way off base? If I am correct about how these two elements can be used, then my next problem is with PUT and MCKOL. For example PUT www.server.com/file2.txt My server would place this file in the database, generate the itemid, but.... how do I get the proper URI back to the client? The 201 status returned wouldn't allow me to show the client that the proper URI to request this file is actually www.server.com/itemid2 The only way the client would be able to get the proper URI for this resource is to do a propfind depth 1 on the parent collection, and this does not appear to be the case for most of the clients I have tested. I think I know how this will turn out, but I was just wondering. Thanks, James Woods woodsja@us.ibm.com From w3c-dist-auth-request@w3.org Thu Aug 16 21:52:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29925 for ; Thu, 16 Aug 2001 21:52:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA21751; Thu, 16 Aug 2001 21:26:17 -0400 (EDT) Resent-Date: Thu, 16 Aug 2001 21:26:17 -0400 (EDT) Resent-Message-Id: <200108170126.VAA21751@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA21705 for ; Thu, 16 Aug 2001 21:26:04 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id VAA23031 for ; Thu, 16 Aug 2001 21:26:05 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 16 Aug 2001 21:35:13 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 21:35:13 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F48BC0@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 16 Aug 2001 21:35:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: usage of href XML element Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5290 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: James Woods [mailto:woodsja@us.ibm.com] I am working on a implementaion of a webdav server. The server is going to use a database for the repository. In the database, all the resources use a unique itemid instead of the original resource name. So for example a GET www.server.com/file1.txt will have to go through a name resolver so that the database request is used with the itemid. and a PUT www.server.com/file1.txt will place this file in the database, generating a unique itemid. This is all fine, and I had planned to just create this name resolver to handle all of this, but then I was looking at the href element. I want to use the itemid as the URI for the item, and the displayname dav property to have the client show the resource name. For example, say I do a propfind on the root collection with depth 1 PROPFIND www.server.com in the properties for one of the internal members http://www.server.com/itemid1 file1.txt Now the client uses the display name to display the file in the "explorer" view, but has the href to the actual URI for requests (GET, LOCK, etc.) This is how I think these to elements were meant to be used (or at least how they could be used). Am I correct in this, or way off base? Everything is OK up to here. If I am correct about how these two elements can be used, then my next problem is with PUT and MCKOL. For example PUT www.server.com/file2.txt The argument to PUT (or MKCOL or GET or any other HTTP method) will always be a URL, not the displayname. So you would have to do the PUT to a URL with the itemid, which is a problem if you want the server to generate the dbid, rather than the client. My server would place this file in the database, generate the itemid, but.... how do I get the proper URI back to the client? You can't. PUT is required to take a URL, and required to create a resource at the specified URL, not some resource at some other server generated URL. The 201 status returned wouldn't allow me to show the client that the proper URI to request this file is actually www.server.com/itemid2 The only way the client would be able to get the proper URI for this resource is to do a propfind depth 1 on the parent collection, and this does not appear to be the case for most of the clients I have tested. I think I know how this will turn out, but I was just wondering. This is probably how you thought it would turn out. If you want to have the server generated itemid's, you are better off using the "displayname" as the URL, and if you want to expose the itemid, expose it as a server defined live property value. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Aug 16 23:30:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01823 for ; Thu, 16 Aug 2001 23:30:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA25627; Thu, 16 Aug 2001 23:09:56 -0400 (EDT) Resent-Date: Thu, 16 Aug 2001 23:09:56 -0400 (EDT) Resent-Message-Id: <200108170309.XAA25627@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA25607 for ; Thu, 16 Aug 2001 23:09:51 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id XAA30266 for ; Thu, 16 Aug 2001 23:09:52 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 16 Aug 2001 23:18:59 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 23:18:59 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F48BDB@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 16 Aug 2001 23:09:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Behavior of PUT on unlocked resource with invalid IF header . .. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5291 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Jason Crawford [mailto:ccjason@us.ibm.com] [geoff] I agree with your point about the If header being excessively overloaded, but for compatibility with existing implementations, I'd try to fix the problem by clarifying how lock tokens should appear in If headers, rather than defining a new header. And I might find that acceptable, but I'd think the long term view is that we keep it seperate and orthogonal, so I'm going to continue to advocate a seperate header. I'm pretty neutral on this, so I'll go along with whatever is the consensus (assuming that there is one :-). First a question though: I did a quick read of the spec last night. Can there be more than one IF: header for a given request? Interesting question. RFC 2616 only allows multiple headers with the same value if the arguments of that header are defined to be a comma separated list. For some reason known only to the authors of 2518, the arguments to the If header are defined to be a *space* separated list, so no, there cannot be more than one If header. (Note that the DAV and the Timeout headers are defined sensibly to be a comma separated list, so you can have multiple DAV and Timeout headers). JimW et. al. What *were* you thinking?!? (:-) OK, on those grounds, I'll switch my vote to a new header, which takes a comma separated list as its argument! Proposal: Let's propose a new header (for clarity of this note, let's call it "submitted-ltokens:"). We can work out what the syntax is for that after some discussion, but we could start with something similar to what Geoff proposed in his last note. This should provide a very clean spec, but we could optionally add some text to bring attention to the fact that token presentation has changed. I pretty much abhor all abreviations, so I'd prefer something like "Lock-Token-Set". With that spec in place, the implementations would want to implement a transition strategy. For servers, if the submitted-ltokens header is included, the prudent servers would only check that header for the purpose of token submission purposes. If the new header is not included in the request, the prudent server would check the IF header for token submission along the vaguely specified (aka unspecified) lines of 2518. In both cases, the IF header would be checked as documented by 2518 section 9.4. For prudent clients the transition strategy would be to simply submit both the new header and the if header. This would insure that they could work with old servers and new servers. Is this reasonable? OK by me. I'm still shaking my head over the choice of a space separated list for the If header (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Aug 17 03:20:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20882 for ; Fri, 17 Aug 2001 03:20:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA01714; Fri, 17 Aug 2001 03:20:10 -0400 (EDT) Resent-Date: Fri, 17 Aug 2001 03:20:10 -0400 (EDT) Resent-Message-Id: <200108170720.DAA01714@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA01686 for ; Fri, 17 Aug 2001 03:19:52 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA16001 for ; Fri, 17 Aug 2001 03:19:52 -0400 Received: (qmail 22302 invoked by uid 0); 17 Aug 2001 07:19:29 -0000 Received: from p3ee24673.dip.t-dialin.net (HELO lisa) (62.226.70.115) by mail.gmx.net (mail06) with SMTP; 17 Aug 2001 07:19:29 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Fri, 17 Aug 2001 09:19:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F48BC0@SUS-MA1IT01> Subject: RE: usage of href XML element Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5292 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, August 17, 2001 3:35 AM > To: w3c-dist-auth@w3.org > Subject: RE: usage of href XML element > > ... > Now the client uses the display name to display the file in the > "explorer" > view, but has the href to the actual URI for requests (GET, LOCK, etc.) > > This is how I think these to elements were meant to be used > (or at least > how they could be used). Am I correct in this, or way off base? > > Everything is OK up to here. Note: as far as I remember, the MS webfolder client currently ignores the displayname and always use the last part of the URL. > ... From w3c-dist-auth-request@w3.org Fri Aug 17 07:59:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25338 for ; Fri, 17 Aug 2001 07:59:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA11621; Fri, 17 Aug 2001 07:57:54 -0400 (EDT) Resent-Date: Fri, 17 Aug 2001 07:57:54 -0400 (EDT) Resent-Message-Id: <200108171157.HAA11621@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA11599 for ; Fri, 17 Aug 2001 07:57:49 -0400 (EDT) Received: from www.pspl.co.in (www.pspl.co.in [202.54.11.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA06093 for ; Fri, 17 Aug 2001 07:57:43 -0400 Received: from persistent.co.in (gateway.pspl.co.in [203.199.147.2]) by www.pspl.co.in (8.11.0/8.11.0) with ESMTP id f7HBscY32315; Fri, 17 Aug 2001 17:24:38 +0530 Message-ID: <3B7D0612.101BF70C@persistent.co.in> Date: Fri, 17 Aug 2001 17:24:58 +0530 From: Rashmi Singh Organization: Persistent Systems Private Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Clemm, Geoff" CC: w3c-dist-auth@w3c.org References: <3906C56A7BD1F54593344C05BD1374B103F48BDB@SUS-MA1IT01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Behavior of PUT on unlocked resource with invalid IF header . .. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5293 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The original question still remains unanswered. Do we agree on rejecting the PUT submitted with invalid lock token on an unlocked resource. Just to make things explicit, the same applies to COPY and MOVE also. i) COPY - What if COPY is submitted with an invalid locktoken for unlocked destination? ii) MOVE - What if MOVE is submitted with an invalid locktoken for either an unlocked source or an unlocked destination? Should we return 412 (Precondition failed) in the above case? Rashmi. "Clemm, Geoff" wrote: > > From: Jason Crawford [mailto:ccjason@us.ibm.com] > > [geoff] I agree with your point about the If header being > excessively overloaded, but for compatibility with existing > implementations, I'd try to fix the problem by clarifying how lock > tokens should appear in If headers, rather than defining a new > header. > > And I might find that acceptable, but I'd think the long term view > is that we keep it seperate and orthogonal, so I'm going to > continue to advocate a seperate header. > > I'm pretty neutral on this, so I'll go along with whatever > is the consensus (assuming that there is one :-). > > First a question though: I did a quick read of the spec last night. > Can there be more than one IF: header for a given request? > > Interesting question. RFC 2616 only allows multiple headers with > the same value if the arguments of that header are defined to be > a comma separated list. For some reason known only to the authors > of 2518, the arguments to the If header are defined to be a *space* > separated list, so no, there cannot be more than one If header. > (Note that the DAV and the Timeout headers are defined sensibly > to be a comma separated list, so you can have multiple DAV and Timeout > headers). > > JimW et. al. What *were* you thinking?!? (:-) > > OK, on those grounds, I'll switch my vote to a new header, which > takes a comma separated list as its argument! > > Proposal: Let's propose a new header (for clarity of this note, let's > call > it "submitted-ltokens:"). We can work out what the syntax is for that > after some discussion, but we could start with something similar to what > Geoff proposed in his last note. This should provide a very clean spec, > but we could optionally add some text to bring attention to the fact that > token presentation has changed. > > I pretty much abhor all abreviations, so I'd prefer something like > "Lock-Token-Set". > > With that spec in place, the implementations would want to implement a > transition strategy. For servers, if the submitted-ltokens header is > included, the prudent servers would only check that header for the > purpose > of token submission purposes. If the new header is not included in the > request, the prudent server would check the IF header for token > submission > along the vaguely specified (aka unspecified) lines of 2518. In both > cases, the IF header would be checked as documented by 2518 section 9.4. > > For prudent clients the transition strategy would be to simply submit > both > the new header and the if header. This would insure that they could work > with old servers and new servers. > > Is this reasonable? > > OK by me. I'm still shaking my head over the choice of a space separated > list for the If header (:-). > > Cheers, > Geoff From w3c-dist-auth-request@w3.org Fri Aug 17 09:21:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29768 for ; Fri, 17 Aug 2001 09:21:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA16314; Fri, 17 Aug 2001 09:20:18 -0400 (EDT) Resent-Date: Fri, 17 Aug 2001 09:20:18 -0400 (EDT) Resent-Message-Id: <200108171320.JAA16314@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA16267 for ; Fri, 17 Aug 2001 09:19:58 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37113.rational.com [192.229.37.113]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA14630 for ; Fri, 17 Aug 2001 09:19:58 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 17 Aug 2001 09:28:05 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 09:21:30 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F48C38@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 17 Aug 2001 09:21:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Behavior of PUT on unlocked resource with invalid IF header . .. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5294 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Rashmi Singh [mailto:rashmi@persistent.co.in] Do we agree on rejecting the PUT submitted with invalid lock token on an unlocked resource. Just to make things explicit, the same applies to COPY and MOVE also. Assuming it is sumitted in a non-negated no-tagged list, or in a non-negated tagged list that specifies the unlocked resource, then yes (by the definition of the If header, not by any special locking semantics). i) COPY - What if COPY is submitted with an invalid locktoken for unlocked destination? Invalid, for same reason as above. ii) MOVE - What if MOVE is submitted with an invalid locktoken for either an unlocked source or an unlocked destination? You have to be specific about what you mean by "submitted", i.e. what exactly are you planning on sending in the If header? Assuming you meant the simplest thing, i.e. a non-negated no-tagged list, then yes, the locktoken must match both the source and the destination of the MOVE. What 2518 leaves open and ambiguous is whether it must also match both the source collection and the destination collection. I would argue, yes, because both of those collections are being modified by the MOVE. Should we return 412 (Precondition failed) in the above case? Yes. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Aug 17 09:57:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02145 for ; Fri, 17 Aug 2001 09:57:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA18922; Fri, 17 Aug 2001 09:57:03 -0400 (EDT) Resent-Date: Fri, 17 Aug 2001 09:57:03 -0400 (EDT) Resent-Message-Id: <200108171357.JAA18922@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA18900 for ; Fri, 17 Aug 2001 09:56:49 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA19108 for ; Fri, 17 Aug 2001 09:56:45 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA02858; Fri, 17 Aug 2001 09:56:09 -0400 Received: from 034.dhcp2.liv.opentext.com(172.17.2.34) by krusty.wl.opentext.com via smap (V2.1) id xma002849; Fri, 17 Aug 01 09:56:05 -0400 From: "Dylan Barrell" To: "Julian Reschke" , "Clemm, Geoff" , Date: Fri, 17 Aug 2001 09:55:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: usage of href XML element Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5295 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Friday, August 17, 2001 3:19 AM > To: Clemm, Geoff; w3c-dist-auth@w3.org > Subject: RE: usage of href XML element > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Friday, August 17, 2001 3:35 AM > > To: w3c-dist-auth@w3.org > > Subject: RE: usage of href XML element > > > > ... > > Now the client uses the display name to display the file in the > > "explorer" > > view, but has the href to the actual URI for requests (GET, > LOCK, etc.) > > > > This is how I think these to elements were meant to be used > > (or at least > > how they could be used). Am I correct in this, or way off base? > > > > Everything is OK up to here. > > Note: as far as I remember, the MS webfolder client currently ignores the > displayname and always use the last part of the URL. > > > ... Nope, it does not ignore the displayname. It displays the display name. From w3c-dist-auth-request@w3.org Fri Aug 17 21:02:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17777 for ; Fri, 17 Aug 2001 21:02:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA23457; Fri, 17 Aug 2001 21:01:41 -0400 (EDT) Resent-Date: Fri, 17 Aug 2001 21:01:41 -0400 (EDT) Resent-Message-Id: <200108180101.VAA23457@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA23434 for ; Fri, 17 Aug 2001 21:01:36 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA21494 for ; Fri, 17 Aug 2001 21:01:36 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA311656; Fri, 17 Aug 2001 20:58:58 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7I0rAT78826; Fri, 17 Aug 2001 20:53:10 -0400 Importance: Normal To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 17 Aug 2001 20:58:35 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/17/2001 09:01:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Behavior of PUT on unlocked resource with invalid IF header . .. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5296 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'm pretty neutral on this, so I'll go along with whatever is the consensus (assuming that there is one :-). OK, on those grounds, I'll switch my vote to a new header, which takes a comma separated list as its argument! I pretty much abhor all abreviations, so I'd prefer something like "Lock-Token-Set". If more one person pipes up in favor of spec'ing a new header for lock token presentation in principle, I'll write up a proposal..... Is anyone else supportive of this? J. From w3c-dist-auth-request@w3.org Sat Aug 18 13:26:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14121 for ; Sat, 18 Aug 2001 13:26:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA14064; Sat, 18 Aug 2001 13:22:29 -0400 (EDT) Resent-Date: Sat, 18 Aug 2001 13:22:29 -0400 (EDT) Resent-Message-Id: <200108181722.NAA14064@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA14044 for ; Sat, 18 Aug 2001 13:22:18 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA21067 for ; Sat, 18 Aug 2001 13:22:19 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA254538; Sat, 18 Aug 2001 13:19:40 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7IHDqp116800; Sat, 18 Aug 2001 13:13:52 -0400 Importance: Normal To: "Clemm, Geoff" Cc: "WebDAV (E-mail)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sat, 18 Aug 2001 13:15:22 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/18/2001 01:21:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Comments regarding locking & auto-checkin... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5297 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: Now there is some ambiguity about the meaning of "the resource to which the header is applied" and no-tag-list productions. For example, is the collection one of the resources to which the header is applied, when you delete a member of the collection? But that's a different discussion (:-). I've added that to the issues list as CLARIFY_UNTAGGED_IF_HEADER_APPLICATION From w3c-dist-auth-request@w3.org Sat Aug 18 15:27:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15041 for ; Sat, 18 Aug 2001 15:27:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA15991; Sat, 18 Aug 2001 15:23:50 -0400 (EDT) Resent-Date: Sat, 18 Aug 2001 15:23:50 -0400 (EDT) Resent-Message-Id: <200108181923.PAA15991@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA15967 for ; Sat, 18 Aug 2001 15:23:40 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA29351 for ; Sat, 18 Aug 2001 15:23:40 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA391782 for ; Sat, 18 Aug 2001 15:21:02 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7IJFEp113198 for ; Sat, 18 Aug 2001 15:15:14 -0400 Importance: Normal To: "WebDAV (E-mail)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sat, 18 Aug 2001 15:05:17 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/18/2001 03:23:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5298 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: Again. I'd like at least one more supportive comment before I file this one as resolved. Please pipe up. :-) ----------------------------------------------------------------------------------------------------------- I'd just delete the paragraph in 9.8 that states: The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. The last sentence is redundant, since it is already specified in the LOCK semantics. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Aug 19 12:30:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14507 for ; Sun, 19 Aug 2001 12:30:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA07261; Sun, 19 Aug 2001 12:26:50 -0400 (EDT) Resent-Date: Sun, 19 Aug 2001 12:26:50 -0400 (EDT) Resent-Message-Id: <200108191626.MAA07261@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA07241 for ; Sun, 19 Aug 2001 12:26:33 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA12891 for ; Sun, 19 Aug 2001 12:26:33 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA431432; Sun, 19 Aug 2001 12:23:53 -0400 Received: from sp1n351at0.watson.ibm.com (d01mlwt1.watson.ibm.com [9.2.104.68]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7JGI4w58454; Sun, 19 Aug 2001 12:18:04 -0400 Importance: Normal To: "Eric Sedlar" Cc: "Webdav WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sun, 19 Aug 2001 12:19:46 -0400 X-MIMETrack: Serialize by Router on D01MLWT1/01/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 08/19/2001 12:26:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5299 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << The other issue, Geoff, is that people are using LOCK as a poor person's CHECKOUT, also assuming that LOCK's won't timeout. >> I agree. << The RFC2518 revision should clearly state that LOCKs aren't to be used for this purpose. >> ???? - I assume the purpose of locking is to avoid lost updates. What is the distinction between a "poor man's CHECKOUT" and "avoidance of the lost update problem"? In the absense of actual versioning, aren't they the same? J. From w3c-dist-auth-request@w3.org Mon Aug 20 04:50:39 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09625 for ; Mon, 20 Aug 2001 04:50:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA08587; Mon, 20 Aug 2001 04:41:00 -0400 (EDT) Resent-Date: Mon, 20 Aug 2001 04:41:00 -0400 (EDT) Resent-Message-Id: <200108200841.EAA08587@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA08519 for ; Mon, 20 Aug 2001 04:40:43 -0400 (EDT) Received: from apollo.eurgw.xerox.com (apollo.ext.eurgw.xerox.com [212.137.33.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA14735 for ; Mon, 20 Aug 2001 04:40:39 -0400 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by apollo.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA08899 for ; Mon, 20 Aug 2001 09:40:29 +0100 (BST) Received: from [13.202.66.60] (eurdubmg03.eur.xerox.com [13.202.66.60]) by eurodns4.eur.xerox.com (8.9.3/8.9.3) with ESMTP id JAA06493 for ; Mon, 20 Aug 2001 09:40:29 +0100 (BST) Received: from eurgbrbh03.emeacinops.xerox.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 20 Aug 2001 09:33:24 +0100 Received: from gbrwgcpf01.wgc.uk.xerox.com (gbrwgcpf01.wgc.gbr.xerox.com [13.200.2.141]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id RD2RMK44; Mon, 20 Aug 2001 09:40:22 +0100 Received: by gbrwgcpf01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Aug 2001 09:40:25 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB776728761B@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'W3C WebDAV Mailing List'" Date: Mon, 20 Aug 2001 09:40:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5300 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: Agreed with Geoff. We never liked the statement anyway :-) (could be abused too easily for a start). Shaun Hall Xerox Europe > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: 18 August 2001 20:05 > To: WebDAV (E-mail) > Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS > > > > > > Again. I'd like at least one more supportive comment before > I file this > one as resolved. Please pipe up. :-) > > > -------------------------------------------------------------- > --------------------------------------------- > > > > I'd just delete the paragraph in 9.8 that states: > > The timeout counter SHOULD be restarted any time an owner > of the lock > sends a method to any member of the lock, including unsupported > methods, or methods which are unsuccessful. However the > lock MUST be > refreshed if a refresh LOCK method is successfully received. > > The last sentence is redundant, since it is already specified in the > LOCK semantics. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Tue Aug 21 00:02:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12631 for ; Tue, 21 Aug 2001 00:02:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA05748; Mon, 20 Aug 2001 23:58:14 -0400 (EDT) Resent-Date: Mon, 20 Aug 2001 23:58:14 -0400 (EDT) Resent-Message-Id: <200108210358.XAA05748@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA05728 for ; Mon, 20 Aug 2001 23:57:56 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA26848 for ; Mon, 20 Aug 2001 23:57:56 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA26410 for ; Mon, 20 Aug 2001 23:55:17 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7L3nSX45304 for ; Mon, 20 Aug 2001 23:49:28 -0400 Importance: Normal To: "Webdav WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Mon, 20 Aug 2001 23:57:02 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/20/2001 11:57:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5301 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: It sounds like we might have consensus opinion that the power to unlock someone else's locked resource should be under ACL control. Could someone that feels strongly about this propose a wording and placement in 2518 that makes this proposal concrete? Thanks, J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Aug 21 00:13:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12713 for ; Tue, 21 Aug 2001 00:13:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA06234; Tue, 21 Aug 2001 00:09:23 -0400 (EDT) Resent-Date: Tue, 21 Aug 2001 00:09:23 -0400 (EDT) Resent-Message-Id: <200108210409.AAA06234@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA06209 for ; Tue, 21 Aug 2001 00:09:03 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37119.rational.com [192.229.37.119]) by tux.w3.org (8.9.3/8.9.3) with SMTP id AAA27613 for ; Tue, 21 Aug 2001 00:09:03 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 00:18:22 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 00:18:22 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F492E3@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Tue, 21 Aug 2001 00:18:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5302 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: Well, that's a really easy change, i.e. all you have to do is absolutely nothing (:-). Currently, section 11 in 2518 places no constraints on who can do an UNLOCK operation (i.e. if you can discover the lock token, you can request an UNLOCK). The ACL spec introduces ways to constrain who can do an operation. So we're done (:-). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Monday, August 20, 2001 11:57 PM To: Webdav WG Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS It sounds like we might have consensus opinion that the power to unlock someone else's locked resource should be under ACL control. Could someone that feels strongly about this propose a wording and placement in 2518 that makes this proposal concrete? Thanks, J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Aug 21 11:30:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20426 for ; Tue, 21 Aug 2001 11:30:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA12592; Tue, 21 Aug 2001 11:29:26 -0400 (EDT) Resent-Date: Tue, 21 Aug 2001 11:29:26 -0400 (EDT) Resent-Message-Id: <200108211529.LAA12592@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA12572 for ; Tue, 21 Aug 2001 11:29:21 -0400 (EDT) Received: from inet-mail4.oraclecorp.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA28252 for ; Tue, 21 Aug 2001 11:29:21 -0400 Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail4.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7LFM8U04223 for ; Tue, 21 Aug 2001 08:22:08 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f7LFSnl26039 for ; Tue, 21 Aug 2001 09:28:49 -0600 (MDT) From: "Eric Sedlar" To: "Webdav WG" Date: Tue, 21 Aug 2001 08:34:57 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F492E3@SUS-MA1IT01> Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5303 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Should we define an UNLOCK privilege as a part of the ACL spec? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, August 20, 2001 9:19 PM > To: Webdav WG > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > Well, that's a really easy change, i.e. all you have to do is > absolutely nothing (:-). Currently, section 11 in 2518 places > no constraints on who can do an UNLOCK operation (i.e. if you > can discover the lock token, you can request an UNLOCK). The ACL spec > introduces ways to constrain who can do an operation. So we're done (:-). > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Monday, August 20, 2001 11:57 PM > To: Webdav WG > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > > > > It sounds like we might have consensus opinion that the power to unlock > someone else's locked resource should be under ACL control. > Could someone > that feels strongly about this propose a wording and placement in > 2518 that > makes this proposal concrete? > > Thanks, > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Tue Aug 21 11:41:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21155 for ; Tue, 21 Aug 2001 11:41:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA13559; Tue, 21 Aug 2001 11:41:02 -0400 (EDT) Resent-Date: Tue, 21 Aug 2001 11:41:02 -0400 (EDT) Resent-Message-Id: <200108211541.LAA13559@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA13522 for ; Tue, 21 Aug 2001 11:40:56 -0400 (EDT) Received: from inet-mail4.oraclecorp.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA29638 for ; Tue, 21 Aug 2001 11:40:56 -0400 Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail4.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7LFXhU11584 for ; Tue, 21 Aug 2001 08:33:44 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f7LFeOU04740 for ; Tue, 21 Aug 2001 09:40:24 -0600 (MDT) From: "Eric Sedlar" To: "WebDAV \(E-mail\)" Date: Tue, 21 Aug 2001 08:46:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5304 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with the current consensus that LOCKs should not be refreshed on other methods. We don't do that. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Saturday, August 18, 2001 12:05 PM > To: WebDAV (E-mail) > Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS > > > > > > Again. I'd like at least one more supportive comment before I file this > one as resolved. Please pipe up. :-) > > > ------------------------------------------------------------------ > ----------------------------------------- > > > > I'd just delete the paragraph in 9.8 that states: > > The timeout counter SHOULD be restarted any time an owner of the lock > sends a method to any member of the lock, including unsupported > methods, or methods which are unsuccessful. However the lock MUST be > refreshed if a refresh LOCK method is successfully received. > > The last sentence is redundant, since it is already specified in the > LOCK semantics. > > Cheers, > Geoff > > > > > > > > From w3c-dist-auth-request@w3.org Tue Aug 21 12:47:41 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23451 for ; Tue, 21 Aug 2001 12:47:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA18143; Tue, 21 Aug 2001 12:41:07 -0400 (EDT) Resent-Date: Tue, 21 Aug 2001 12:41:07 -0400 (EDT) Resent-Message-Id: <200108211641.MAA18143@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA18123 for ; Tue, 21 Aug 2001 12:41:02 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37119.rational.com [192.229.37.119]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA05257 for ; Tue, 21 Aug 2001 12:41:01 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 12:50:17 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 12:50:17 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB70@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Tue, 21 Aug 2001 12:40:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5305 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: OK, by me. If we do, we probably should have separate "lock" and "unlock" privileges. But I'd be happy to add this in later, if it is at all contentious. Cheers, Geoff -----Original Message----- From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com] Sent: Tuesday, August 21, 2001 11:35 AM To: Webdav WG Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Should we define an UNLOCK privilege as a part of the ACL spec? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, August 20, 2001 9:19 PM > To: Webdav WG > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > Well, that's a really easy change, i.e. all you have to do is > absolutely nothing (:-). Currently, section 11 in 2518 places > no constraints on who can do an UNLOCK operation (i.e. if you > can discover the lock token, you can request an UNLOCK). The ACL spec > introduces ways to constrain who can do an operation. So we're done (:-). > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Monday, August 20, 2001 11:57 PM > To: Webdav WG > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > > > > It sounds like we might have consensus opinion that the power to unlock > someone else's locked resource should be under ACL control. > Could someone > that feels strongly about this propose a wording and placement in > 2518 that > makes this proposal concrete? > > Thanks, > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Tue Aug 21 13:32:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24875 for ; Tue, 21 Aug 2001 13:32:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA20354; Tue, 21 Aug 2001 13:27:18 -0400 (EDT) Resent-Date: Tue, 21 Aug 2001 13:27:18 -0400 (EDT) Resent-Message-Id: <200108211727.NAA20354@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA20334 for ; Tue, 21 Aug 2001 13:27:13 -0400 (EDT) Received: from inet-mail4.oraclecorp.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10238 for ; Tue, 21 Aug 2001 13:27:13 -0400 Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail4.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7LHK0U16118; Tue, 21 Aug 2001 10:20:01 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f7LHQfU06673; Tue, 21 Aug 2001 11:26:41 -0600 (MDT) From: "Eric Sedlar" To: "Jason Crawford" Cc: "Webdav WG" Date: Tue, 21 Aug 2001 10:32:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5306 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well, checkout doesn't allow things to timeout, nor can you grab a resource checked out into another workspace the way you can grab somebody else's lock. > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Sunday, August 19, 2001 9:20 AM > To: Eric Sedlar > Cc: Webdav WG > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > > << > The other issue, Geoff, is that people are using LOCK as a poor person's > CHECKOUT, also assuming that LOCK's won't timeout. > >> > I agree. > > << > The RFC2518 revision > should clearly state that LOCKs aren't to be used for this purpose. > >> > ???? - I assume the purpose of locking is to avoid lost updates. What is > the distinction between a "poor man's CHECKOUT" and "avoidance > of the lost > update problem"? In the absense of actual versioning, aren't they the > same? > > J. > > > From w3c-dist-auth-request@w3.org Tue Aug 21 14:28:26 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26738 for ; Tue, 21 Aug 2001 14:28:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA23988; Tue, 21 Aug 2001 14:27:45 -0400 (EDT) Resent-Date: Tue, 21 Aug 2001 14:27:45 -0400 (EDT) Resent-Message-Id: <200108211827.OAA23988@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA23947 for ; Tue, 21 Aug 2001 14:27:27 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37119.rational.com [192.229.37.119]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA16361 for ; Tue, 21 Aug 2001 14:27:28 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 14:36:47 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 14:36:47 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB72@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Tue, 21 Aug 2001 14:36:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5307 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'd probably avoid the whole "when is a checkout like a lock" discussion. They are pretty much orthogonal concepts, where a checkout takes an unwriteable thing, and makes it writeable (or makes a writeable copy of it), while a lock takes a writeable thing and limits who can write to it. So locking a checked-out thing can be a sensible thing to do (i.e. now that it is writeable, you want to limit who can write to it), and even locking a checked-in thing can be sensible (if you want to limit who can update the live properties that are affected by locking but are not affected by the resource being checked in). Cheers, Geoff -----Original Message----- From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com] Sent: Tuesday, August 21, 2001 1:33 PM To: Jason Crawford Cc: Webdav WG Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Well, checkout doesn't allow things to timeout, nor can you grab a resource checked out into another workspace the way you can grab somebody else's lock. > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Sunday, August 19, 2001 9:20 AM > To: Eric Sedlar > Cc: Webdav WG > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > > << > The other issue, Geoff, is that people are using LOCK as a poor person's > CHECKOUT, also assuming that LOCK's won't timeout. > >> > I agree. > > << > The RFC2518 revision > should clearly state that LOCKs aren't to be used for this purpose. > >> > ???? - I assume the purpose of locking is to avoid lost updates. What is > the distinction between a "poor man's CHECKOUT" and "avoidance > of the lost > update problem"? In the absense of actual versioning, aren't they the > same? > > J. > > > From w3c-dist-auth-request@w3.org Tue Aug 21 18:21:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02765 for ; Tue, 21 Aug 2001 18:21:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA09351; Tue, 21 Aug 2001 18:20:25 -0400 (EDT) Resent-Date: Tue, 21 Aug 2001 18:20:25 -0400 (EDT) Resent-Message-Id: <200108212220.SAA09351@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA09327 for ; Tue, 21 Aug 2001 18:20:14 -0400 (EDT) Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA09176 for ; Tue, 21 Aug 2001 18:20:14 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA60558 for ; Tue, 21 Aug 2001 18:18:04 -0400 Received: from d03nm008.boulder.ibm.com (d03nm008.boulder.ibm.com [9.99.140.11]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7LMKDA253324 for ; Tue, 21 Aug 2001 16:20:13 -0600 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James Woods" Date: Tue, 21 Aug 2001 15:20:10 -0700 X-MIMETrack: Serialize by Router on D03NM008/03/M/IBM(Release 5.0.8 |June 18, 2001) at 08/21/2001 04:20:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Question about the creationdate property Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5308 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: Hello all, I was looking at the discusion about the what DAV properties were writable by the client and the summary of consensus http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0071.html my question is on creationdate. I had assumed that this property represented when the file was created, but how am I supposed to tell the server when the creation date was if the property is protected? For example. I created a document a week ago, and it currently resides on my local file system. I decide to place this document on the Web using my favorite protocol, WebDAV, with a PUT. So, how do I (the client) tell the server the original creationdate since I can not do a PROPPATCH? Is there a way send this property value along with the PUT? Or does creationdate represent when my document was created as a WebDav Compliant Resource and reflects the timestamp of the PUT? Thanks, James Woods woodsja@us.ibm.com From w3c-dist-auth-request@w3.org Tue Aug 21 18:26:36 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02817 for ; Tue, 21 Aug 2001 18:26:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA09490; Tue, 21 Aug 2001 18:25:51 -0400 (EDT) Resent-Date: Tue, 21 Aug 2001 18:25:51 -0400 (EDT) Resent-Message-Id: <200108212225.SAA09490@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA09470 for ; Tue, 21 Aug 2001 18:25:36 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37119.rational.com [192.229.37.119]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA09562 for ; Tue, 21 Aug 2001 18:25:37 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 18:34:55 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 18:34:55 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB76@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Tue, 21 Aug 2001 18:35:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Question about the creationdate property Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5309 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: Yes, the DAV:creationdate is the servers idea of the creation date (i.e. when the resource was first created on the server), not some clients idea of the creationdate (this is consistent with how dates in general are handled in HTTP). Cheers, Geoff -----Original Message----- From: James Woods [mailto:woodsja@us.ibm.com] Sent: Tuesday, August 21, 2001 6:20 PM To: w3c-dist-auth@w3.org Subject: Question about the creationdate property Hello all, I was looking at the discusion about the what DAV properties were writable by the client and the summary of consensus http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0071.html my question is on creationdate. I had assumed that this property represented when the file was created, but how am I supposed to tell the server when the creation date was if the property is protected? For example. I created a document a week ago, and it currently resides on my local file system. I decide to place this document on the Web using my favorite protocol, WebDAV, with a PUT. So, how do I (the client) tell the server the original creationdate since I can not do a PROPPATCH? Is there a way send this property value along with the PUT? Or does creationdate represent when my document was created as a WebDav Compliant Resource and reflects the timestamp of the PUT? Thanks, James Woods woodsja@us.ibm.com From w3c-dist-auth-request@w3.org Wed Aug 22 04:27:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27557 for ; Wed, 22 Aug 2001 04:27:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA07676; Wed, 22 Aug 2001 04:27:15 -0400 (EDT) Resent-Date: Wed, 22 Aug 2001 04:27:15 -0400 (EDT) Resent-Message-Id: <200108220827.EAA07676@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA07656 for ; Wed, 22 Aug 2001 04:26:59 -0400 (EDT) Received: from inet4all.net (inet4all.net [216.121.191.48]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA22365 for ; Wed, 22 Aug 2001 04:26:59 -0400 Received: from cad ([212.12.59.25]) by inet4all.net (8.9.3/8.9.3) with ESMTP id KAA14592 for ; Wed, 22 Aug 2001 10:26:58 +0200 Message-ID: <011901c12ae4$2cae1200$be00a8c0@wegalink.pro> From: "Eckhard Kantz" To: References: <3906C56A7BD1F54593344C05BD1374B103F48771@SUS-MA1IT01> Date: Wed, 22 Aug 2001 10:26:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Re: IETF-51 WebDAV WG meeting minutes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5310 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, Ordered collections have been applied in a web server that generates an automatic menu in the browser screen (http://www.simplecms.de:8000). The question that came up in a discussion was how to expose that feature to webdav clients that are supposed to maintain the directory structure and content? Would it be appropriate to implement the draft-ietf-webdav-ordering-protocol-02? Are there known clients that could support this? Thanks for any advice. Eckhard -----Ursprüngliche Nachricht----- Von: "Clemm, Geoff" An: Gesendet: Mittwoch, 15. August 2001 16:10 Betreff: RE: IETF-51 WebDAV WG meeting minutes > > > From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com] > > - Question: What remains to do in the WebDAV WG charter? Advanced > collections, redirect references, properties registry doc., ordered > collections, and raising DAV to a draft standard. > > - This remaining work is probably just lacking an editor/champion. > The WG should push them forward or drop them if there is no > interest in the work being done. > > In the past, JimW has expressed interest in doing the final editing > round on the advanced collection protocols (binding, redirect > references, ordered collections). With the DeltaV protocol nearing > completion, I would be willing to do the final editing round on the > binding protocol. Anyone want to volunteer as editor for the redirect > reference or ordered collection protocols, in case JimW does not have > time to take care of this? > > Cheers, > Geoff From w3c-dist-auth-request@w3.org Fri Aug 24 00:43:14 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08912 for ; Fri, 24 Aug 2001 00:43:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA20106; Fri, 24 Aug 2001 00:41:12 -0400 (EDT) Resent-Date: Fri, 24 Aug 2001 00:41:12 -0400 (EDT) Resent-Message-Id: <200108240441.AAA20106@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA20086 for ; Fri, 24 Aug 2001 00:40:58 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA23687 for ; Fri, 24 Aug 2001 00:40:56 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 7DFDF49B6A; Fri, 24 Aug 2001 14:40:13 +1000 (EST) Date: Fri, 24 Aug 2001 14:40:13 +1000 From: Alan Kent To: WebDAV Message-ID: <20010824144013.J3597@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Subject: Infinite depth locks and unlocking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5311 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: Since locking is a bit of a rage at the moment, I just wanted to clarify something relating to infinite depth locks. I believe according to the spec that if I do a depth infinity lock on /a/b/c then if I do an unlock on /a/b/c/d/e using the same lock token, the lock is completely removed from all resources (that is, from /a/b/c down). Other possible interpretations that I think are not what the spec says are (1) /a/b/c stays locked, only /a/b/c/d/e (and descdenants) are unlocked (2) You are not permitted to unlock /a/b/c/d/e - you should unlock /a/b/c I also noticed that if you successfully delete a resource (a binding?) then 'all its locks are removed' which for a depth infinity lock implies that if you delete /a/b/c/d/e then the lock on /a/b/c would also be unlocked. With the recent lock and lock null resource discussion, I was trying to rethink what is the best way to implement locking with depth infinity. I had previously come to the opinion that the easiest approach to get the semantics right was to keep a lock table of URLs - not apply the locks to the real resources. This is because you do not unlock single resources, you remove the depth infinity lock from the table. (There might have been other reasons as well.) But the current semantics of depth infinity lock is not the same as depth 0 locking all of the resources in the tree. This creates weird edge cases (such as above) which I am not 100% of sure the correct/best way to resolve. Does anyone use depth infinity locks? How have people implemented them such that deleting /a/b/c/d/e will remove the lock on the whole tree? Or am I missing something here? Thanks! Alan From w3c-dist-auth-request@w3.org Fri Aug 24 09:17:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04332 for ; Fri, 24 Aug 2001 09:17:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA04441; Fri, 24 Aug 2001 09:16:07 -0400 (EDT) Resent-Date: Fri, 24 Aug 2001 09:16:07 -0400 (EDT) Resent-Message-Id: <200108241316.JAA04441@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA04267 for ; Fri, 24 Aug 2001 09:15:48 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37119.rational.com [192.229.37.119]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA30851 for ; Fri, 24 Aug 2001 09:15:48 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 24 Aug 2001 09:25:16 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 09:25:16 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10405C9A2@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Fri, 24 Aug 2001 09:25:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Infinite depth locks and unlocking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5312 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I believe the only sensible way to interpret depth infinity locks are to say that: - the lock is "on" the URL that was locked - the lock "affects" the resource mapped to that URL, and if that resource is a collection, then it "affects" all members of that collection. This means that we should extend the current lock discovery information with the URL that the lock is "on", so that a client knows the scope of the lock. If this were added, it would be reasonable to require a client to issue the UNLOCK against the locked URL. The alternative is to allow the UNLOCK to be applied to any URL that identifies a resource that is affected by the lock. I could live with that, if the working group prefers it, but I prefer the "must unlock the locked URL" approach. For one thing, it is more compatible with the approach taken by the ACL spec for inherited ACEs (i.e. you cannot change inherited ACEs). Cheers, Geoff -----Original Message----- From: Alan Kent [mailto:ajk@mds.rmit.edu.au] Sent: Friday, August 24, 2001 12:40 AM To: WebDAV Subject: Infinite depth locks and unlocking Since locking is a bit of a rage at the moment, I just wanted to clarify something relating to infinite depth locks. I believe according to the spec that if I do a depth infinity lock on /a/b/c then if I do an unlock on /a/b/c/d/e using the same lock token, the lock is completely removed from all resources (that is, from /a/b/c down). Other possible interpretations that I think are not what the spec says are (1) /a/b/c stays locked, only /a/b/c/d/e (and descdenants) are unlocked (2) You are not permitted to unlock /a/b/c/d/e - you should unlock /a/b/c I also noticed that if you successfully delete a resource (a binding?) then 'all its locks are removed' which for a depth infinity lock implies that if you delete /a/b/c/d/e then the lock on /a/b/c would also be unlocked. With the recent lock and lock null resource discussion, I was trying to rethink what is the best way to implement locking with depth infinity. I had previously come to the opinion that the easiest approach to get the semantics right was to keep a lock table of URLs - not apply the locks to the real resources. This is because you do not unlock single resources, you remove the depth infinity lock from the table. (There might have been other reasons as well.) But the current semantics of depth infinity lock is not the same as depth 0 locking all of the resources in the tree. This creates weird edge cases (such as above) which I am not 100% of sure the correct/best way to resolve. Does anyone use depth infinity locks? How have people implemented them such that deleting /a/b/c/d/e will remove the lock on the whole tree? Or am I missing something here? Thanks! Alan From w3c-dist-auth-request@w3.org Fri Aug 24 13:07:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09844 for ; Fri, 24 Aug 2001 13:07:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11729; Fri, 24 Aug 2001 13:06:05 -0400 (EDT) Resent-Date: Fri, 24 Aug 2001 13:06:05 -0400 (EDT) Resent-Message-Id: <200108241706.NAA11729@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA11705 for ; Fri, 24 Aug 2001 13:05:54 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37119.rational.com [192.229.37.119]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA21603 for ; Fri, 24 Aug 2001 13:05:54 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 24 Aug 2001 13:15:23 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 13:15:23 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB82@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Fri, 24 Aug 2001 13:15:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Infinite depth locks and unlocking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5314 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The problem with not saying where the lock is, is that the lock token doesn't need to be a URL (i.e. it might not be something you can send a HTTP request to). So you need to send the UNLOCK request to a resource that is guaranteed to understand it, which for sure is the locked URL, and almost for sure is any child of the locked URL (since all those children are affected by the Depth:infinity lock). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Friday, August 24, 2001 10:16 AM To: Clemm, Geoff Cc: WebDAV Subject: RE: Infinite depth locks and unlocking << If this were added, it would be reasonable to require a client to issue the UNLOCK against the locked URL. The alternative is to allow the UNLOCK to be applied to any URL that identifies a resource that is affected by the lock. I could live with that, if the working group prefers it, but I prefer the "must unlock the locked URL" approach. >> I'd even be comfortable with the approach that you don't even have to say where the lock is. The lock is supposed to be globally unique. And if the client wants to verify that it understands where the lock is, it could use an IF header. (Actually right now the IF header is used for UNLOCK, but changing that is on the issues list.) Of course if we feel the *server* *always* needs to verify the client's knowledge of the lock location, I can live with that too. J. From w3c-dist-auth-request@w3.org Fri Aug 24 13:45:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10706 for ; Fri, 24 Aug 2001 13:45:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA13574; Fri, 24 Aug 2001 13:45:20 -0400 (EDT) Resent-Date: Fri, 24 Aug 2001 13:45:20 -0400 (EDT) Resent-Message-Id: <200108241745.NAA13574@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA13554 for ; Fri, 24 Aug 2001 13:45:15 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA28945 for ; Fri, 24 Aug 2001 13:45:15 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA144750 for ; Fri, 24 Aug 2001 13:42:34 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7OHaiL182682 for ; Fri, 24 Aug 2001 13:36:44 -0400 Importance: Normal To: Webdav WG X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 24 Aug 2001 13:30:26 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/24/2001 01:44:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5315 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: Just so it doesn't get overlooked.... do we agree with what Geoff has said below? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Clemm, Geoff" @w3.org on 08/21/2001 12:18:30 AM Sent by: w3c-dist-auth-request@w3.org To: Webdav WG cc: Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Well, that's a really easy change, i.e. all you have to do is absolutely nothing (:-). Currently, section 11 in 2518 places no constraints on who can do an UNLOCK operation (i.e. if you can discover the lock token, you can request an UNLOCK). The ACL spec introduces ways to constrain who can do an operation. So we're done (:-). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Monday, August 20, 2001 11:57 PM To: Webdav WG Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS It sounds like we might have consensus opinion that the power to unlock someone else's locked resource should be under ACL control. Could someone that feels strongly about this propose a wording and placement in 2518 that makes this proposal concrete? Thanks, J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Aug 24 15:18:39 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12994 for ; Fri, 24 Aug 2001 15:18:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA18208; Fri, 24 Aug 2001 15:16:10 -0400 (EDT) Resent-Date: Fri, 24 Aug 2001 15:16:10 -0400 (EDT) Resent-Message-Id: <200108241916.PAA18208@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA18186 for ; Fri, 24 Aug 2001 15:16:03 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05482 for ; Fri, 24 Aug 2001 15:16:00 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA02244 for ; Fri, 24 Aug 2001 12:16:02 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 24 Aug 2001 12:12:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: How can an HTTP 1.1 client force a challenge Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5316 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added Peter to the accept2 list, so future emails from him will go straight through to the list. - Jim -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Friday, August 24, 2001 10:26 AM To: 'w3c-dist-auth@w3.org' Cc: 'slawrence@virata.com'; 'ejw@cse.uscs.edu'; 'bartman@process.com' Subject: [Moderator Action] How can an HTTP 1.1 client force a challenge All, Sorry to post this HTTP 1.1 question to your DL but the official HTTP 1.1 DL is no longer active. The IETF Working Group for the Internet Printing Protocol (IPP). (IPP is described in rfc2910, rfc2911) We have the following issue and solution and would like your opinion. From an HTTP 1.1 standpoint is the solution valid? ISSUE: How can a client force an HTTP server to issue a challenge before the client sends a POST body containing a lot of data? BACKGROUND: IPP v1.1 is carried over HTTP 1.1 via a POST. The IPP operation Print-Job carries the desired printing instructions (e.g. two-sided, stapled) followed by the print data in the same HTTP request. In some instances the job may be large. In other cases the print data is being generated on the fly and cannot be easily regenerated. The IPP Implementer's Guide needs to recommend how IPP Clients and Printers should use the HTTP 1.1 protocol to provide an interoperable IPP operation that accommodates security challenges. SOLUTION: 1. The client sends an HTTP request header containing the "Expect:100-continue" header field, but waits before transmitting the request body. 2. The Printer (i.e. server) examines the HTTP header and decides whether or not to accept the HTTP request. 3a. If the Printer accepts the HTTP request, it sends a 100(Continue) response and continues to read from the input stream. Go to 4a. 3b If the Printer requires authentication, it rejects the request with 401 (Unauthorized) status and a "WWW-Authenticate" header field containing at least one challenge. Go to 4b. 4a. If the client receives a 100 (Continue) response, it now has a reasonable expectation that the HTTP request will succeed. The client now transmits the request body which contains the IPP printing instructions and print data. Go to 5. 4b. If the client receives a challenge, it sends a new HTTP request header containing an "Authorization" header field and an "Expect: 100-continue" header field. Go to 3a. 5. After the Printer receives and processes the HTTP request body, it sends a final HTTP status code in response. Thanks for any guidance you can offer. Peter Zehler XEROX Xerox Architecture Center Email: PZehler@crt.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-69E Webster NY, 14580-9701 From w3c-dist-auth-request@w3.org Fri Aug 24 16:47:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15165 for ; Fri, 24 Aug 2001 16:47:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA08856; Fri, 24 Aug 2001 11:45:58 -0400 (EDT) Resent-Date: Fri, 24 Aug 2001 11:45:58 -0400 (EDT) Resent-Message-Id: <200108241545.LAA08856@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA08399 for ; Fri, 24 Aug 2001 11:45:01 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA04549 for ; Fri, 24 Aug 2001 10:21:21 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA400314; Fri, 24 Aug 2001 10:18:26 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7OECSL141702; Fri, 24 Aug 2001 10:12:28 -0400 Importance: Normal To: "Clemm, Geoff" Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 24 Aug 2001 10:16:13 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/24/2001 10:20:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Infinite depth locks and unlocking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5313 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: << If this were added, it would be reasonable to require a client to issue the UNLOCK against the locked URL. The alternative is to allow the UNLOCK to be applied to any URL that identifies a resource that is affected by the lock. I could live with that, if the working group prefers it, but I prefer the "must unlock the locked URL" approach. >> I'd even be comfortable with the approach that you don't even have to say where the lock is. The lock is supposed to be globally unique. And if the client wants to verify that it understands where the lock is, it could use an IF header. (Actually right now the IF header is used for UNLOCK, but changing that is on the issues list.) Of course if we feel the *server* *always* needs to verify the client's knowledge of the lock location, I can live with that too. J. From w3c-dist-auth-request@w3.org Fri Aug 24 19:35:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17001 for ; Fri, 24 Aug 2001 19:35:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA04899; Fri, 24 Aug 2001 19:34:41 -0400 (EDT) Resent-Date: Fri, 24 Aug 2001 19:34:41 -0400 (EDT) Resent-Message-Id: <200108242334.TAA04899@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA04879 for ; Fri, 24 Aug 2001 19:34:32 -0400 (EDT) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA32000 for ; Fri, 24 Aug 2001 19:34:31 -0400 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id f7ONYVF11204 for ; Fri, 24 Aug 2001 16:34:31 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f7ONXYb24608 for ; Fri, 24 Aug 2001 16:33:34 -0700 (PDT) Received: from larrypad ([153.32.67.7]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with SMTP id GILISC00.E0N; Fri, 24 Aug 2001 16:33:48 -0700 From: "Larry Masinter - LMM@acm.org" To: Cc: "Jim Whitehead" , "WebDAV" Date: Fri, 24 Aug 2001 16:32:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Subject: RE: How can an HTTP 1.1 client force a challenge Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5317 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit # Sorry to post this HTTP 1.1 question to your DL but the official HTTP 1.1 DL # is no longer active. .... The HTTP 1.1 DL (mailing list) is still active: http-wg@hplb.hpl.hp.com archived at http://groups.yahoo.com/group/http-wg/ and (somewhat unreliably) at http://www.ics.uci.edu/pub/ietf/http/hypermail/ From w3c-dist-auth-request@w3.org Sun Aug 26 01:36:46 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23631 for ; Sun, 26 Aug 2001 01:36:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA14875; Sun, 26 Aug 2001 01:34:57 -0400 (EDT) Resent-Date: Sun, 26 Aug 2001 01:34:57 -0400 (EDT) Resent-Message-Id: <200108260534.BAA14875@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA14851 for ; Sun, 26 Aug 2001 01:34:51 -0400 (EDT) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA30357 for ; Sun, 26 Aug 2001 01:34:51 -0400 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id f7Q5YpF13319 for ; Sat, 25 Aug 2001 22:34:51 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f7Q5YO213230 for ; Sat, 25 Aug 2001 22:34:24 -0700 (PDT) Received: from larrypad ([130.248.184.135]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with SMTP id GINU4W00.IAQ for ; Sat, 25 Aug 2001 22:34:08 -0700 From: "Larry Masinter" To: Date: Sat, 25 Aug 2001 22:33:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: content-location vs. location for "/" appending? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5318 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit RFC 2518 says: There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names. However, "Content-Location" as a header in RFC 2616 (section 14.14) refers to the location of the entity body, not the revised location of the resource. If you're going to supply a new location in response to, for example, a PROPFIND, I think you should use the "Location:" header and not "Content-Location". I know at the interop there were some difficulties with trailing slash equivalences for collections, so maybe this is something that can be fixed. From w3c-dist-auth-request@w3.org Sun Aug 26 14:36:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14837 for ; Sun, 26 Aug 2001 14:36:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA00234; Sun, 26 Aug 2001 14:36:04 -0400 (EDT) Resent-Date: Sun, 26 Aug 2001 14:36:04 -0400 (EDT) Resent-Message-Id: <200108261836.OAA00234@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA00210 for ; Sun, 26 Aug 2001 14:35:59 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA21238 for ; Sun, 26 Aug 2001 14:35:58 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Sun, 26 Aug 2001 19:35:57 +0100 Received: from cs.bris.ac.uk (lama [137.222.102.207]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id TAA28188 for ; Sun, 26 Aug 2001 19:34:37 +0100 (BST) Message-ID: <3B89413D.18696CBD@cs.bris.ac.uk> Date: Sun, 26 Aug 2001 19:34:37 +0100 From: Bita Shadgar Organization: Bristol Computer Science Dept X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Inheritance on properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5319 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I am wondering if anybody let me know, has the inheritance been considered on properties of resources in Webdav? Consider you have a lots of resource with the same properties. If you have inheritance, you can easily store one copy of properties and it can be inherited to other resources with the same properties. Indeed, what is preparationed in Webdav if a resource has a property with more than one value. I know it is considered in RDF, however I think it may be necessary to be a part of Webdav. So that all Webdav projects support it intrinsically. What do you think? Any discussion and pointer will be appreciated, Bita. From w3c-dist-auth-request@w3.org Sun Aug 26 21:01:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16969 for ; Sun, 26 Aug 2001 21:01:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA12016; Sun, 26 Aug 2001 21:01:11 -0400 (EDT) Resent-Date: Sun, 26 Aug 2001 21:01:11 -0400 (EDT) Resent-Message-Id: <200108270101.VAA12016@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA11992 for ; Sun, 26 Aug 2001 21:01:04 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA14610 for ; Sun, 26 Aug 2001 21:01:04 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA03672; Sun, 26 Aug 2001 18:02:16 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sun, 26 Aug 2001 18:02:16 -0700 From: Greg Stein To: Jason Crawford Cc: Webdav WG Message-ID: <20010826180216.G3499@lyra.org> Mail-Followup-To: Jason Crawford , Webdav WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ccjason@us.ibm.com on Fri, Aug 24, 2001 at 01:30:26PM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5320 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: It is fine with me, as long as a server can refuse the UNLOCK even if it does not implement the ACL specification. Cheers, -g On Fri, Aug 24, 2001 at 01:30:26PM -0400, Jason Crawford wrote: > > > Just so it doesn't get overlooked.... do we agree with what Geoff has said > below? > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > "Clemm, Geoff" @w3.org on 08/21/2001 12:18:30 AM > > Sent by: w3c-dist-auth-request@w3.org > > > To: Webdav WG > cc: > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > Well, that's a really easy change, i.e. all you have to do is > absolutely nothing (:-). Currently, section 11 in 2518 places > no constraints on who can do an UNLOCK operation (i.e. if you > can discover the lock token, you can request an UNLOCK). The ACL spec > introduces ways to constrain who can do an operation. So we're done (:-). > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Monday, August 20, 2001 11:57 PM > To: Webdav WG > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > > > > It sounds like we might have consensus opinion that the power to unlock > someone else's locked resource should be under ACL control. Could someone > that feels strongly about this propose a wording and placement in 2518 that > makes this proposal concrete? > > Thanks, > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Aug 27 09:54:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18607 for ; Mon, 27 Aug 2001 09:54:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA12005; Mon, 27 Aug 2001 09:53:53 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 09:53:53 -0400 (EDT) Resent-Message-Id: <200108271353.JAA12005@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA11984 for ; Mon, 27 Aug 2001 09:53:45 -0400 (EDT) Received: from mailgate.excosoft.se (mailgate.excosoft.se [193.15.188.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA10319 for ; Mon, 27 Aug 2001 09:53:44 -0400 Received: from bombadill ([192.9.200.49]) by mailgate.excosoft.se (8.9.3/8.9.3) with SMTP id PAA02285 for ; Mon, 27 Aug 2001 15:53:01 +0200 (MET DST) From: "Rickard Falk" To: Date: Mon, 27 Aug 2001 15:53:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id JAA11984 Subject: Getcontentlength & GetContentType Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5321 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit What should I respond if a client asks for the properties Getcontentlength or GetContentType on a collection? The spec states: "The getcontentlength property MUST be defined on any DAV compliant resource that returns the Content-Length header in response to a GET." But it doesn't say, if the value a supposed to be the same as if I perform a 'Get' on that url. The collection itself doesn't normally have a content, so does this mean that if the collection have a default page. That it should return the values of that page? Or if the server is set to send a generated HTML page listing the children, should the values be text/html and the size of that page? Or have I missed something in the spec? /Rickard Falk From w3c-dist-auth-request@w3.org Mon Aug 27 10:39:09 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20316 for ; Mon, 27 Aug 2001 10:39:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA14083; Mon, 27 Aug 2001 10:37:03 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 10:37:03 -0400 (EDT) Resent-Message-Id: <200108271437.KAA14083@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA14059 for ; Mon, 27 Aug 2001 10:36:42 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA15866 for ; Mon, 27 Aug 2001 10:36:41 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id KAA19316; Mon, 27 Aug 2001 10:36:05 -0400 Received: from 242.dhcp3.liv.opentext.com(172.17.3.242) by krusty.wl.opentext.com via smap (V2.1) id xma019305; Mon, 27 Aug 01 10:36:02 -0400 From: "Dylan Barrell" To: "Rickard Falk" , Date: Mon, 27 Aug 2001 10:35:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: Getcontentlength & GetContentType Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5322 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit GET on a collection is not covered by DAV. You want to get the contents of a collection, then do a PROPFIND. You therefore don't have to maintain those proprties for collections (they also don't make sense). --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Rickard Falk > Sent: Monday, August 27, 2001 9:53 AM > To: w3c-dist-auth@w3.org > Subject: Getcontentlength & GetContentType > > > What should I respond if a client asks for the properties > Getcontentlength or GetContentType on a collection? > The spec states: > "The getcontentlength property MUST be defined on any > DAV compliant resource that returns the Content-Length header in > response to a GET." > > But it doesn't say, if the value a supposed to be the same as if > I perform a 'Get' on that url. The collection itself doesn't > normally have a content, so does this mean that if the collection > have a default page. That it should return the values of that > page? Or if the server is set to send a generated HTML page > listing the children, should the values be text/html and the size > of that page? > > Or have I missed something in the spec? > > /Rickard Falk From w3c-dist-auth-request@w3.org Mon Aug 27 10:44:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20442 for ; Mon, 27 Aug 2001 10:44:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA14711; Mon, 27 Aug 2001 10:44:05 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 10:44:05 -0400 (EDT) Resent-Message-Id: <200108271444.KAA14711@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA14689 for ; Mon, 27 Aug 2001 10:43:50 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA16744 for ; Mon, 27 Aug 2001 10:43:50 -0400 Received: (qmail 28930 invoked by uid 0); 27 Aug 2001 14:43:19 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 27 Aug 2001 14:43:19 -0000 From: "Julian Reschke" To: "Dylan Barrell" , "Rickard Falk" , Date: Mon, 27 Aug 2001 16:43:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: Getcontentlength & GetContentType Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5323 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit WebDAV should still say what it means if a property "must be defined", but doesn't have a value... > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > Sent: Monday, August 27, 2001 4:36 PM > To: Rickard Falk; w3c-dist-auth@w3.org > Subject: RE: Getcontentlength & GetContentType > > > GET on a collection is not covered by DAV. You want to get the > contents of a > collection, then do a PROPFIND. > > You therefore don't have to maintain those proprties for collections (they > also don't make sense). > > --Dylan > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Rickard Falk > > Sent: Monday, August 27, 2001 9:53 AM > > To: w3c-dist-auth@w3.org > > Subject: Getcontentlength & GetContentType > > > > > > What should I respond if a client asks for the properties > > Getcontentlength or GetContentType on a collection? > > The spec states: > > "The getcontentlength property MUST be defined on any > > DAV compliant resource that returns the Content-Length header in > > response to a GET." > > > > But it doesn't say, if the value a supposed to be the same as if > > I perform a 'Get' on that url. The collection itself doesn't > > normally have a content, so does this mean that if the collection > > have a default page. That it should return the values of that > > page? Or if the server is set to send a generated HTML page > > listing the children, should the values be text/html and the size > > of that page? > > > > Or have I missed something in the spec? > > > > /Rickard Falk > From w3c-dist-auth-request@w3.org Mon Aug 27 11:09:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21167 for ; Mon, 27 Aug 2001 11:09:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA16115; Mon, 27 Aug 2001 11:06:31 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 11:06:31 -0400 (EDT) Resent-Message-Id: <200108271506.LAA16115@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA16087 for ; Mon, 27 Aug 2001 11:06:16 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA19585 for ; Mon, 27 Aug 2001 11:06:16 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id LAA28817; Mon, 27 Aug 2001 11:05:41 -0400 Received: from 242.dhcp3.liv.opentext.com(172.17.3.242) by krusty.wl.opentext.com via smap (V2.1) id xmaa28792; Mon, 27 Aug 01 11:05:39 -0400 From: "Dylan Barrell" To: "Julian Reschke" , "Rickard Falk" , Date: Mon, 27 Aug 2001 11:05:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: Getcontentlength & GetContentType Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5324 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit What does it mean to have a property that must be defined, but has no meaningful value? It means your spec has a design flaw. What is an example of such a thing? --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Monday, August 27, 2001 10:43 AM > To: Dylan Barrell; Rickard Falk; w3c-dist-auth@w3.org > Subject: RE: Getcontentlength & GetContentType > > > WebDAV should still say what it means if a property "must be defined", but > doesn't have a value... > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > > Sent: Monday, August 27, 2001 4:36 PM > > To: Rickard Falk; w3c-dist-auth@w3.org > > Subject: RE: Getcontentlength & GetContentType > > > > > > GET on a collection is not covered by DAV. You want to get the > > contents of a > > collection, then do a PROPFIND. > > > > You therefore don't have to maintain those proprties for > collections (they > > also don't make sense). > > > > --Dylan > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Rickard Falk > > > Sent: Monday, August 27, 2001 9:53 AM > > > To: w3c-dist-auth@w3.org > > > Subject: Getcontentlength & GetContentType > > > > > > > > > What should I respond if a client asks for the properties > > > Getcontentlength or GetContentType on a collection? > > > The spec states: > > > "The getcontentlength property MUST be defined on any > > > DAV compliant resource that returns the Content-Length header in > > > response to a GET." > > > > > > But it doesn't say, if the value a supposed to be the same as if > > > I perform a 'Get' on that url. The collection itself doesn't > > > normally have a content, so does this mean that if the collection > > > have a default page. That it should return the values of that > > > page? Or if the server is set to send a generated HTML page > > > listing the children, should the values be text/html and the size > > > of that page? > > > > > > Or have I missed something in the spec? > > > > > > /Rickard Falk > > From w3c-dist-auth-request@w3.org Mon Aug 27 14:44:46 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26972 for ; Mon, 27 Aug 2001 14:44:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA00140; Mon, 27 Aug 2001 14:43:40 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 14:43:40 -0400 (EDT) Resent-Message-Id: <200108271843.OAA00140@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA00116 for ; Mon, 27 Aug 2001 14:43:35 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA13123 for ; Mon, 27 Aug 2001 14:43:34 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA19940 for ; Mon, 27 Aug 2001 11:43:37 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 27 Aug 2001 11:40:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B89413D.18696CBD@cs.bris.ac.uk> Importance: Normal Subject: RE: Inheritance on properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5325 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bite Shadgar writes: > I am wondering if anybody let me know, has the inheritance been > considered on properties of resources in Webdav? I don't think we ever considered this idea. The access control specification has inheritance of access control lists, which are represented as properties, but this capability is limited just to access control lists. > Consider you have a lots of resource with the same properties. If you > have inheritance, you can > easily store one copy of properties and it can be inherited to other > resources with the same properties. Some issues here: * Is the inheritance down a collection hierarchy (from a collection to its members), or up a hierarchy (from a member to its parents), or does there need to be a mechanism for specifying the inheritance pattern? * Which takes precedence, the inheritance operation, or a lock? That is, if A inherits properties from B, and A is locked, what is the effect of a PROPPATCH on B? Does it succeed, or does it fail, due to the lock on A? > Indeed, what is preparationed in Webdav if a resource has a property > with more than one value. I know it is considered in RDF, however I > think it may be necessary to be a part of Webdav. So that all Webdav > projects support it intrinsically. What do you think? We left this up to the definition for each individual property. There are many ways to represent this. For example: ... ... ... or ... ... ... or

  • ...
  • ...
    • ... - Jim From w3c-dist-auth-request@w3.org Mon Aug 27 14:53:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27097 for ; Mon, 27 Aug 2001 14:53:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA00711; Mon, 27 Aug 2001 14:53:43 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 14:53:43 -0400 (EDT) Resent-Message-Id: <200108271853.OAA00711@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA00604 for ; Mon, 27 Aug 2001 14:53:10 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA13960 for ; Mon, 27 Aug 2001 14:53:09 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA22257; Mon, 27 Aug 2001 11:53:04 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" , , , Date: Mon, 27 Aug 2001 11:49:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: RE: How can an HTTP 1.1 client force a challenge Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5326 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit We have run across this issue with clients wanting to get a challenge before sending the body of a large PUT request. > ISSUE: How can a client force an HTTP server to issue a challenge > before the > client sends a POST body containing a lot of data? > SOLUTION: > 1. The client sends an HTTP request header containing the > "Expect:100-continue" header field, but waits before transmitting the > request body. IMO, this is the preferred solution. The only drawback I can see is that some of the fielded IPP servers might not support the Expect header. Thus, you might want to have some kind of discovery mechanism available for clients to determine if a printer supports Expect. > 2. The Printer (i.e. server) examines the HTTP header and decides > whether or not to accept the HTTP request. I think that this approach would depend too much on the semantics of client stacks. Does a client stack check for responses as it is sending out a large request body? This may not be under the control of a user-space client (i.e., if the client hands a pointer to the kernel and says "ship these bytes" then I believe the ability to detect an early reply depends on the implementation of the tcp stack in the kernel). > 3a. If the Printer accepts the HTTP request, it sends a > 100(Continue) > response and continues to read from the input stream. Go to 4a. Assuming the client can handle a 100 response -- you would need to check the installed base of IPP clients to see if this would work. > 3b If the Printer requires authentication, it rejects the request > with 401 (Unauthorized) status and a "WWW-Authenticate" header field > containing at least one challenge. Go to 4b. > 4a. If the client receives a 100 (Continue) response, it now has a > reasonable expectation that the HTTP request will succeed. The client now > transmits the request body which contains the IPP printing > instructions and > print data. Go to 5. > 4b. If the client receives a challenge, it sends a new HTTP request > header containing an "Authorization" header field and an "Expect: > 100-continue" header field. Go to 3a. > 5. After the Printer receives and processes the HTTP > request body, it > sends a final HTTP status code in response. - Jim From w3c-dist-auth-request@w3.org Mon Aug 27 15:11:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27575 for ; Mon, 27 Aug 2001 15:11:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA02885; Mon, 27 Aug 2001 15:11:23 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 15:11:23 -0400 (EDT) Resent-Message-Id: <200108271911.PAA02885@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA02865 for ; Mon, 27 Aug 2001 15:11:14 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA16166 for ; Mon, 27 Aug 2001 15:11:14 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA26079 for ; Mon, 27 Aug 2001 12:11:17 -0700 (PDT) From: "Jim Whitehead" To: "Webdav WG" Date: Mon, 27 Aug 2001 12:08:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010826180216.G3499@lyra.org> Importance: Normal Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5327 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jason Crawford writes: > Just so it doesn't get overlooked.... do we agree with what > Geoff has said below? No. Geoff Clemm writes: > Well, that's a really easy change, i.e. all you have to do is > absolutely nothing (:-). Currently, section 11 in 2518 places > no constraints on who can do an UNLOCK operation (i.e. if you > can discover the lock token, you can request an UNLOCK). The ACL spec > introduces ways to constrain who can do an operation. So we're > done (:-). This interpretation is very much counter to the intent of RFC 2518. Section 7.1 states, "A write lock MUST prevent a principal without the lock from successfully executing a ... UNLOCK ... on the locked resource." Now, you could certainly argue that "having a lock" implies merely "having the lock token", but this is counter to the definition of a lock token as an identifier of a lock (not the lock itself), and the last paragraph of 6.3: "Having a lock token provides no special access rights. Anyone can find out anyone else's lock token be performing lock discovery. Locks MUST be enforced based on whatever authentication mechanism is used by the server, not based on the secrecy of the token values." The intent of the first sentence of the last paragraph of 7.6 is that it is the COMBINATION of the LOCK TOKEN *AND* valid AUTHENTICATION CREDENTIALS that grants access to a locked resource. ("In order to prevent these collisions a lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with or the method MUST fail.") Since 7.1 clearly lists UNLOCK as a method affected by LOCK, then UNLOCK is affected by this requirement in 7.6. > > It sounds like we might have consensus opinion that the power to unlock > > someone else's locked resource should be under ACL control. > > Could someone that feels strongly about this propose a wording and placement > > in 2518 that makes this proposal concrete? Now, we may want to *change* the semantics of RFC 2518 to allow people other than the lock holder to perform an unlock, as controlled by an access control entry. However, in my mind this is clearly a change, and not an interpretation. As well, it seems to me that what people really want is a "SIEZE" or "TAKE" operation, where the resource remains locked, but ownership of the lock is transferred (with a new lock token generated). If you grab a lock using UNLOCK, it's possible that someone else could sneak in during the epsilon of time the resource is unlocked. - Jim From w3c-dist-auth-request@w3.org Mon Aug 27 15:24:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27882 for ; Mon, 27 Aug 2001 15:24:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA04798; Mon, 27 Aug 2001 15:24:14 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 15:24:14 -0400 (EDT) Resent-Message-Id: <200108271924.PAA04798@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA04774 for ; Mon, 27 Aug 2001 15:23:58 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA17754 for ; Mon, 27 Aug 2001 15:23:58 -0400 Received: (qmail 29570 invoked by uid 0); 27 Aug 2001 19:23:47 -0000 Received: from p3ee2467b.dip.t-dialin.net (HELO lisa) (62.226.70.123) by mail.gmx.net (mp010-rz3) with SMTP; 27 Aug 2001 19:23:47 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "WebDAV" Date: Mon, 27 Aug 2001 21:23:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Subject: RE: Inheritance on properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5328 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > ... > > We left this up to the definition for each individual property. There are > many ways to represent this. > > For example: > > > ... > ... > ... > > > or > > > ... > ... > ... > > > or > > > >
  • ...
    • >
  • ...
    • > ... >     >     This could be implemented using typed properties: Although my proposal (see ) currently doesn't give an example for this case, this could for instance be implemented using SOAP's array encoding scheme (indeed our server implements this). From w3c-dist-auth-request@w3.org Mon Aug 27 15:27:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27949 for ; Mon, 27 Aug 2001 15:27:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA05275; Mon, 27 Aug 2001 15:27:37 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 15:27:37 -0400 (EDT) Resent-Message-Id: <200108271927.PAA05275@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA05184 for ; Mon, 27 Aug 2001 15:27:28 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA18405 for ; Mon, 27 Aug 2001 15:27:28 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA29876 for ; Mon, 27 Aug 2001 12:27:32 -0700 (PDT) From: "Jim Whitehead" To: Date: Mon, 27 Aug 2001 12:24:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: RE: Getcontentlength & GetContentType Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5329 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > What should I respond if a client asks for the properties > Getcontentlength or GetContentType on a collection? For DAV:getcontentlength, RFC 2518 states, in section 13.4, that it contains "the Content-Length header returned by a GET without accept headers." > But it doesn't say, if the value a supposed to be the same as if > I perform a 'Get' on that url. I'm finding it difficult to see how you came to this interpretation. > The collection itself doesn't > normally have a content, so does this mean that if the collection > have a default page. That it should return the values of that > page? Yes, that was the intent for collections. If you can retrieve the contents of resource R via a GET on URLs collection/ and collection/index.html, then this implied to me that resource R had two URL mappings. In particular, it meant that a GET on collection/ was non-zero, and should result in a value for DAV:getcontentlength and DAV:getcontenttype. > Or if the server is set to send a generated HTML page > listing the children, should the values be text/html and the size > of that page? That was also the intent. Now, given the performance implications of this, I can easily see why a server might not want to compute a value here. Seems like it would be handy to have a value a server could use to indicate that the content length is variable, and dynamic, like and thus allow a server to avoid computing the contents of dynamic resources. > Or have I missed something in the spec? Doesn't look like it. - Jim From w3c-dist-auth-request@w3.org Mon Aug 27 15:28:19 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27963 for ; Mon, 27 Aug 2001 15:28:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA05357; Mon, 27 Aug 2001 15:28:01 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 15:28:01 -0400 (EDT) Resent-Message-Id: <200108271928.PAA05357@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA05337 for ; Mon, 27 Aug 2001 15:27:56 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA18592 for ; Mon, 27 Aug 2001 15:27:57 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA29979 for ; Mon, 27 Aug 2001 12:28:00 -0700 (PDT) From: "Jim Whitehead" To: Date: Mon, 27 Aug 2001 12:24:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: RE: Getcontentlength & GetContentType Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5330 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Julian Reschke writes: > WebDAV should still say what it means if a property "must be defined", but > doesn't have a value... Agreed, I'll add this to the issues list. Makes sense to me for a server to just give the property an empty value for these cases. - Jim From w3c-dist-auth-request@w3.org Mon Aug 27 15:39:42 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28142 for ; Mon, 27 Aug 2001 15:39:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA07489; Mon, 27 Aug 2001 15:39:45 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 15:39:45 -0400 (EDT) Resent-Message-Id: <200108271939.PAA07489@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA07415 for ; Mon, 27 Aug 2001 15:39:26 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA19925 for ; Mon, 27 Aug 2001 15:39:25 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id PAA17930; Mon, 27 Aug 2001 15:38:51 -0400 Received: from 242.dhcp3.liv.opentext.com(172.17.3.242) by krusty.wl.opentext.com via smap (V2.1) id xma017903; Mon, 27 Aug 01 15:38:45 -0400 From: "Dylan Barrell" To: "Jim Whitehead" , "WebDAV" Date: Mon, 27 Aug 2001 15:38:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: Inheritance on properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5331 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit There is nothing in webDAV that precludes a server from implementing this inheritance under the covers. That having been said, I would like to see the spec extended to support schema discovery resources and would not be opposed to an optional portion of the spec dealing with inheritance. The biggest problem with the current spec and its usage in the real world is that properties are essentially useless other than as a way for a particular client implementation to store attributes that another instance of the same client would then be able to re-use. There is no way for the server to tell the client what properties it requires and the type of those properties (for example it should be possible for a collection to enforce a mandatory expiry date to be provided for each new document added to that collection) the client should be able to identify that the collection requires this property, that it is a date property so that an appropriate interface can be presented to the user for capture of the date. This means that if you have multiple interfaces to the same repository (webDAV, web, proprietary client, wireless), there is no meaningful way for them to interoperate on properties with standard webDAV clients. --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Monday, August 27, 2001 2:40 PM > To: WebDAV > Subject: RE: Inheritance on properties > > > Bite Shadgar writes: > > I am wondering if anybody let me know, has the inheritance been > > considered on properties of resources in Webdav? > > I don't think we ever considered this idea. The access control > specification has inheritance of access control lists, which are > represented > as properties, but this capability is limited just to access > control lists. > > > Consider you have a lots of resource with the same properties. If you > > have inheritance, you can > > easily store one copy of properties and it can be inherited to other > > resources with the same properties. > > Some issues here: > > * Is the inheritance down a collection hierarchy (from a collection to its > members), or up a hierarchy (from a member to its parents), or does there > need to be a mechanism for specifying the inheritance pattern? > > * Which takes precedence, the inheritance operation, or a lock? > That is, if > A inherits properties from B, and A is locked, what is the effect of a > PROPPATCH on B? Does it succeed, or does it fail, due to the lock on A? > > > Indeed, what is preparationed in Webdav if a resource has a property > > with more than one value. I know it is considered in RDF, however I > > think it may be necessary to be a part of Webdav. So that all Webdav > > projects support it intrinsically. What do you think? > > We left this up to the definition for each individual property. There are > many ways to represent this. > > For example: > > > ... > ... > ... > > > or > > > ... > ... > ... > > > or > > > >
  • ...
    • >
  • ...
    • > ... >     >     > > - Jim From w3c-dist-auth-request@w3.org Mon Aug 27 15:42:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28201 for ; Mon, 27 Aug 2001 15:42:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA07895; Mon, 27 Aug 2001 15:41:55 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 15:41:55 -0400 (EDT) Resent-Message-Id: <200108271941.PAA07895@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA07848 for ; Mon, 27 Aug 2001 15:41:30 -0400 (EDT) Received: from inet-mail3.oraclecorp.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA20418 for ; Mon, 27 Aug 2001 15:41:29 -0400 Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail3.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7RJaIe14162 for ; Mon, 27 Aug 2001 12:36:18 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f7RJewD26098 for ; Mon, 27 Aug 2001 13:40:58 -0600 (MDT) From: "Eric Sedlar" To: Date: Mon, 27 Aug 2001 12:46:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Subject: RE: Getcontentlength & GetContentType Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5332 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit would be useful as a return value for any resource that has contents generated dynamically, like a servlet. This would be a REALLY great addition, IMHO. --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Monday, August 27, 2001 12:24 PM > To: w3c-dist-auth@w3.org > Subject: RE: Getcontentlength & GetContentType > > > > What should I respond if a client asks for the properties > > Getcontentlength or GetContentType on a collection? > > For DAV:getcontentlength, RFC 2518 states, in section 13.4, that > it contains > "the Content-Length header returned by a GET without accept headers." > > > But it doesn't say, if the value a supposed to be the same as if > > I perform a 'Get' on that url. > > I'm finding it difficult to see how you came to this interpretation. > > > The collection itself doesn't > > normally have a content, so does this mean that if the collection > > have a default page. That it should return the values of that > > page? > > Yes, that was the intent for collections. > > If you can retrieve the contents of resource R via a GET on URLs > collection/ > and collection/index.html, then this implied to me that resource R had two > URL mappings. In particular, it meant that a GET on collection/ was > non-zero, and should result in a value for DAV:getcontentlength and > DAV:getcontenttype. > > > Or if the server is set to send a generated HTML page > > listing the children, should the values be text/html and the size > > of that page? > > That was also the intent. Now, given the performance implications > of this, I > can easily see why a server might not want to compute a value here. Seems > like it would be handy to have a value a server could use to indicate that > the content length is variable, and dynamic, like and thus > allow a server to avoid computing the contents of dynamic resources. > > > Or have I missed something in the spec? > > Doesn't look like it. > > - Jim > > From w3c-dist-auth-request@w3.org Mon Aug 27 15:54:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28455 for ; Mon, 27 Aug 2001 15:54:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA08773; Mon, 27 Aug 2001 15:51:30 -0400 (EDT) Resent-Date: Mon, 27 Aug 2001 15:51:30 -0400 (EDT) Resent-Message-Id: <200108271951.PAA08773@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA08683 for ; Mon, 27 Aug 2001 15:51:14 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA21622 for ; Mon, 27 Aug 2001 15:51:13 -0400 Received: (qmail 31115 invoked by uid 0); 27 Aug 2001 19:50:42 -0000 Received: from p3ee2467b.dip.t-dialin.net (HELO lisa) (62.226.70.123) by mail.gmx.net (mp020-rz3) with SMTP; 27 Aug 2001 19:50:42 -0000 From: "Julian Reschke" To: "Jim Whitehead" , Date: Mon, 27 Aug 2001 21:50:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Subject: RE: Getcontentlength & GetContentType Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5333 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Monday, August 27, 2001 9:25 PM > To: w3c-dist-auth@w3.org > Subject: RE: Getcontentlength & GetContentType > > > Julian Reschke writes: > > WebDAV should still say what it means if a property "must be > defined", but > > doesn't have a value... > > Agreed, I'll add this to the issues list. > > Makes sense to me for a server to just give the property an empty > value for > these cases. At least in the case where the server in fact does not support GET on properties. From w3c-dist-auth-request@w3.org Fri Aug 31 01:58:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15352 for ; Fri, 31 Aug 2001 01:58:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA08841; Fri, 31 Aug 2001 01:58:17 -0400 (EDT) Resent-Date: Fri, 31 Aug 2001 01:58:17 -0400 (EDT) Resent-Message-Id: <200108310558.BAA08841@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA08613 for ; Fri, 31 Aug 2001 01:57:52 -0400 (EDT) Received: from mailrelayerformercurymailsites.more.net (mailrelayerformercurymailsites.more.net [198.209.253.70]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA18236; Fri, 31 Aug 2001 01:57:48 -0400 From: b54yhn567@msn.com Received: from mail.wrtcty.k12.mo.us (mail.wrtcty.k12.mo.us [209.106.64.253]) by mailrelayerformercurymailsites.more.net (8.11.6/8.11.4) with ESMTP id f7V5vdH24411; Fri, 31 Aug 2001 00:57:39 -0500 (CDT) Received: from WRTCTY/SpoolDir by mail.wrtcty.k12.mo.us (Mercury 1.44); 31 Aug 80 00:56:12 -600 Received: from SpoolDir by WRTCTY (Mercury 1.44); 30 Aug 01 03:40:43 -600 Received: from 199.232.255.209 (209.106.65.253) by mail.wrtcty.k12.mo.us (Mercury 1.44); 30 Aug 01 03:40:40 -600 Message-ID: <00007c0467c7$000060c3$0000325c@199.232.255.209> To: Date: Thu, 30 Aug 2001 05:56:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Subject: Join the fight to quality. Make 36 Annually secured Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5334 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Make 35% in 9 months Fully Secured Is the stock market rollor coaster making you worried? Join The Flight to Quality. Make 36% ANNUALLY FULLY SECURED FULLY SECURED For a free investment video PLEASE FOLLOW THE LINK BELOW www.freewebhostingcentral.cc/ch3/36percent/ To be removed from all further mailings, please send a message to: mailto:dfhthth22111@yahoo.com