From w3c-dist-auth-request@w3.org Wed Dec 1 03:02:20 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25249 for ; Wed, 1 Dec 1999 03:02:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA16812; Wed, 1 Dec 1999 02:51:17 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 02:51:17 -0500 (EST) Resent-Message-Id: <199912010751.CAA16812@www19.w3.org> Message-Id: <4.1.19991130225258.00abc630@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 Nov 1999 22:54:31 +0100 To: "'WebDAV'" From: Jim Davis In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3695 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 05:30 PM 11/30/99 +0000, Mark Birbeck wrote: >[good reasons that propfind should not return the ordering propery unless explicitly asked] I agree with Mark. Drop the "should" from the spec. From w3c-dist-auth-request@w3.org Wed Dec 1 03:02:23 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25288 for ; Wed, 1 Dec 1999 03:02:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA16868; Wed, 1 Dec 1999 02:51:30 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 02:51:30 -0500 (EST) Resent-Message-Id: <199912010751.CAA16868@www19.w3.org> Message-Id: <4.1.19991130230349.00ac3120@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 Nov 1999 23:22:15 +0100 To: w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: References: < <8E3CFBC709A8D21191A400805F15E0DBD24504@crte147.wc.eso.mc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3697 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 10:15 AM 11/30/99 -0800, Kevin Wiggen wrote: Thought 1 was fine. >THOUGHT 2: >If >the client asks for a specific order via the clause, does the >server always append on the order of the collection as the last ordering. Nice thought but I am afraid I do not agree. I think the DASL arbiter should not append anything to the query. First, it is costly. Most search engines are going to ignore DAV collection ordering, it wont be part of the underlying indexing information. The entries in the indexing are most likely going to be a flat set of rows (for an RDB) of all the entities that are indexed, they won't be grouped by collection. Second, it is meaningless. If there was an underlying order to the collection, that order has gotten scrambled by the ordering in the query , so we gain nothing by restoring only part of it. I mean, if the collection was sorted by date, but the dasl query was a sort by alphabetic name (only), then what good does it do to sort by date within name? If the client wanted that secondary sort, it would have asked for it, or done it itself. Third, orderby is part of DASL's basicsearch but might not be part of other DASL query grammars. fourth, I don't want ordered collections to depend on DASL or vice versa if it can be helped. >I believe an even better answer to this situation is to add >clause to the propfind. In this way we generalized the problem, and turn it >into a better solution. Are you proposing that a PROPFIND request by able to provide an arbitrary (re) ordering, just as in DASL? While I admit that I do see the charm, I am afraid that I would strongly disagree. I would object to it in RFC 2518, and I would object to it for the Ordered Collection extension. Your proposal would require a server to potentially have to perform a sorts for each PROPFIND request, a significant burden. We have heard consistently that people do not want Ordered Collections to be expensive. Your proposal would make not only Ordered Collections but even plain old RFC 2518 expensive. Also the ordering in Ordered Collections is explicitly intended for client -provided orderings, where the burden and the cost of such ordering is paid by the client, not the server. Not all WebDAV servers will support DASL, and they should not have to pay the price of supporting sorting. From w3c-dist-auth-request@w3.org Wed Dec 1 03:02:49 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25527 for ; Wed, 1 Dec 1999 03:02:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA17038; Wed, 1 Dec 1999 02:51:58 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 02:51:58 -0500 (EST) Resent-Message-Id: <199912010751.CAA17038@www19.w3.org> Message-Id: <4.1.19991130225635.00ab0460@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 Nov 1999 22:59:16 +0100 To: From: Jim Davis In-Reply-To: <000101bf3b09$47e3f750$d6f00218@c786448-a.cdrrpd1.ia.home.c om> References: <4.1.19991130013916.00ac3740@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3696 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 12:02 AM 11/30/99 -0800, David M. Chandler wrote: > >... As far as the >"bad" behavior which might result when newly-added children inherit depth-0 >locks, I propose the following scenario. Your scenario is exactly right, that is, it makes all the right predictions. So the claim is that it would be confusing if WebDAV acted this way... you'd have a tree of resources, only some of which were locked, and whose lockedness depended on the history. In fact I agree, it seems confusing to me too. It's a good argument for changing the spec. From w3c-dist-auth-request@w3.org Wed Dec 1 03:03:32 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25925 for ; Wed, 1 Dec 1999 03:03:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA17197; Wed, 1 Dec 1999 02:52:20 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 02:52:20 -0500 (EST) Resent-Message-Id: <199912010752.CAA17197@www19.w3.org> Message-Id: <4.1.19991130232227.00ab4260@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 Nov 1999 23:33:39 +0100 To: From: Jim Davis In-Reply-To: <011301bf3b60$793b93b0$9ef6a8c0@lex.rational.com> References: <4.1.19991125192837.00b04650@pop.xs4all.nl> <4.1.19991130013916.00ac3740@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3698 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 01:26 PM 11/30/99 -0500, Geoffrey Clemm wrote: >From: Jim Davis >See >In particular, this message says: > >I lock a collection, because I'm going to be adding members >to that collection. If a depth:0 lock applies to all the >immediate members of a collection as well, then I have prevented >anyone from updating the state of one of the existing internal members of >that collection. Thanks for tracking down the quotation (I can't search the email archive right now) but that message responds to a strawman. I never said "a depth:0 lock applies to all the immediate members of a collection". (indeed, that's what a depth infinity lock does). I was asking about a depth 0 lock being inherited by *newly created* members of the collection. So let me ask again. If I lock collection a/ with depth 0, then do a PUT to a/b.html (which did not prev exist), and a/b.html is added to the lock, what bad thing then happens, or what good thing is prevented? Does something bad happen if the PUT is instead a MKCOL, or COPY/MOVE, or a LOCK? Note that I have seen David Chandler's reply. Do you have anything to add other than his example? Also, if you have any comments on the very end of my last email (where I asked whether the problem was the definition of "added to the lock") that might help. best wishes Jim From w3c-dist-auth-request@w3.org Wed Dec 1 10:50:05 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06094 for ; Wed, 1 Dec 1999 10:50:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA02172; Wed, 1 Dec 1999 10:34:40 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 10:34:40 -0500 (EST) Resent-Message-Id: <199912011534.KAA02172@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525683A.00509667.00@d54mta03.raleigh.ibm.com> Date: Wed, 1 Dec 1999 09:37:17 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Access Control and JAAS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3700 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list http://developer.java.sun.com/developer/earlyAccess/jaas/ might be a good source of input for WebDAV ACLs. It would be great if there was some interoperability between them. From w3c-dist-auth-request@w3.org Wed Dec 1 10:51:11 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06710 for ; Wed, 1 Dec 1999 10:51:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA01916; Wed, 1 Dec 1999 10:31:55 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 10:31:55 -0500 (EST) Resent-Message-Id: <199912011531.KAA01916@www19.w3.org> Message-ID: <018901bf3c11$61c6eac0$9ef6a8c0@lex.rational.com> From: "Geoffrey Clemm" To: References: <8525683A.0004549D.00@D51MTA03.pok.ibm.com> Date: Wed, 1 Dec 1999 10:33:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3699 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I am also in the "only return what the client requests" camp as well. All of the arguments in favor of returning some particular bit of information take the form "this is really important information, and it's not that long". The essential flaw in this argument is that *every* piece of data is important to some client, or we wouldn't have spent the effort on standardizing on it. There have been several proposals to provide "named batches" of information, so that a client can say things like: "I'm interested in all the DAV:display information". That would be fine with me. Cheers, Geoff ----- Original Message ----- From: To: 'WebDAV' Sent: Tuesday, November 30, 1999 7:46 PM Subject: Re: Ordered Collections and PROPFIND Responses > > Until someone points out why this isn't good, I'm in the camp that says the > server should only return the properties that the client requested. > > > > From w3c-dist-auth-request@w3.org Wed Dec 1 11:06:37 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14161 for ; Wed, 1 Dec 1999 11:06:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA03512; Wed, 1 Dec 1999 10:54:25 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 10:54:25 -0500 (EST) Resent-Message-Id: <199912011554.KAA03512@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525683A.00571C66.00@d54mta03.raleigh.ibm.com> Date: Wed, 1 Dec 1999 10:47:56 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3701 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I agree with Geoff. "Geoffrey Clemm" on 12/01/99 10:33:12 AM To: w3c-dist-auth@w3.org cc: Subject: Re: Ordered Collections and PROPFIND Responses I am also in the "only return what the client requests" camp as well. All of the arguments in favor of returning some particular bit of information take the form "this is really important information, and it's not that long". The essential flaw in this argument is that *every* piece of data is important to some client, or we wouldn't have spent the effort on standardizing on it. There have been several proposals to provide "named batches" of information, so that a client can say things like: "I'm interested in all the DAV:display information". That would be fine with me. Cheers, Geoff ----- Original Message ----- From: To: 'WebDAV' Sent: Tuesday, November 30, 1999 7:46 PM Subject: Re: Ordered Collections and PROPFIND Responses > > Until someone points out why this isn't good, I'm in the camp that says the > server should only return the properties that the client requested. > > > > From w3c-dist-auth-request@w3.org Wed Dec 1 13:42:38 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03160 for ; Wed, 1 Dec 1999 13:42:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11682; Wed, 1 Dec 1999 13:28:03 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 13:28:03 -0500 (EST) Resent-Message-Id: <199912011828.NAA11682@www19.w3.org> From: Jim Whitehead To: Lars-Gunnar.F.Fallman@telia.se, WebDAV WG MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Wed, 1 Dec 1999 10:25:53 -0800 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: Office 2000 and properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3702 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I do not believe this is possible -- Office 2000 properties appear to be exclusively embedded within the document. An intelligent server that has knowledge of the Office data formats might be able to extract the properties and expose them via DAV, but I know of no server (including MS's) that does this. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of > Lars-Gunnar.F.Fallman@telia.se > Sent: Friday, November 26, 1999 11:35 AM > To: w3c-dist-auth@w3.org > Subject: Office 2000 and properties > > > Does anyone know if it's possible to configure the Ms office 2000 > applications and ms webfolders to use webdav properties instead of just > embed them in the document ? > > /Lars-Gunnar > From w3c-dist-auth-request@w3.org Wed Dec 1 14:51:04 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06922 for ; Wed, 1 Dec 1999 14:51:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15030; Wed, 1 Dec 1999 14:39:48 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 14:39:48 -0500 (EST) Resent-Message-Id: <199912011939.OAA15030@www19.w3.org> From: atul.mathur@autodesk.com Message-ID: <19879C753611D3119DAB0008C7A4C0C102BBE847@hqmsgsrf04.autodesk.com> To: ejw@ics.uci.edu, Lars-Gunnar.F.Fallman@telia.se, w3c-dist-auth@w3.org Date: Wed, 1 Dec 1999 11:05:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Office 2000 and properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3703 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I suppose Office 2000 uses OLE Persistent Property Sets for storing the properties within the document. Jim Whitehead wrote: >> An intelligent server that has knowledge of the Office data formats >> might be able to extract the properties and expose them via DAV, Such a server would be interesting for documents created using many other Windows based applications as well. OLE defines a standard seialized data format for property sets called "Structured Storage Serialized Property Set Format". A Windows NT based server could use StgOpenStorageEx and get the IPropertySetStorage/IPropertyStorage interfaces to access the properties. Any other server could directly access the properties using the published format. Atul From w3c-dist-auth-request@w3.org Wed Dec 1 17:01:17 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10484 for ; Wed, 1 Dec 1999 17:01:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA25145; Wed, 1 Dec 1999 16:50:22 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 16:50:22 -0500 (EST) Resent-Message-Id: <199912012150.QAA25145@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 1 Dec 1999 13:48:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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) In-Reply-To: <97FD7417E8C9D111AB4100805FADB6A203DDE2C5@pariah.cncx.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Unsubscribing from the WG list Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3704 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Michael Hamilton writes: > How do I unsubscribe? In case you've lost the initial mail sent when you subscribed to this list, the way to unsubscribe to the WG list is to send an email with a subject line of "unsubscribe" to w3c-dist-auth-request@w3.org. You'll then automatically be removed from the mailing list. - Jim From w3c-dist-auth-request@w3.org Wed Dec 1 17:01:34 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10637 for ; Wed, 1 Dec 1999 17:01:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA25183; Wed, 1 Dec 1999 16:50:38 -0500 (EST) Resent-Date: Wed, 1 Dec 1999 16:50:38 -0500 (EST) Resent-Message-Id: <199912012150.QAA25183@www19.w3.org> From: Jim Whitehead To: Jim Davis , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Wed, 1 Dec 1999 13:48:23 -0800 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) In-Reply-To: <4.1.19991130013916.00ac3740@pop.xs4all.nl> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3705 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Jim Davis writes: > Look, I quote 7.5 > > If a lock owner causes the URI of a resource to be added as an > internal member URI of a locked collection then the new resource MUST > be automatically added to the lock. This is the only mechanism that > allows a resource to be added to a write lock. Thus, for example, if > the collection /a/b/ is write locked and the resource /c is moved to > /a/b/c then resource /a/b/c will be added to the write lock. > > It does not say "locked depth infinity" it just says "locked". > > If the authors had meant to restrict this to apply only to infinite-depth > locked collection, they would have said so, no? > > Or perhaps the difficulty lies in the term "added to the lock"? I think > this may be the source of the confusion. > > This really isn't pedantry, honest. I am not doing this just for the > pleasure of arguing. I am doing this because i want a spec that's clear, > so that any implementor can read it and know what to expect. Sorry I didn't read this thread sooner... The original intent was to have the inheritance behavior only apply to Depth infinity locked collections, not to Depth 0 locked collections. Since section 7.5 does not explicitly state a "depth infinity locked collection", but only states a "lcoked collection", the section is ambiguous, and should be clarified in a future revision of RFC 2518. I've added this to the issues list, available at: http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 08:56:27 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21459 for ; Thu, 2 Dec 1999 08:56:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA15530; Thu, 2 Dec 1999 08:41:14 -0500 (EST) Resent-Date: Thu, 2 Dec 1999 08:41:14 -0500 (EST) Resent-Message-Id: <199912021341.IAA15530@www19.w3.org> Message-Id: <4.1.19991202142656.039d53a0@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 02 Dec 1999 14:38:31 +0100 To: w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: References: <4.1.19991130013916.00ac3740@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3706 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 01:48 PM 12/1/99 -0800, Jim Whitehead wrote: > >The original intent was to have the inheritance behavior only apply to Depth >infinity locked collections, not to Depth 0 locked collections. Since >section 7.5 does not explicitly state a "depth infinity locked collection", >but only states a "lcoked collection", the section is ambiguous, and should >be clarified in a future revision of RFC 2518. I've added this to the >issues list, available at: Okay, that resolves that. I've modified tdav.py to reflect the intended behavior, and now I can confirm that the server at Sharemation is (so far as I can tell) in full compliance with RFC 2518. From w3c-dist-auth-request@w3.org Thu Dec 2 12:11:02 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01584 for ; Thu, 2 Dec 1999 12:11:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA22409; Thu, 2 Dec 1999 11:55:54 -0500 (EST) Resent-Date: Thu, 2 Dec 1999 11:55:54 -0500 (EST) Resent-Message-Id: <199912021655.LAA22409@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Thu, 2 Dec 1999 08:53:51 -0800 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) In-Reply-To: <000501bf3638$a21755d0$d6f00218@c786448-a.cdrrpd1.ia.home.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: Integrated XML browser/editor and WebDAV BOF at XML '99 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3707 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit David Chandler writes: > If anyone is planning to attend in Philadelphia and would like to get > together informally to discuss current WebDAV-related initiatives, please > send me e-mail and I'll help coordinate a time and place. > > David M. Chandler > Web Applications Developer > National Computer Systems > 5chandlers@home.com And Greg Stein writes: > I think you missed one of the talks at XML '99 :-) ... > > WebDAV: Web-Based Distributed Authoring and Versioning I just wanted to say that I think a BOF is a great idea. Even though I won't be attending XML'99, if I were there, I'd certainly want to get together with Greg, David, and other DAV folk. I'd also definitely attend Greg's talk. :-) - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 12:27:18 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10358 for ; Thu, 2 Dec 1999 12:27:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA23790; Thu, 2 Dec 1999 12:14:56 -0500 (EST) Resent-Date: Thu, 2 Dec 1999 12:14:56 -0500 (EST) Resent-Message-Id: <199912021714.MAA23790@www19.w3.org> From: Jim Whitehead To: Juergen Reuter Cc: WebDAV WG , jjh@ira.uka.de MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Thu, 2 Dec 1999 09:12:20 -0800 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) In-Reply-To: <"iraun1.ira.780:24.11.99.15.28.59"@ira.uka.de> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: Syntax Issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3708 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Sorry for the slow response -- your email came in at the start of my Thanksgiving holiday... > As far as I understand, WebDAV's DTD itself is fixed; but the examples > in chapter 8 use a namespace identified by the external entity > reference URI "http://www.foo.bar/boxschema", which, effectively, > extends the syntax. This is correct -- we're viewing this as a feature. We wanted property names and values to be created by anyone without having to go through a central property registry. We felt it was unlikely that all clients and servers would understand all properties, and hence we demand just the lowest level of interoperability, well-formedness. However, Larry Masinter has, in the past, warned of the dangers of this approach, noting that it is possible to create new protocols that are conveyed only in properties, and these protocols would not be interoperable, despite the fact all applications would be WebDAV compliant. So far this risk has not materialized -- perhaps the fact that no current client actually uses PROPPATCH is a contributor :-) > Ok, I understand that there might be reasons for some implementors not > to use validation. On the other hand, I think validating xml could be > implicitly introduced into [WebDAV], thereby allowing each implementor > to decide on his own whether to use validation or not. The current > syntax, however, makes it impossible to use validation, unless an > additional input filter is supplied that patches the input data, or a > validating parser is patched to accept even [WebDAV]'s syntax. Well, given that property values can potentially contain almost any element, and since the DAV vocabulary of XML elements is tightly controlled by RFCs, I'm really not sure what value an application would gain from validation, except to expend CPU cycles. What benefit do you perceive your application would gain from validation? > However, this is not a problem, because in section 2.8 [XML] says: > "The document type declaration can point to an external subset ..., or > contain the markup declarations directly ..., or can do both." This > means client properties do not need to be declared in the DTD, but can > also be declared directly as markup declarations in the submitted > document. OK, this is possible, but again I wonder at its value. In order to make use of a property, the application must typically understand both its syntax and semantics. The DTD information only supplies a limited form of syntactic information, and conveys virtually no semantic information. The only application I can imagine that might make use of DTD information without understanding the contents of the property is a property viewer (an app. that just displays the properties to the user), which, due to XML's document-centric heritage, is no great surprise. But, any other application will either (a) not understand the semantics of the property, and hence will only need to parse the information, a quality provided by well-formedness, or (b) will have in-depth understanding of the syntax and semantics of the property which goes far beyond the information conveyed in a DTD, in which case the DTD provides only a limited, and not particularly useful, form of specification redundancy. - Jim From w3c-dist-auth-request@w3.org Fri Dec 3 08:34:49 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19635 for ; Fri, 3 Dec 1999 08:34:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA28189; Fri, 3 Dec 1999 08:23:51 -0500 (EST) Resent-Date: Fri, 3 Dec 1999 08:23:51 -0500 (EST) Resent-Message-Id: <199912031323.IAA28189@www19.w3.org> Message-Id: <3.0.5.32.19991203082238.02c553b0@127.0.0.1> X-Sender: swick@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 03 Dec 1999 08:22:38 -0500 To: WebDAV WG From: "Ralph R. Swick" In-Reply-To: References: <97FD7417E8C9D111AB4100805FADB6A203DDE2C5@pariah.cncx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Unsubscribing from the WG list Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3709 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 01:48 PM 12/1/1999 -0800, Jim Whitehead wrote: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0295 >the way to unsubscribe to the WG list is to send an email with a subject >line of "unsubscribe" to w3c-dist-auth-request@w3.org. You'll then >automatically be removed from the mailing list. And a reminder to those of you who have mail servers that occasionally go off-line: our list server will automatically remove addresses that bounce more than 4 messages. If the list is very active it may not take long for that to happen. From w3c-dist-auth-request@w3.org Fri Dec 3 17:14:07 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13246 for ; Fri, 3 Dec 1999 17:14:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA14645; Fri, 3 Dec 1999 17:00:46 -0500 (EST) Resent-Date: Fri, 3 Dec 1999 17:00:46 -0500 (EST) Resent-Message-Id: <199912032200.RAA14645@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24518@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Fri, 3 Dec 1999 17:00:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: Server-Maintained Orderings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3710 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At the moment, the Ordered Collections spec contains some minimal support for server-maintained orderings. The design team would like to remove that support. The rationale for removing it is that unless we are willing to define a standard set of server-maintained orderings that servers must support in order to be compliant, we don't really gain any interoperability. And we are not willing to go that far. At the moment, all we are able to do is provide a way for clients to discover what server-maintained orderings are available and choose one. But if the client was not designed to work with the particular server (so that it understands the tokens identifying the orderings), the list of available orderings will be meaningless to the client. So there is no gain in interoperability. Given this state of affairs, the consensus among the design team was that it would be better to do nothing at all in support of server-maintained orderings, leaving anyone who wants to design a well-thought-out extension to the protocol in the future completely free to design server-maintained orderings as they wish. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Sat Dec 4 15:12:39 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20506 for ; Sat, 4 Dec 1999 15:12:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA05828; Sat, 4 Dec 1999 15:01:08 -0500 (EST) Resent-Date: Sat, 4 Dec 1999 15:01:08 -0500 (EST) Resent-Message-Id: <199912042001.PAA05828@www19.w3.org> Message-ID: <384970FC.799732B6@us.oracle.com> Date: Sat, 04 Dec 1999 11:52:28 -0800 From: "Eric Sedlar" Organization: Oracle Corporation X-Mailer: Mozilla 4.51 [en] (WinNT; U) 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: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3711 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit It appears that the authors of the advanced collections spec expect that BINDing a resource into a new collection will adjust a reference count on the destination, ensuring that the destination resource persists until all bindings have been explicitly removed. The problem with this behavior is dealing with cyclic references. A server implementer may allow cyclic BINDings, in which case DELETE becomes very expensive, since the server must now validate that there is still a valid path to the destination resource from the root, to avoid orphaned cycles. Alternately, a server implementer can disallow cyclic bindings from being inserted in the first place, which is computationally much cheaper, but which restricts the usefulness of BINDings. (Like the way UNIX restricts hard links to directories). Has any thought been given to a notion of a "weak" binding, which doesn't affect persistence? As long as weak bindings are automatically deleted when all of the strong bindings are removed, dangling BINDings (the great evil) are avoided. Especially when a DAV server is implementing something like a user space quota, a strong BINDing implies that the user creating it wants to maintain storage for the object (implying a quota impact), whereas a weak binding would be more like a smart bookmark that would follow a web page when moved and disappear if that page were removed. --Eric Sedlar Oracle Corporation esedlar@us.oracle.com From w3c-dist-auth-request@w3.org Sat Dec 4 16:41:36 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27384 for ; Sat, 4 Dec 1999 16:41:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA07111; Sat, 4 Dec 1999 16:30:42 -0500 (EST) Resent-Date: Sat, 4 Dec 1999 16:30:42 -0500 (EST) Resent-Message-Id: <199912042130.QAA07111@www19.w3.org> Message-Id: <4.1.19991204221950.00b28dd0@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 04 Dec 1999 22:21:07 +0100 To: "'WebDAV'" From: Jim Davis In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD24518@crte147.wc.eso.mc.x erox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Server-Maintained Orderings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3712 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Makes total sense. Just be sure you capture the rationale, because it's likely that people will ask for this feature again in the future, so let's be ready to tell them why not. From w3c-dist-auth-request@w3.org Tue Dec 7 11:57:19 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21607 for ; Tue, 7 Dec 1999 11:57:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA15308; Tue, 7 Dec 1999 11:28:22 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 11:28:22 -0500 (EST) Resent-Message-Id: <199912071628.LAA15308@www19.w3.org> Date: Tue, 7 Dec 1999 11:28:11 -0500 Message-Id: <9912071628.AA01275@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <384970FC.799732B6@us.oracle.com> (esedlar@us.oracle.com) Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3713 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: "Eric Sedlar" It appears that the authors of the advanced collections spec expect that BINDing a resource into a new collection will adjust a reference count on the destination, ensuring that the destination resource persists until all bindings have been explicitly removed. As you note below, a mark sweep style algorithm is more appropriate if you want to do garbage collection (the spec does not require a server to do any garbage collection). The problem with this behavior is dealing with cyclic references. A server implementer may allow cyclic BINDings, Actually, that wording has been revised to say that a server _must_ implement cycle bindings. in which case DELETE becomes very expensive, since the server must now validate that there is still a valid path to the destination resource from the root, to avoid orphaned cycles. Note that orphaned cycles are not forbidden by the spec, so there is no requirement to clean up orphaned cycles immediately (e.g. it could be a weekly garbage collection run). Alternately, a server implementer can disallow cyclic bindings from being inserted in the first place, which is computationally much cheaper, but which restricts the usefulness of BINDings. (Like the way UNIX restricts hard links to directories). This is now forbidden by the spec. Has any thought been given to a notion of a "weak" binding, which doesn't affect persistence? As long as weak bindings are automatically deleted when all of the strong bindings are removed, dangling BINDings (the great evil) are avoided. Especially when a DAV server is implementing something like a user space quota, a strong BINDing implies that the user creating it wants to maintain storage for the object (implying a quota impact), whereas a weak binding would be more like a smart bookmark that would follow a web page when moved and disappear if that page were removed. Yes, this was one of the variants discussed, but some of the difficulties encountered are: - does a server have to delete a weak binding when the last strong binding goes away, or can it leave it dangling? - how can a server ensure that it has write access to all weak bindings that might need to be deleted when the last strong binding is deleted? - if a weak binding is left dangling, how is this conveyed to a client? - does the weak binding track the resource as it moves, or does it just point at a specific URL? - what happens if you issue a LOCK against a URL that contained a weak binding? So we decided that the complexity of defining and supporting a weak binding outweighed its benefits. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Dec 7 15:51:04 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16639 for ; Tue, 7 Dec 1999 15:51:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA23013; Tue, 7 Dec 1999 15:39:07 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 15:39:07 -0500 (EST) Resent-Message-Id: <199912072039.PAA23013@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <85256840.0062B45C.00@D51MTA03.pok.ibm.com> Date: Tue, 7 Dec 1999 12:56:55 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3714 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Alternately, a server implementer can disallow cyclic bindings from being inserted in the first place, which is computationally much cheaper, but which restricts the usefulness of BINDings. (Like the way UNIX restricts hard links to directories). This is now forbidden by the spec. Just to clarify. By "this" Geoff was refering to the possibility of the server not supporting cycles. The proposed changes now require servers to allow cycles to be created. Geoff was not suggesting anything regarding hard links to directories. From w3c-dist-auth-request@w3.org Tue Dec 7 16:15:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28432 for ; Tue, 7 Dec 1999 16:15:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA23992; Tue, 7 Dec 1999 16:03:40 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 16:03:40 -0500 (EST) Resent-Message-Id: <199912072103.QAA23992@www19.w3.org> Message-ID: <384D741F.44120E3E@us.oracle.com> Date: Tue, 07 Dec 1999 12:54:55 -0800 From: "Eric Sedlar" Organization: Oracle Corporation X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Geoffrey M. Clemm" CC: w3c-dist-auth@w3.org References: <9912071628.AA01275@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3715 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I've implemented this type of system before, and the costs of mark and sweep are enormous when you are talking about large sets of documents living on disk (like in a relational database). People generally expect unlink/delete on a file to work quickly, and applications depend on that not eating up a tremendous amount of cycles or doing a lot of I/O. Mark and sweep is also much more expensive than forbidding the insertion of cycles. If you wait to do garbage collection asynchronously, searches that do not traverse the hierarchical namespace but that use other indexes (like keyword searches, for example) will find things that the user has deleted. Also, deferring the garbage collection associated with the unlink breaks the transactional guarantee when people COMMIT their work. I can give you a perfectly good set of answers about how to deal with weak links. Oracle built a system that implements weak links and forbids cycles as part of the Internet Filesystem product. My responses to your issues are included below, marked with . --Eric Sedlar "Geoffrey M. Clemm" wrote: > From: "Eric Sedlar" > > It appears that the authors of the advanced collections spec expect that > BINDing a resource into a new collection will adjust a reference count > on the destination, ensuring that the destination resource persists > until all bindings have been explicitly removed. > > As you note below, a mark sweep style algorithm is more appropriate > if you want to do garbage collection (the spec does not require a > server to do any garbage collection). > > The problem with this behavior is dealing with cyclic references. A > server implementer may allow cyclic BINDings, > > Actually, that wording has been revised to say that a server _must_ > implement cycle bindings. > > in which case DELETE > becomes very expensive, since the server must now validate that there is > still a valid path to the destination resource from the root, to avoid > orphaned cycles. > > Note that orphaned cycles are not forbidden by the spec, so there is > no requirement to clean up orphaned cycles immediately (e.g. it could > be a weekly garbage collection run). > > Alternately, a server implementer can disallow cyclic > bindings from being inserted in the first place, which is > computationally much cheaper, but which restricts the usefulness of > BINDings. (Like the way UNIX restricts hard links to directories). > > This is now forbidden by the spec. > > Has any thought been given to a notion of a "weak" binding, which > doesn't affect persistence? As long as weak bindings are automatically > deleted when all of the strong bindings are removed, dangling BINDings > (the great evil) are avoided. Especially when a DAV server is > implementing something like a user space quota, a strong BINDing implies > that the user creating it wants to maintain storage for the object > (implying a quota impact), whereas a weak binding would be more like a > smart bookmark that would follow a web page when moved and disappear if > that page were removed. > > Yes, this was one of the variants discussed, but some of the difficulties > encountered are: > - does a server have to delete a weak binding when the last strong > binding goes away, or can it leave it dangling? delete the weak binding > - how can a server ensure that it has write access to all weak bindings > that might need to be deleted when the last strong binding is deleted? run the weak link cleanup as setuid root /system/whatever > > - if a weak binding is left dangling, how is this conveyed to a client? not an issue> > > - does the weak binding track the resource as it moves, or does it > just point at a specific URL? it tracks the resource as it moves > > - what happens if you issue a LOCK against a URL that contained a > weak binding? locking a URL locks the namespace, not the resource. While you have locked the URL containing a weak binding, nobody else can use that set of names in their respective collections. The resource the locked URL points to may actually be deleted while the URL to it is locked. In this case the resource is deleted when the lock is released. (Think of the lock like an open file descriptor, or in database terms, a snapshot in a read-only transaction that was started when the lock was acquired). This has the same effect as if someone deleted that resource the instant the lock was released. > > > So we decided that the complexity of defining and supporting a weak binding > outweighed its benefits. > > Cheers, > Geoff My experience on this question that the user benefits of allowing strong BINDings to form a cycle are minimal if weak BINDings are allowed, and the performance costs are high. The distinction between two types of bindings is useful when you add user quotas. We call these strong & weak BINDings "saved" and "unsaved" links--a saved link is a statement by the user that s/he is willing to pay storage costs for the item linked to, whereas a weak BINDing is more like a bookmark, useful for categorization and simplifying navigation. From w3c-dist-auth-request@w3.org Tue Dec 7 16:19:38 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00474 for ; Tue, 7 Dec 1999 16:19:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA24231; Tue, 7 Dec 1999 16:07:55 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 16:07:55 -0500 (EST) Resent-Message-Id: <199912072107.QAA24231@www19.w3.org> Message-ID: <384D751C.353D8BD8@us.oracle.com> Date: Tue, 07 Dec 1999 12:59:09 -0800 From: "Eric Sedlar" Organization: Oracle Corporation X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ccjason@us.ibm.com CC: "Geoffrey M. Clemm" , w3c-dist-auth@w3.org References: <85256840.0062B45C.00@D51MTA03.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3716 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Can a server implementer build both strong & weak BINDings and only allow cycles in weak bindings? --Eric ccjason@us.ibm.com wrote: > Alternately, a server implementer can disallow cyclic > bindings from being inserted in the first place, which is > computationally much cheaper, but which restricts the usefulness of > BINDings. (Like the way UNIX restricts hard links to directories). > > This is now forbidden by the spec. > > Just to clarify. By "this" Geoff was refering to the possibility of the > server not supporting cycles. The proposed changes now require servers > to allow cycles to be created. Geoff was not suggesting anything > regarding hard links to directories. Well either you can use the UNIX filesystem to support advanced collections or you can't. It sounds like the current answer is that you can't. From w3c-dist-auth-request@w3.org Tue Dec 7 17:38:15 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08411 for ; Tue, 7 Dec 1999 17:38:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA25778; Tue, 7 Dec 1999 17:26:28 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 17:26:28 -0500 (EST) Resent-Message-Id: <199912072226.RAA25778@www19.w3.org> Date: Tue, 7 Dec 1999 17:26:16 -0500 Message-Id: <9912072226.AA01406@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <384D741F.44120E3E@us.oracle.com> (esedlar@us.oracle.com) Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3717 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: "Eric Sedlar" I've implemented this type of system before, and the costs of mark and sweep are enormous when you are talking about large sets of documents living on disk (like in a relational database). People generally expect unlink/delete on a file to work quickly, and applications depend on that not eating up a tremendous amount of cycles or doing a lot of I/O. Mark and sweep is also much more expensive than forbidding the insertion of cycles. This is a classic garbage collection tradeoff. On one side, you can let the client define the relationships that it wants, and force the server to deal with issues like detecting islands of garbage. On the other side, you can require that the client only define relationships that are easy/efficient for the server to garbage collect. The problem with the latter approach is that there are different equally valid choices for how to constrain the relationships (the weak/strong dichotomy you suggest is certainly a very reasonable one). Reaching agreement on the constraints is very hard, since if your system was not implemented with those constraints in mind, they do you no good (and in fact, are probably even harder to implement than the general form). For example, the Unix file system also has weak and strong bindings (symbolic and hard links). It provides for efficient deletion, but it made some different choices from the ones you picked. In particular, it chose to leave the weak bindings (symbolic links) dangling when the last strong binding was deleted, and to only have the strong bindings (hard links) track resource movement. Trying to simulate in the Unix file system the weak/strong behavior you describe would be prohibitively expensive. So although it may be painful to only support one type of bindings, I believe it has the advantage that it is simpler to define and "fairer" across the various existing implementations. If you wait to do garbage collection asynchronously, searches that do not traverse the hierarchical namespace but that use other indexes (like keyword searches, for example) will find things that the user has deleted. WebDAV only supports searches that traverse the hierarchical namespace, so although I understand your point, it does not apply to WebDAV as it is currently defined. Once the "V" (versioning) is added to WebDAV, queries across the entire resource space will probably be rare in any case. Also, deferring the garbage collection associated with the unlink breaks the transactional guarantee when people COMMIT their work. There is no COMMIT functionality in WebDAV, so this would not be an issue. I can give you a perfectly good set of answers about how to deal with weak links. Oracle built a system that implements weak links and forbids cycles as part of the Internet Filesystem product. My responses to your issues are included below, marked with . The set of answers you provide for the Internet Filesystem product appear both consistent and very sensible, especially in the context of an underlying relational database implementation for the WebDAV store. Just one comment on the locking issue: locking a URL locks the namespace, not the resource. I assume this only applies to weak bindings (i.e. there must be some way to lock the resource itself, so I assume that is done through a strong binding?). While you have locked the URL containing a weak binding, nobody else can use that set of names in their respective collections. This sounds very different from WebDAV locks, which prevents unauthorized clients from modifying a resource, not from using it. Or by "use", did you mean "modify"? By "set of names", did you mean for example the set of names: {"/a/b/c", "/a/b", "/a"} that are relevant for a binding named "/a/b/c"? The resource the locked URL points to may actually be deleted while the URL to it is locked. In this case the resource is deleted when the lock is released. (Think of the lock like an open file descriptor, or in database terms, a snapshot in a read-only transaction that was started when the lock was acquired). This has the same effect as if someone deleted that resource the instant the lock was released. This could be hard for a server implement if it didn't have underlying transaction support. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Dec 7 17:42:17 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10314 for ; Tue, 7 Dec 1999 17:42:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA26032; Tue, 7 Dec 1999 17:30:40 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 17:30:40 -0500 (EST) Resent-Message-Id: <199912072230.RAA26032@www19.w3.org> Date: Tue, 7 Dec 1999 17:30:30 -0500 Message-Id: <9912072230.AA01414@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <384D751C.353D8BD8@us.oracle.com> (esedlar@us.oracle.com) Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3718 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: "Eric Sedlar" Can a server implementer build both strong & weak BINDings and only allow cycles in weak bindings? The current binding spec only defines strong bindings, but if your server only allows cycles with weak bindings, you could implement BIND by anchoring all resources with a strong binding outside of the URL space, and then use weak bindings to implement all BIND operations. ccjason@us.ibm.com wrote: > Alternately, a server implementer can disallow cyclic > bindings from being inserted in the first place, which is > computationally much cheaper, but which restricts the usefulness of > BINDings. (Like the way UNIX restricts hard links to directories). > > This is now forbidden by the spec. > > Just to clarify. By "this" Geoff was refering to the possibility of the > server not supporting cycles. The proposed changes now require servers > to allow cycles to be created. Geoff was not suggesting anything > regarding hard links to directories. Well either you can use the UNIX filesystem to support advanced collections or you can't. It sounds like the current answer is that you can't. You can, using the technique described above, i.e. implementing bindings as symbolic links into a source tree maintained outside of the URL namespace. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Dec 7 18:18:19 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27363 for ; Tue, 7 Dec 1999 18:18:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA27368; Tue, 7 Dec 1999 18:07:05 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 18:07:05 -0500 (EST) Resent-Message-Id: <199912072307.SAA27368@www19.w3.org> Message-ID: <384D9108.8F796130@us.oracle.com> Date: Tue, 07 Dec 1999 14:58:16 -0800 From: "Eric Sedlar" Organization: Oracle Corporation X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Geoffrey M. Clemm" CC: w3c-dist-auth@w3.org References: <9912072226.AA01406@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3719 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Are you assuming that WebDAV servers will generally be standalone repositories, or do expect existing repositories (e.g. ClearCase, MSExchange, Oracle RDBMS) will implement WebDAV in addition to other protocols they currently use to access information therein? Do you expect WebDAV servers to be only used for managing development content or also to manage production content? It would seem like you would want the broadest audience possible, and that would include existing servers and handling both development and production content. If you implementing WebDAV on an existing server breaks their existing guarantees, they won't be able to support WebDAV, which seems like an undesirable outcome. "Geoffrey M. Clemm" wrote: > > WebDAV only supports searches that traverse the hierarchical namespace, > so although I understand your point, it does not apply to WebDAV as it > is currently defined. Once the "V" (versioning) is added to WebDAV, > queries across the entire resource space will probably be rare in any case. > It seems to me that the most common type of WebDAV application would be managing content on a web site, and the most common type of search (as is most common today) would be the Yahoo-like one box keyword search across the entire resource space, or perhaps contrained across a certain class of resources, like Amazon's "Search all books" functionality. If I want to implement this functionality against a resource space managed by WebDAV, I'm screwed if I defer garbage collection. > > Also, > deferring the garbage collection associated with the unlink breaks the > transactional guarantee when people COMMIT their work. > > There is no COMMIT functionality in WebDAV, so this would not be an issue. > Are you assuming that WebDAV can only be implemented against non-transactional content repositories? If so, you should state that in the charter for WebDAV. I think you would be unnecessarily restricting the number of vendors interested in WebDAV if you did this. > > I can give you a perfectly good set of answers about how to deal with weak > links. Oracle built a system that implements weak links and forbids cycles as > part of the Internet Filesystem product. My responses to your issues are > included below, marked with . > > The set of answers you provide for the Internet Filesystem product > appear both consistent and very sensible, especially in the context of > an underlying relational database implementation for the WebDAV store. > > Just one comment on the locking issue: > > locking a URL locks the namespace, not the resource. > > I assume this only applies to weak bindings (i.e. there must be some > way to lock the resource itself, so I assume that is done through a > strong binding?). > I'm jumping to conclusions here based on the conversations you have been having with Yaron Goland. Given that some applications will want to reserve the entire pathname when they LOCK it to prevent it from being moved, it seemed like a dichotomy would have to be introduced where there are two separate types of LOCK operations: one that locks the name separately from another request that locks the resource it refers to. > > While you have > locked the URL containing a weak binding, nobody else can use that set of names > in their respective collections. > > This sounds very different from WebDAV locks, which prevents > unauthorized clients from modifying a resource, not from using it. > Or by "use", did you mean "modify"? > > By "set of names", did you mean for example the set of names: > {"/a/b/c", "/a/b", "/a"} that are relevant for a binding named "/a/b/c"? > I meant that the name "a" is reserved in the root collection, the name "b" is reserved in the "/a" collection, and the name "c" is reserved in the "/a/b" collection. By reserved, I meant that no new files could use those names in those collections, nor rename those names or move those links into another collection. > > The resource the locked URL points to may actually be deleted while > the URL to it is locked. In this case the resource > is deleted when the lock is released. (Think of the lock like an open file > descriptor, or in database terms, a snapshot in a read-only transaction that > was started when the lock was acquired). This has the same effect as if > someone deleted that resource the instant the lock was released. > > > This could be hard for a server implement if it didn't have underlying > transaction support. > Well UNIX doesn't go through a lot of hoops to maintain storage for open files. However, another way to do this is to increase the reference count on the resource by one for each BINDing and LOCK against the resource. Why do you think this would be hard? > > Cheers, > Geoff --Eric From w3c-dist-auth-request@w3.org Tue Dec 7 18:20:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28386 for ; Tue, 7 Dec 1999 18:20:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA27585; Tue, 7 Dec 1999 18:09:27 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 18:09:27 -0500 (EST) Resent-Message-Id: <199912072309.SAA27585@www19.w3.org> Message-ID: <384D919C.9FD474DB@us.oracle.com> Date: Tue, 07 Dec 1999 15:00:44 -0800 From: "Eric Sedlar" Organization: Oracle Corporation X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Geoffrey M. Clemm" CC: w3c-dist-auth@w3.org References: <9912072230.AA01414@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3720 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Couldn't you make PUT and MKCOL all create strong bindings, and then have weak BINDings from BIND? Then you wouldn't have to introduce fake bindings to maintain persistence? --Eric "Geoffrey M. Clemm" wrote: > From: "Eric Sedlar" > > Can a server implementer build both strong & weak BINDings and only allow > cycles in weak bindings? > > The current binding spec only defines strong bindings, but if your > server only allows cycles with weak bindings, you could implement BIND > by anchoring all resources with a strong binding outside of the URL > space, and then use weak bindings to implement all BIND operations. > > ccjason@us.ibm.com wrote: > > > Alternately, a server implementer can disallow cyclic > > bindings from being inserted in the first place, which is > > computationally much cheaper, but which restricts the usefulness of > > BINDings. (Like the way UNIX restricts hard links to directories). > > > > This is now forbidden by the spec. > > > > Just to clarify. By "this" Geoff was refering to the possibility of the > > server not supporting cycles. The proposed changes now require servers > > to allow cycles to be created. Geoff was not suggesting anything > > regarding hard links to directories. > > Well either you can use the UNIX filesystem to support advanced collections > or you can't. It sounds like the current answer is that you can't. > > You can, using the technique described above, i.e. implementing bindings > as symbolic links into a source tree maintained outside of the URL namespace. > > Cheers, > Geoff From w3c-dist-auth-request@w3.org Tue Dec 7 19:15:54 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23697 for ; Tue, 7 Dec 1999 19:15:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA29243; Tue, 7 Dec 1999 19:04:38 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 19:04:38 -0500 (EST) Resent-Message-Id: <199912080004.TAA29243@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Eric Sedlar" cc: "Geoffrey M. Clemm" , w3c-dist-auth@w3.org Message-ID: <85256841.00005E6A.00@D51MTA03.pok.ibm.com> Date: Tue, 7 Dec 1999 19:02:48 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3721 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >> Couldn't you make PUT and MKCOL all create strong bindings, and then have weak BINDings from BIND? Then you wouldn't have to introduce fake bindings to maintain persistence? >> You could do it many ways. If I interpret Geoff's proposal correctly, a bindings to collections would use a symbolic link and all bindings to non-collections would us bindings. Your suggested approach could also be taken. In WebDAV bindings created via GET/MKCOL are no more privledged than those created with BIND. If you decided to implement them differently, then you'll have two types of situations to handle when a DELETE is requested. You'd have handle deletion of bindings to directories implemented as hard links and as symbolic links. The deletion of a symbolic link just works. Deletion of a hard link isn't quite so easy. You can't just delete it because all those symbolic links get broken. ... so instead you'll have to delete one of the symbolic links and then move the "deleted" directory to the location where the symbolic link was. And then also redirect any other symbolic links. Of course in order to do all this, you have to keep track of all your symbolic links and manage them during method processing. Geoff's approach makes these methods map to trivial file system operations and allows GC'ing to be defered From w3c-dist-auth-request@w3.org Tue Dec 7 22:58:21 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15922 for ; Tue, 7 Dec 1999 22:58:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA02769; Tue, 7 Dec 1999 22:47:24 -0500 (EST) Resent-Date: Tue, 7 Dec 1999 22:47:24 -0500 (EST) Resent-Message-Id: <199912080347.WAA02769@www19.w3.org> Date: Tue, 7 Dec 1999 22:47:03 -0500 Message-Id: <9912080347.AA01622@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <384D9108.8F796130@us.oracle.com> (esedlar@us.oracle.com) Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3722 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Before diving in, I'd like to thank Eric for becoming active in the working group! Getting this kind of in depth analysis is of immense value as we try to nail down the spec for last call. From: "Eric Sedlar" Are you assuming that WebDAV servers will generally be standalone repositories, or do expect existing repositories (e.g. ClearCase, MSExchange, Oracle RDBMS) will implement WebDAV in addition to other protocols they currently use to access information therein? The latter. Do you expect WebDAV servers to be only used for managing development content or also to manage production content? Both. It would seem like you would want the broadest audience possible, and that would include existing servers and handling both development and production content. Definitely. If you implementing WebDAV on an existing server breaks their existing guarantees, they won't be able to support WebDAV, which seems like an undesirable outcome. The challenge is that different server implementations (e.g. file systems, relational databases, document mgmt repositories, versioning repositories) have very different guarantees, so defining a protocol that allows clients to interoperate with all of them inevitably leads to choices that are not optimal for any particular existing server. The example of the Unix file system was intended to illustrate how your (very reasonable) definition of strong/weak bindings are problematic when applied to a different server implementation (i.e. the Unix file system). It seems to me that the most common type of WebDAV application would be managing content on a web site, and the most common type of search (as is most common today) would be the Yahoo-like one box keyword search across the entire resource space, or perhaps contrained across a certain class of resources, like Amazon's "Search all books" functionality. If I want to implement this functionality against a resource space managed by WebDAV, I'm screwed if I defer garbage collection. A WebDAV site will commonly contained the source resources from which derived resources are computed, as well as historical information (e.g. previous revisions of existing information). In the case of Yahoo-like searches, unless they are constrained to a particular tree (and in the case of versioning, a particular tree with a particular target-selector header), many/most of the "hits" will be incorrect. The "search all resources" approach works when only "deployed" resources exist at a site ... with WebDAV support, there will be much more available, and naive searches that don't restrict themselves to a particular hierarchy will no longer be effective. > Also, > deferring the garbage collection associated with the unlink breaks the > transactional guarantee when people COMMIT their work. > > There is no COMMIT functionality in WebDAV, so this would not be an issue. Are you assuming that WebDAV can only be implemented against non-transactional content repositories? No - we are just assuming that WebDAV must be implementable on either a transactional or a non-transactional server, which means that no cross-request transactional behavior can be assumed or required. If so, you should state that in the charter for WebDAV. I think you would be unnecessarily restricting the number of vendors interested in WebDAV if you did this. If there is any problem implementing WebDAV on a transactional server, please flag it! My point was just that WebDAV cannot assume cross-request transactional behavior, so an argument based on what is needed to support cross-request transactions would not apply to the WebDAV protocol. Perhaps I misunderstood your point about COMMIT? > locking a URL locks the namespace, not the resource. > > I assume this only applies to weak bindings (i.e. there must be some > way to lock the resource itself, so I assume that is done through a > strong binding?). I'm jumping to conclusions here based on the conversations you have been having with Yaron Goland. Given that some applications will want to reserve the entire pathname when they LOCK it to prevent it from being moved, it seemed like a dichotomy would have to be introduced where there are two separate types of LOCK operations: one that locks the name separately from another request that locks the resource it refers to. Currently, that is not the case for RFC-2518. A lock is applied to the URL and results in both a lock on the resource identified by the URL, and the protection of the mapping of that URL to that resource. > The resource the locked URL points to may actually be deleted while > the URL to it is locked. In this case the resource > is deleted when the lock is released. (Think of the lock like an open file > descriptor, or in database terms, a snapshot in a read-only transaction that > was started when the lock was acquired). This has the same effect as if > someone deleted that resource the instant the lock was released. > > > This could be hard for a server implement if it didn't have underlying > transaction support. Well UNIX doesn't go through a lot of hoops to maintain storage for open files. However, another way to do this is to increase the reference count on the resource by one for each BINDing and LOCK against the resource. Why do you think this would be hard? Well, the creation of those .nfsxxx files that sometimes don't get garbage collected properly are some pretty ugly hoops (:-). But more to the point, RFC-2518 currently states that a locked resource can only be deleted by a holder of the lock token, and that if you do hold the lock token and issue a DELETE, the DELETE applies immediately and is not deferred until the lock is removed. So the DELETE semantics you describe would not be compliant with RFC-2518. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Dec 8 16:09:27 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16604 for ; Wed, 8 Dec 1999 16:09:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA00950; Wed, 8 Dec 1999 15:57:18 -0500 (EST) Resent-Date: Wed, 8 Dec 1999 15:57:18 -0500 (EST) Resent-Message-Id: <199912082057.PAA00950@www19.w3.org> Message-ID: <00ea01bf41be$e1280030$79442382@us.oracle.com> From: "Eric Sedlar" To: "Geoffrey M. Clemm" , References: <9912080347.AA01622@tantalum> Date: Wed, 8 Dec 1999 12:57:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3723 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit The reason you give that repository-wide searches are not likely is that you won't want to search all of the revisions? Most of the revision selection mechanisms are not dependent on position in the hierarchy, and so I could do some simple SQL like: SELECT ... FROM labels, resources where labels.name = and labels.resource-id = resources.resource-id and resources.body contains(keyword1, keyword2, ...) This would select all the documents with a particular label with the keywords requested. The same type of thing can be done with typical text-search engines. Let me ask another question though: * let's say I create versioned resource /foo/bar.txt. * I bind another name to that resource, so now we have /werf/bar.txt pointing to the same resource * I label the currently selected revision of /foo/bar.txt with some tag I assume that a revision selection rule specifying that label for /foo/bar.txt would also apply that selection if it encountered /werf/bar.txt as well, correct? From a performance standpoint, I would like to point out that the types of indexes that work for hierarchy-independent searches tend to be MUCH faster than traversing hierarchies. Database indexes (or should I say indices?) as well as text-search engines will both see a significant performance slowdown if you force queries to traverse the URL hierarchy for all access. Plus you will have to do a bunch of development on all of these search engines to handle the join with the hierarchical information. I STRONGLY recommend not REQUIRING hierarchical access to WebDAV-managed content. You will break most of the search technology currently in use on the web. I can tell you that if most Oracle customers are offered the choice of having a bunch of great neat content management functionality at the price of decreasing search performance, they will stick with the search performance. Nothing irritates users more than waiting for search results. For this reason alone, I think it is worth adding the concept of weak BINDings to the Advanced Collections spec, since I think a lot of server implementors will want to avoid dealing with cyclic references that impact object persistence and avoid garbage collection. --Eric > > Before diving in, I'd like to thank Eric for becoming active > in the working group! Getting this kind of in depth analysis > is of immense value as we try to nail down the spec for last call. > > From: "Eric Sedlar" > > Are you assuming that WebDAV servers will generally be standalone > repositories, or do expect existing repositories (e.g. ClearCase, > MSExchange, Oracle RDBMS) will implement WebDAV in addition to other > protocols they currently use to access information therein? > > The latter. > > Do you > expect WebDAV servers to be only used for managing development content > or also to manage production content? > > Both. > > It would seem like you would > want the broadest audience possible, and that would include existing > servers and handling both development and production content. > > Definitely. > > If you > implementing WebDAV on an existing server breaks their existing > guarantees, they won't be able to support WebDAV, which seems like an > undesirable outcome. > > The challenge is that different server implementations (e.g. file > systems, relational databases, document mgmt repositories, versioning > repositories) have very different guarantees, so defining a protocol > that allows clients to interoperate with all of them inevitably leads > to choices that are not optimal for any particular existing server. > > The example of the Unix file system was intended to illustrate how > your (very reasonable) definition of strong/weak bindings are problematic > when applied to a different server implementation (i.e. the Unix file > system). > > It seems to me that the most common type of WebDAV application would > be managing content on a web site, and the most common type of search > (as is most common today) would be the Yahoo-like one box keyword > search across the entire resource space, or perhaps contrained across > a certain class of resources, like Amazon's "Search all books" > functionality. If I want to implement this functionality against a > resource space managed by WebDAV, I'm screwed if I defer garbage > collection. > > A WebDAV site will commonly contained the source resources from which > derived resources are computed, as well as historical information > (e.g. previous revisions of existing information). In the case of > Yahoo-like searches, unless they are constrained to a particular tree > (and in the case of versioning, a particular tree with a particular > target-selector header), many/most of the "hits" will be incorrect. > The "search all resources" approach works when only "deployed" > resources exist at a site ... with WebDAV support, there will be much > more available, and naive searches that don't restrict themselves > to a particular hierarchy will no longer be effective. > > > Also, > > deferring the garbage collection associated with the unlink breaks the > > transactional guarantee when people COMMIT their work. > > > > There is no COMMIT functionality in WebDAV, so this would not be an issue. > > Are you assuming that WebDAV can only be implemented against > non-transactional content repositories? > > No - we are just assuming that WebDAV must be implementable > on either a transactional or a non-transactional server, which > means that no cross-request transactional behavior can be > assumed or required. > > If so, you should state that > in the charter for WebDAV. I think you would be unnecessarily > restricting the number of vendors interested in WebDAV if you did > this. > > If there is any problem implementing WebDAV on a transactional server, > please flag it! My point was just that WebDAV cannot assume cross-request > transactional behavior, so an argument based on what is needed to support > cross-request transactions would not apply to the WebDAV protocol. > Perhaps I misunderstood your point about COMMIT? > > > locking a URL locks the namespace, not the resource. > > > > I assume this only applies to weak bindings (i.e. there must be some > > way to lock the resource itself, so I assume that is done through a > > strong binding?). > > I'm jumping to conclusions here based on the conversations you have > been having with Yaron Goland. Given that some applications will want > to reserve the entire pathname when they LOCK it to prevent it from > being moved, it seemed like a dichotomy would have to be introduced > where there are two separate types of LOCK operations: one that locks > the name separately from another request that locks the resource it > refers to. > > Currently, that is not the case for RFC-2518. A lock is applied to the > URL and results in both a lock on the resource identified by the URL, > and the protection of the mapping of that URL to that resource. > > > The resource the locked URL points to may actually be deleted while > > the URL to it is locked. In this case the resource > > is deleted when the lock is released. (Think of the lock like an open file > > descriptor, or in database terms, a snapshot in a read-only transaction that > > was started when the lock was acquired). This has the same effect as if > > someone deleted that resource the instant the lock was released. > > > > > > This could be hard for a server implement if it didn't have underlying > > transaction support. > > Well UNIX doesn't go through a lot of hoops to maintain storage for > open files. However, another way to do this is to increase the > reference count on the resource by one for each BINDing and LOCK > against the resource. Why do you think this would be hard? > > Well, the creation of those .nfsxxx files that sometimes don't get > garbage collected properly are some pretty ugly hoops (:-). But more > to the point, RFC-2518 currently states that a locked resource can > only be deleted by a holder of the lock token, and that if you do hold > the lock token and issue a DELETE, the DELETE applies immediately and > is not deferred until the lock is removed. So the DELETE semantics > you describe would not be compliant with RFC-2518. > > Cheers, > Geoff > > From w3c-dist-auth-request@w3.org Thu Dec 9 03:25:26 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07989 for ; Thu, 9 Dec 1999 03:25:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA14034; Thu, 9 Dec 1999 03:14:23 -0500 (EST) Resent-Date: Thu, 9 Dec 1999 03:14:23 -0500 (EST) Resent-Message-Id: <199912090814.DAA14034@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Eric Sedlar" cc: "Geoffrey M. Clemm" , w3c-dist-auth@w3.org Message-ID: <85256842.002D0C3C.00@D51MTA03.pok.ibm.com> Date: Thu, 9 Dec 1999 03:09:21 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3724 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >> I can tell you that if most Oracle customers are offered the choice of having a bunch of great neat content management functionality at the price of decreasing search performance, they will stick with the search performance. Nothing irritates users more than waiting for search results. >> On the comment I quoted above...Are we talking about text searches? You did mention text searches above. If performance were important, wouldn't you build an index and just use the index to service queries? ... just like most search systems do? If you use an index, the amount of time users wait for search results is not really relevant to your point. The performance will be the same either way. From w3c-dist-auth-request@w3.org Thu Dec 9 12:48:48 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28275 for ; Thu, 9 Dec 1999 12:48:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA14860; Thu, 9 Dec 1999 12:36:47 -0500 (EST) Resent-Date: Thu, 9 Dec 1999 12:36:47 -0500 (EST) Resent-Message-Id: <199912091736.MAA14860@www19.w3.org> Message-ID: <384FE699.85F70CD6@us.oracle.com> Date: Thu, 09 Dec 1999 09:27:53 -0800 From: "Eric Sedlar" Organization: Oracle Corporation X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ccjason@us.ibm.com CC: "Geoffrey M. Clemm" , w3c-dist-auth@w3.org References: <85256842.002D0C3C.00@D51MTA03.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3725 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Of course you will build an index. That's the problem, because you are locating the data without traversing the collection hierarchy to find the data. Let's say you find a hit using that index. That item may actually have been deleted because you have deferred garbage collection, and there is no way to update the index to remove that item until the actual resource has been deleted. If you were traversing the hierarchy as well, you wouldn't find that item if it would be garbage collected later because there wouldn't be a path to find it. --Eric ccjason@us.ibm.com wrote: > >> > I can tell you > that if most Oracle customers are offered the choice of having a bunch of > great neat content management functionality at the price of decreasing > search performance, they will stick with the search performance. Nothing > irritates users more than waiting for search results. > >> > On the comment I quoted above...Are we talking about text searches? > You did mention text searches above. > If performance were important, > wouldn't you build an index and just use the index to service queries? > ... just like most search systems do? If you use an index, the amount > of time users wait for search results is not really relevant to your > point. The performance will be the same either way. From w3c-dist-auth-request@w3.org Thu Dec 9 19:42:37 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27275 for ; Thu, 9 Dec 1999 19:42:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA28820; Thu, 9 Dec 1999 19:31:16 -0500 (EST) Resent-Date: Thu, 9 Dec 1999 19:31:16 -0500 (EST) Resent-Message-Id: <199912100031.TAA28820@www19.w3.org> To: w3c-dist-auth@w3.org Date: Fri, 10 Dec 1999 01:26:16 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <19991210002616.C13C5610DB@aachen.heimat.de> From: ruebe@aachen.heimat.de (Christian Scholz) Subject: Announce Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3726 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi everybody! I wanted to announce the first release of my python davserver. This work is part of my thesis which will be a webdav enabled groupware when it is finished. What is it? python davserver is a bundle of python classes which form a davserver framework. It is divided in the main davserver class which runs as a daemon and an interface class which has the purpose of getting the actual data to serve. Thus one only has to write this interface class in order to extend one's application with a davserver. In the distribution there is one example of interfacing a normal filesystem. What's the status? The version is 0.1 which means that it is right at the beginning. But it's working locally for me with cadaver (a command line dav client for unix). It's not working with Web Folders right now but I decided to release it anyway to get it started. (Any maybe someone else has an idea why it is now working with web folder which only says "error", which does not help a lot ;-). Ok, look at it at http://webdav.de or download it directly at ftp://comlounge.net/webdav/davserver-0.1.tar.gz You will need Python 1.5 to run it (along with the xml parsers). So far it's only tested with Linux (SuSE 6.3, Kernel 2.2) but should run on other platforms also. best, Christian From w3c-dist-auth-request@w3.org Fri Dec 10 00:10:40 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09442 for ; Fri, 10 Dec 1999 00:10:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA04445; Thu, 9 Dec 1999 23:55:58 -0500 (EST) Resent-Date: Thu, 9 Dec 1999 23:55:58 -0500 (EST) Resent-Message-Id: <199912100455.XAA04445@www19.w3.org> Date: Thu, 9 Dec 1999 23:55:37 -0500 Message-Id: <9912100455.AA02972@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <384FE699.85F70CD6@us.oracle.com> (esedlar@us.oracle.com) Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3727 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Why not just add a "deleted" attribute to a resource, set this to be "true" when a resource is deleted, and then automatically add "!deleted" to search queries? Cheers, Geoff From: "Eric Sedlar" Of course you will build an index. That's the problem, because you are locating the data without traversing the collection hierarchy to find the data. Let's say you find a hit using that index. That item may actually have been deleted because you have deferred garbage collection, and there is no way to update the index to remove that item until the actual resource has been deleted. If you were traversing the hierarchy as well, you wouldn't find that item if it would be garbage collected later because there wouldn't be a path to find it. ccjason@us.ibm.com wrote: > >> > I can tell you > that if most Oracle customers are offered the choice of having a bunch of > great neat content management functionality at the price of decreasing > search performance, they will stick with the search performance. Nothing > irritates users more than waiting for search results. > >> > On the comment I quoted above...Are we talking about text searches? > You did mention text searches above. > If performance were important, > wouldn't you build an index and just use the index to service queries? > ... just like most search systems do? If you use an index, the amount > of time users wait for search results is not really relevant to your > point. The performance will be the same either way. From w3c-dist-auth-request@w3.org Fri Dec 10 03:32:21 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26510 for ; Fri, 10 Dec 1999 03:32:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA08960; Fri, 10 Dec 1999 03:21:01 -0500 (EST) Resent-Date: Fri, 10 Dec 1999 03:21:01 -0500 (EST) Resent-Message-Id: <199912100821.DAA08960@www19.w3.org> Message-ID: <3850B5D9.615291B7@us.oracle.com> Date: Fri, 10 Dec 1999 00:12:10 -0800 From: "Eric Sedlar" Organization: Oracle Corporation X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Geoffrey M. Clemm" CC: w3c-dist-auth@w3.org References: <9912100455.AA02972@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3728 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit If you have an orphaned cycle, the reference count doesn't get decremented to zero, so you don't know to set a deleted flag. You don't know what is going to be deleted until you do a graph traversal. Let's say we have the following files, ID = 1 & Id =2. /a identifies resource 1. /a/b identifies resource 2. We bind /a into /a/b, creating a cycle (I can now get to resource 1 with /a/b/a). The refcount on /a is 2 (the BINDing from root and the one from /a/b). The refcount on /a/b is 1 (the BINDing from /a). Now I unlink /a from root. Both resource 1 (the former /a) and resource 2 (the former /a/b) now have refcounts of 1. However, both should be deleted as I now have an orphaned cycle (RFC2518 specifies that deletes are recursive to infinity). There is no way to detect this condition without the garbage collection. Until the garbage collection runs, resources 1 & 2 will still show up on hits. Garbage collection on in-memory objects (like in a Java VM) is bad enough. Doing it on disk is incredibly awful. Many applications find the need to issue lots of bulk DELETEs (delete *.* in this directory, for example). Each of these will require a separate path traversal if you are doing this synchronously. The problem with WebDAV BINDings as currently spec'ed, as well as UNIX hard links, is that they have both navigation and persistence semantics. The reason people want to create cycles of BINDings / links is for navigational reasons, not for persistence reasons. If you have a "smart" weak link that follows the referenced object and is removed when the referenced object is removed, you have all the functionality that most use cases require. --Eric "Geoffrey M. Clemm" wrote: > Why not just add a "deleted" attribute to a resource, set this to > be "true" when a resource is deleted, and then automatically add > "!deleted" to search queries? > > Cheers, > Geoff > > From: "Eric Sedlar" > > Of course you will build an index. That's the problem, because you are > locating the data without traversing the collection hierarchy to find the > data. Let's say you find a hit using that index. That item may actually > have been deleted because you have deferred garbage collection, and there is > no way to update the index to remove that item until the actual resource has > been deleted. If you were traversing the hierarchy as well, you wouldn't > find that item if it would be garbage collected later because there wouldn't > be a path to find it. > > ccjason@us.ibm.com wrote: > > > >> > > I can tell you > > that if most Oracle customers are offered the choice of having a bunch of > > great neat content management functionality at the price of decreasing > > search performance, they will stick with the search performance. Nothing > > irritates users more than waiting for search results. > > > >> > > On the comment I quoted above...Are we talking about text searches? > > You did mention text searches above. > > If performance were important, > > wouldn't you build an index and just use the index to service queries? > > ... just like most search systems do? If you use an index, the amount > > of time users wait for search results is not really relevant to your > > point. The performance will be the same either way. From w3c-dist-auth-request@w3.org Fri Dec 10 10:52:30 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25690 for ; Fri, 10 Dec 1999 10:52:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA20673; Fri, 10 Dec 1999 10:39:43 -0500 (EST) Resent-Date: Fri, 10 Dec 1999 10:39:43 -0500 (EST) Resent-Message-Id: <199912101539.KAA20673@www19.w3.org> Date: Fri, 10 Dec 1999 10:39:33 -0500 Message-Id: <9912101539.AA03284@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <3850B5D9.615291B7@us.oracle.com> (esedlar@us.oracle.com) Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3729 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list "Geoffrey M. Clemm" wrote: Why not just add a "deleted" attribute to a resource, set this to be "true" when a resource is deleted, and then automatically add "!deleted" to search queries? From: "Eric Sedlar" If you have an orphaned cycle, the reference count doesn't get decremented to zero, so you don't know to set a deleted flag. Perhaps my choice of name for the flag was misleading. Let's call it the "hidden" flag, instead of the "deleted" flag. My point wasn't that a hidden flag solves the problem of doing garbage collection, but rather that you can use the hidden flag to give a client the ability to say "this resource should no longer appear in searches". If your server wants to classify certain bindings as "strong" (e.g. those created by PUT and MKCOL) and other bindings as "weak" (e.g. those created by BIND), and then automatically set the hidden flag on a whole tree of resources when that "strong" binding is deleted, it is free to do so. The problem with WebDAV BINDings as currently spec'ed, as well as UNIX hard links, is that they have both navigation and persistence semantics. The reason people want to create cycles of BINDings / links is for navigational reasons, not for persistence reasons. If you have a "smart" weak link that follows the referenced object and is removed when the referenced object is removed, you have all the functionality that most use cases require. I agree that there are some relationships that the user wants to use to imply persistence, and others where the user only wants to get navigation. It is also true that WebDAV bindings are specifically designed for use when the user wants to imply persistence. If you want a link that does not imply persistence, you do have "redirect references" at your disposal. Although they do not have exactly the semantics you describe, they should let you do what you want with with weak bindings. In particular, they do not have any implication of persistence, but they do allow navigation. The main differences between your weak bindings and redirect references is that the client is responsible for doing more of the work. In particular, the client must make a second request to get to the destination, and the client must delete the link if it doesn't like it dangling. Redirect references were defined this way to support cross-server references (where it is unlikely that a server would be able to know about, much less delete, all the references into it from other servers). Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Dec 10 15:04:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02150 for ; Fri, 10 Dec 1999 15:04:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA29325; Fri, 10 Dec 1999 14:52:29 -0500 (EST) Resent-Date: Fri, 10 Dec 1999 14:52:29 -0500 (EST) Resent-Message-Id: <199912101952.OAA29325@www19.w3.org> Message-ID: <018f01bf4348$226b58f0$79442382@us.oracle.com> From: "Eric Sedlar" To: "Geoffrey M. Clemm" , References: <9912101539.AA03284@tantalum> Date: Fri, 10 Dec 1999 11:52:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3730 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit In the example I gave, assuming only strong BINDings as defined in the draft spec, how would you know to set the hidden flag? How would the client know to set it in that case? My point is that until you do the garbage collection, you don't know whether or not the object should remain for future searches. My suggestions regarding weak BINDings don't address the needs for symbolic links (or redirect references as you are calling them) in the spec, because of the cross-server reasons you cite. I can't do what I want with weak references as long as the spec says that: 1) BINDings must affect persistence 2) BINDings can be cyclic If the spec just said that BINDings may not dangle (dang it!) but that the server has a choice of either removing other BINDings (in my case if they are weak) or affecting the refcount, that would let me do it. However, it would be best if the client knew about weak vs. strong references, so that I don't have to extend the standard to choose a strong vs. weak binding. --Eric ----- Original Message ----- From: Geoffrey M. Clemm To: Sent: Friday, December 10, 1999 7:39 AM Subject: Re: BINDing using a weak reference > > "Geoffrey M. Clemm" wrote: > Why not just add a "deleted" attribute to a resource, set this to > be "true" when a resource is deleted, and then automatically add > "!deleted" to search queries? > > From: "Eric Sedlar" > If you have an orphaned cycle, the reference count doesn't get > decremented to zero, so you don't know to set a deleted flag. > > Perhaps my choice of name for the flag was misleading. Let's > call it the "hidden" flag, instead of the "deleted" flag. > > My point wasn't that a hidden flag solves the problem of doing garbage > collection, but rather that you can use the hidden flag to give a > client the ability to say "this resource should no longer appear in > searches". If your server wants to classify certain bindings as > "strong" (e.g. those created by PUT and MKCOL) and other bindings as > "weak" (e.g. those created by BIND), and then automatically set the > hidden flag on a whole tree of resources when that "strong" binding is > deleted, it is free to do so. > > The problem with WebDAV BINDings as currently spec'ed, as well as UNIX > hard links, is that they have both navigation and persistence > semantics. The reason people want to create cycles of BINDings / > links is for navigational reasons, not for persistence reasons. If > you have a "smart" weak link that follows the referenced object and is > removed when the referenced object is removed, you have all the > functionality that most use cases require. > > I agree that there are some relationships that the user wants to use > to imply persistence, and others where the user only wants to get > navigation. It is also true that WebDAV bindings are specifically > designed for use when the user wants to imply persistence. > > If you want a link that does not imply persistence, you do have > "redirect references" at your disposal. Although they do not have > exactly the semantics you describe, they should let you do what you > want with with weak bindings. In particular, they do not have any > implication of persistence, but they do allow navigation. > > The main differences between your weak bindings and redirect > references is that the client is responsible for doing more of the > work. In particular, the client must make a second request to get to > the destination, and the client must delete the link if it doesn't > like it dangling. Redirect references were defined this way to > support cross-server references (where it is unlikely that a server > would be able to know about, much less delete, all the references > into it from other servers). > > Cheers, > Geoff > > From w3c-dist-auth-request@w3.org Sat Dec 11 07:48:30 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24906 for ; Sat, 11 Dec 1999 07:48:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA18160; Sat, 11 Dec 1999 07:36:00 -0500 (EST) Resent-Date: Sat, 11 Dec 1999 07:36:00 -0500 (EST) Resent-Message-Id: <199912111236.HAA18160@www19.w3.org> Date: Sat, 11 Dec 1999 04:37:10 -0800 (PST) From: Greg Stein To: "Geoffrey M. Clemm" , esedlar@us.oracle.com cc: w3c-dist-auth@w3.org In-Reply-To: <9912080347.AA01622@tantalum> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: BINDing using a weak reference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3731 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Tue, 7 Dec 1999, Geoffrey M. Clemm wrote: >... > From: "Eric Sedlar" > > Are you assuming that WebDAV servers will generally be standalone > repositories, or do expect existing repositories (e.g. ClearCase, > MSExchange, Oracle RDBMS) will implement WebDAV in addition to other > protocols they currently use to access information therein? > > The latter. Already demonstrated. mod_dav ships with the Unix filesystem for a repository. However, there are two (private builds) of mod_dav: one that works against ClearCase (and is experimenting with the versioning spec!), and one that delegates the back-end services through CORBA. There have been some rumblings about using PHP scripting to back-end mod_dav, but nothing has been completed there, yet (that I know of). Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat Dec 11 09:15:19 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26049 for ; Sat, 11 Dec 1999 09:15:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA19405; Sat, 11 Dec 1999 09:03:47 -0500 (EST) Resent-Date: Sat, 11 Dec 1999 09:03:47 -0500 (EST) Resent-Message-Id: <199912111403.JAA19405@www19.w3.org> Date: Sat, 11 Dec 1999 14:03:20 +0000 From: Joe Orton To: feedback@mydocsonline.com Cc: w3c-dist-auth@w3.org Message-ID: <19991211140320.B398@ankh.dunno.local> Mail-Followup-To: feedback@mydocsonline.com, w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Subject: webfolders.mydocsonline.com server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3732 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The PROPFIND response on this server is broken. I send: PROPFIND / HTTP/1.1 User-Agent: cadaver/0.5.0 Connection: Keep-Alive Host: webfolders.mydocsonline.com Content-Type: text/xml Depth: 0 Content-Length: 152 Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxx Response body is: / Oct, Jan GMT HTTP/1.1 200 OK HTTP/1.1 404 Not Found Where the DAV:getlastmodified element is corrupt. Regards, joe From w3c-dist-auth-request@w3.org Sat Dec 11 09:37:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26369 for ; Sat, 11 Dec 1999 09:37:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA20073; Sat, 11 Dec 1999 09:27:08 -0500 (EST) Resent-Date: Sat, 11 Dec 1999 09:27:08 -0500 (EST) Resent-Message-Id: <199912111427.JAA20073@www19.w3.org> Date: Sat, 11 Dec 1999 06:28:28 -0800 (PST) From: Greg Stein To: Joe Orton cc: feedback@mydocsonline.com, w3c-dist-auth@w3.org In-Reply-To: <19991211140320.B398@ankh.dunno.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: webfolders.mydocsonline.com server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3733 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Sat, 11 Dec 1999, Joe Orton wrote: > The PROPFIND response on this server is broken. I send: >... > Response body is: > > > > > / > > > Oct, Jan GMT > > > HTTP/1.1 200 OK > > > > > > HTTP/1.1 404 Not Found > > > > > Where the DAV:getlastmodified element is corrupt. The MyDocsOnline server is mod_dav (modified, I believe) under the covers. Looking at the code for getlastmodified, it would seem there is a problem with the C lib on the server. I'm doing the following: sprintf(buf, "%s, %.2d %s %d %.2d:%.2d:%.2d GMT", I can't see how it would generate the text you saw... very weird. I don't have a developer contact there, so let's hope they're listening here or will respond soon with the feedback@ address (so I can help them with the problem). Thanx for reporting this, Joe! Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat Dec 11 14:46:31 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28521 for ; Sat, 11 Dec 1999 14:46:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA22552; Sat, 11 Dec 1999 14:34:02 -0500 (EST) Resent-Date: Sat, 11 Dec 1999 14:34:02 -0500 (EST) Resent-Message-Id: <199912111934.OAA22552@www19.w3.org> Date: Sat, 11 Dec 1999 19:21:13 +0000 From: Joe Orton To: webdav@zope.org Cc: w3c-dist-auth@w3c.org Message-ID: <19991211192113.B867@ankh.dunno.local> Mail-Followup-To: webdav@zope.org, w3c-dist-auth@w3c.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Subject: Zope: URI encoding problem Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3734 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Against the server at webdav.zope.org:2518, I do a MKCOL on /users/jorton/e/users/jorton/e%3cf/ But, PROPFIND depth 0 on /users/jorton/e%3cf/ returns it incorrectly, as: /users/jorton/e%253cf/ which looks like it has been through the URI encoding routine twice (% -> %25). Regards, joe From w3c-dist-auth-request@w3.org Thu Dec 16 03:19:38 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08698 for ; Thu, 16 Dec 1999 03:19:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA22915; Thu, 16 Dec 1999 00:15:37 -0500 (EST) Resent-Date: Thu, 16 Dec 1999 00:15:37 -0500 (EST) Resent-Message-Id: <199912160515.AAA22915@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 15 Dec 1999 18:04:41 -0800 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 Subject: Adv. Collections Teleconf. Minutes 12/1, 12/8, 12/15 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3735 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I've gotten a little behind in posting minutes from the Advanced Collections Teleconferences, sorry :-( Minutes from the December 1, Decembe 8, and December 15 teleconferences are now available online, at: December 1, 1999: http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes991201.txt December 8, 1999: http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes991208.txt December 15, 1999: http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes991215.txt Many thanks to Judy Slein for organizing these conference calls, and recording minutes! - Jim From w3c-dist-auth-request@w3.org Tue Dec 21 15:21:14 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27849 for ; Tue, 21 Dec 1999 15:21:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA19767; Tue, 21 Dec 1999 15:09:02 -0500 (EST) Resent-Date: Tue, 21 Dec 1999 15:09:02 -0500 (EST) Resent-Message-Id: <199912212009.PAA19767@www19.w3.org> Date: Tue, 21 Dec 1999 19:24:15 +0000 From: Joe Orton To: feedback@mydocsonline.com, support@mydocsonline.com Cc: w3c-dist-auth@w3.org Message-ID: <19991221192415.B286@ankh.dunno.local> Mail-Followup-To: feedback@mydocsonline.com, support@mydocsonline.com, w3c-dist-auth@w3.org References: <19991211140320.B398@ankh.dunno.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from gstein@lyra.org on Sat, Dec 11, 1999 at 06:28:28AM -0800 Subject: Re: webfolders.mydocsonline.com server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3736 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The PROPFIND problem seems to have gone away... I've not heard back about any bugs being fixed, though. So, more testing: MKCOL gives 500 internal server error. Request: MKCOL /foo/ HTTP/1.1 User-Agent: cadaver/0.6.0-dev Connection: Keep-Alive Host: webfolders.mydocsonline.com Authorization: Basic xxx Response headers: HTTP/1.1 500 Internal Server Error Date: Tue, 21 Dec 1999 18:11:50 GMT Server: Apache/1.3.6 (Unix) DAV/0.9-MyDocs Connection: close Transfer-Encoding: chunked Content-Type: text/html Regards, joe From w3c-dist-auth-request@w3.org Wed Dec 22 07:10:25 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06344 for ; Wed, 22 Dec 1999 07:10:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA07400; Wed, 22 Dec 1999 06:59:16 -0500 (EST) Resent-Date: Wed, 22 Dec 1999 06:59:16 -0500 (EST) Resent-Message-Id: <199912221159.GAA07400@www19.w3.org> Message-Id: <199912221159.GAA06059@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 22 Dec 1999 06:59:01 -0500 Subject: I-D ACTION:draft-ietf-webdav-binding-protocol-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3737 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Bindings Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford Filename : draft-ietf-webdav-binding-protocol-01.txt Pages : 25 Date : 21-Dec-99 The WebDAV Distributed Authoring Protocol provides basic support for collections, offering the ability to create and list unordered collections. This specification is one of a group of three specifications that supplement the WebDAV Distributed Authoring Protocol to increase the power of WebDAV collections. This specification defines bindings, one mechanism for allowing a single resource to appear in more than one collection. Bindings make this possible by creating mappings of URIs to resources. The BIND method defined here gives clients the ability to create new bindings to existing resources. The second specification, 'WebDAV Redirect Reference Resources'[RR], defines redirect references, another approach to allowing a single resource to be accessed from multiple collections. The third specification, 'WebDAV Ordered Collections Protocol'[OC], provides a mechanism for ordering collections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-binding-protocol-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-binding-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-binding-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991221121544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-binding-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-binding-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991221121544.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed Dec 22 07:10:25 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06346 for ; Wed, 22 Dec 1999 07:10:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA07441; Wed, 22 Dec 1999 06:59:32 -0500 (EST) Resent-Date: Wed, 22 Dec 1999 06:59:32 -0500 (EST) Resent-Message-Id: <199912221159.GAA07441@www19.w3.org> Message-Id: <199912221159.GAA06087@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 22 Dec 1999 06:59:13 -0500 Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-02.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3739 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Redirect Reference Resources Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford Filename : draft-ietf-webdav-redirectref-protocol-02.txt Pages : 26 Date : 21-Dec-99 This is one of a pair of specifications that extend the WebDAV Distributed Authoring Protocol to enable clients to create new access paths to existing resources. The two protocol extensions have very different characteristics that make them useful for different sorts of applications. The present specification defines redirect reference resources. A redirect reference resource is a resource whose default response is an HTTP/1.1 302 (Found) status code, redirecting the client to a different resource, the target resource. A redirect reference makes it possible to access the target resource indirectly, through any URI mapped to the redirect reference resource. There are no integrity guarantees associated with redirect reference resources. The related specification, RFC xxxx, defines bindings, and the BIND method for creating them. Creating a new binding to a resource indirectly creates one or more new URIs mapped to that resource, which can then be used to access it. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-redirectref-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991221121605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-redirectref-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991221121605.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed Dec 22 07:11:06 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06396 for ; Wed, 22 Dec 1999 07:11:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA07619; Wed, 22 Dec 1999 07:00:21 -0500 (EST) Resent-Date: Wed, 22 Dec 1999 07:00:21 -0500 (EST) Resent-Message-Id: <199912221200.HAA07619@www19.w3.org> Message-Id: <199912221159.GAA06159@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 22 Dec 1999 06:59:59 -0500 Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-02.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3740 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Redirect Reference Resources Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford Filename : draft-ietf-webdav-redirectref-protocol-02.txt Pages : 26 Date : 21-Dec-99 This is one of a pair of specifications that extend the WebDAV Distributed Authoring Protocol to enable clients to create new access paths to existing resources. The two protocol extensions have very different characteristics that make them useful for different sorts of applications. The present specification defines redirect reference resources. A redirect reference resource is a resource whose default response is an HTTP/1.1 302 (Found) status code, redirecting the client to a different resource, the target resource. A redirect reference makes it possible to access the target resource indirectly, through any URI mapped to the redirect reference resource. There are no integrity guarantees associated with redirect reference resources. The related specification, RFC xxxx, defines bindings, and the BIND method for creating them. Creating a new binding to a resource indirectly creates one or more new URIs mapped to that resource, which can then be used to access it. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-redirectref-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991221121605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-redirectref-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991221121605.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed Dec 22 07:11:09 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06407 for ; Wed, 22 Dec 1999 07:11:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA07595; Wed, 22 Dec 1999 07:00:11 -0500 (EST) Resent-Date: Wed, 22 Dec 1999 07:00:11 -0500 (EST) Resent-Message-Id: <199912221200.HAA07595@www19.w3.org> Message-Id: <199912221159.GAA06073@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 22 Dec 1999 06:59:07 -0500 Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-02.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3738 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Ordered Collections Protocol Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford Filename : draft-ietf-webdav-ordering-protocol-02.txt Pages : 19 Date : 21-Dec-99 This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-ordering-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991221121554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-ordering-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991221121554.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed Dec 22 07:11:39 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06420 for ; Wed, 22 Dec 1999 07:11:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA07781; Wed, 22 Dec 1999 07:00:52 -0500 (EST) Resent-Date: Wed, 22 Dec 1999 07:00:52 -0500 (EST) Resent-Message-Id: <199912221200.HAA07781@www19.w3.org> Message-Id: <199912221200.HAA06188@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 22 Dec 1999 07:00:27 -0500 Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-02.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3741 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Ordered Collections Protocol Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford Filename : draft-ietf-webdav-ordering-protocol-02.txt Pages : 19 Date : 21-Dec-99 This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-ordering-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991221121554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-ordering-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991221121554.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed Dec 22 09:20:55 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11338 for ; Wed, 22 Dec 1999 09:20:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA10693; Wed, 22 Dec 1999 09:09:01 -0500 (EST) Resent-Date: Wed, 22 Dec 1999 09:09:01 -0500 (EST) Resent-Message-Id: <199912221409.JAA10693@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24545@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Internet-Drafts@ietf.org'" Cc: w3c-dist-auth@w3.org Date: Wed, 22 Dec 1999 09:08:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF4C86.0BC75850" Subject: RE: I-D ACTION:draft-ietf-webdav-binding-protocol-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3742 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF4C86.0BC75850 Content-Type: text/plain; charset="iso-8859-1" Cynthia -- Something must have gone wrong on this one, since draft-ietf-webdav-binding-protocol-01.txt is the old draft that should have been replaced. Here is a (duplicate) copy of the new one that I sent a few days ago. Best wishes for the holidays. --Judy > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, December 22, 1999 6:59 AM > Cc: w3c-dist-auth@w3.org > Subject: I-D ACTION:draft-ietf-webdav-binding-protocol-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the WWW Distributed Authoring > and Versioning Working Group of the IETF. > > Title : WebDAV Bindings > Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, > C. Fay, J. Crawford > > Filename : draft-ietf-webdav-binding-protocol-01.txt > Pages : 25 > Date : 21-Dec-99 > > The WebDAV Distributed Authoring Protocol provides basic support for > collections, offering the ability to create and list unordered > collections. > This specification is one of a group of three specifications that > supplement the WebDAV Distributed Authoring Protocol to increase the > power of WebDAV collections. This specification defines bindings, one > mechanism for allowing a single resource to appear in more than one > collection. Bindings make this possible by creating mappings > of URIs to > resources. The BIND method defined here gives clients the ability to > create new bindings to existing resources. The second specification, > 'WebDAV Redirect Reference Resources'[RR], defines redirect > references, > another approach to allowing a single resource to be accessed from > multiple collections. The third specification, 'WebDAV Ordered > Collections Protocol'[OC], provides a mechanism for ordering > collections. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-webdav-binding- protocol-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-binding-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-binding-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01BF4C86.0BC75850 Content-Type: text/plain; name="BindingSpec02.txt" Content-Disposition: attachment; filename="BindingSpec02.txt" Content-Transfer-Encoding: quoted-printable WEBDAV Working Group J. Slein, = Xerox INTERNET DRAFT E.J. Whitehead Jr., UC = Irvine J. Davis, = CourseNet G. Clemm, = Rational C. Fay, = FileNet J. Crawford, = IBM December 17, = 1999 Expires June 17, 2000 WebDAV Bindings Status of this Memo This document is an Internet-Draft and is in full conformance with all=20 provisions of Section 10 of RFC2026. Internet-Drafts are working=20 documents of the Internet Engineering Task Force (IETF), its areas, and = its working groups. Note that other groups may also distribute working=20 documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress". To view the list Internet-Draft Shadow Directories, see=20 http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the = Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with = subject=20 "subscribe" to . Discussions of the WEBDAV working group are archived at URL:=20 . Abstract This is one of a pair of specifications that extend the WebDAV=20 Distributed Authoring Protocol to enable clients to create new access=20 paths to existing resources. The two protocol extensions have very=20 different characteristics that make them useful for different sorts of=20 applications. =20 The present specification defines bindings, and the BIND method for=20 creating them. Creating a new binding to a resource indirectly creates = one or more new URIs mapped to that resource, which can then be used to = access it. Servers are required to insure the integrity of any = bindings=20 that they allow to be created. The related specification, RFC xxxx, defines redirect reference=20 resources. A redirect reference resource is a resource whose default=20 response is an HTTP/1.1 302 (Found) status code, redirecting the client = to a different resource, the target resource. A redirect reference=20 makes it possible to access the target resource indirectly, through any = URI mapped to the redirect reference resource. There are no integrity=20 guarantees associated with redirect reference resources. Slein et al. Page 1 =0CInternet-Draft WebDAV Bindings December = 1999 Table of Contents 1 Notational Conventions.......................................2 2 Introduction.................................................3 3 Terminology..................................................4 3.1 Rationale for Distinguishing Bindings from URI Mappings......7 4 Overview of Bindings.........................................8 5 BIND Method..................................................8 5.1 Overview of BIND.............................................8 5.2 Bindings to Collections......................................9 5.3 URI Mappings Created by a BIND..............................10 5.4 Example: URI Mappings Created by a BIND.....................11 5.5 BIND Status Codes...........................................11 5.6 Example: BIND...............................................11 6 DELETE and Bindings.........................................12 7 COPY and Bindings...........................................12 8 MOVE and Bindings...........................................13 9 Bindings and Other Methods..................................14 10 Determining Whether Two Bindings Are to the Same Resource...14 10.1 resourceid URI Scheme.......................................15 11 Discovering the Bindings to a Resource......................15 12 Status Codes................................................16 12.1 506 Loop Detected...........................................16 12.2 507 Cross-Server Binding Forbidden..........................17 13 Properties..................................................17 13.1 bindings Property...........................................17 13.2 resourceid Property.........................................18 14 XML Elements................................................18 14.1 segment XML Element.........................................18 15 Capability Discovery........................................18 15.1 Example: Discovery of Support for Bindings..................18 16 Security Considerations.....................................19 16.1 Privacy Concerns............................................19 16.2 Redirect Loops..............................................19 16.3 Bindings, and Denial of Service.............................19 16.4 Private Locations May Be Revealed...........................20 16.5 DAV:bindings and Denial of Service..........................20 17 Internationalization Considerations.........................20 18 IANA Considerations.........................................20 19 Copyright...................................................21 20 Intellectual Property.......................................21 21 Acknowledgements............................................21 22 References..................................................21 23 Authors' Addresses..........................................22 24 Appendices..................................................22 24.1 Appendix 1: Extensions to the WebDAV Document Type=20 Definition..................................................22 1 Notational Conventions Since this document describes a set of extensions to the WebDAV=20 Distributed Authoring Protocol [WebDAV], itself an extension to the=20 HTTP/1.1 protocol, the augmented BNF used here to describe protocol=20 elements is exactly the same as described in Section 2.1 of [HTTP]. =20 Slein et al. Page 2 =0CInternet-Draft WebDAV Bindings December = 1999 Since this augmented BNF uses the basic production rules provided in=20 Section 2.2 of [HTTP], these rules apply to this document as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in [RFC2119]. 2 Introduction This is one of a pair of specifications that extend the WebDAV=20 Distributed Authoring Protocol to enable clients to create new access=20 paths to existing resources. This capability is useful for several=20 reasons: URIs of WebDAV-compliant resources are hierarchical and correspond to a = hierarchy of collections in resource space. The WebDAV Distributed=20 Authoring Protocol makes it possible to organize these resources into=20 hierarchies, placing them into groupings, known as collections, which=20 are more easily browsed and manipulated than a single flat collection. = However, hierarchies require categorization decisions that locate=20 resources at a single location in the hierarchy, a drawback when a=20 resource has multiple valid categories. For example, in a hierarchy of=20 vehicle descriptions containing collections for cars and boats, a=20 description of a combination car/boat vehicle could belong in either=20 collection. Ideally, the description should be accessible from both.=20 Allowing clients to create new URIs that access the existing resource=20 lets them put that resource into multiple collections. Hierarchies also make resource sharing more difficult, since resources=20 that have utility across many collections are still forced into a = single=20 collection. For example, the mathematics department at one university=20 might create a collection of information on fractals that contains=20 bindings to some local resources, but also provides access to some=20 resources at other universities. For many reasons, it may be=20 undesirable to make physical copies of the shared resources on the = local=20 server: to conserve disk space, to respect copyright constraints, or to = make any changes in the shared resources visible automatically. Being=20 able to create new access paths to existing resources in other=20 collections or even on other servers is useful for this sort of case. The BIND method defined here provides a mechanism for allowing clients=20 to create alternative access paths to existing WebDAV resources. HTTP=20 and WebDAV methods are able to work because there are mappings between=20 URIs and resources. A method is addressed to a URI, and the server=20 follows the mapping from that URI to a resource, applying the method to = that resource. Multiple URIs may be mapped to the same resource, but=20 until now there has been no way for clients to create additional URIs=20 mapped to existing resources. =20 BIND lets clients associate a new URI with an existing WebDAV resource, = and this URI can then be used to submit requests to the resource. = Since=20 URIs of WebDAV resources are hierarchical, and correspond to a = hierarchy=20 of collections in resource space, the BIND method also has the effect = of=20 adding the resource to a collection. As new URIs are associated with=20 the resource, it appears in additional collections. Slein et al. Page 3 =0CInternet-Draft WebDAV Bindings December = 1999 The companion specification, RFC xxxx, defines redirect reference=20 resources, a different mechanism for creating alternative access paths=20 to existing resources. A redirect reference is a resource in one=20 collection whose purpose is to forward requests to another resource = (its=20 target), usually in a different collection. In this way, it provides=20 access to the target resource from another collection. It redirects=20 most requests to the target resource using the HTTP 302 (Moved=20 Temporarily) status code, thereby providing a form of mediated access = to=20 the target resource. Bindings and redirect reference resources have very different=20 characteristics: A BIND request does not create a new resource, but simply makes=20 available a new URI for submitting requests to an existing resource. =20 The new URI is indistinguishable from any other URI when submitting a=20 request to a resource. Only one round trip is needed to submit a=20 request to the intended target. Servers are required to enforce the=20 integrity of the relationships between the new URIs and the resources=20 associated with them. Consequently, it may be very costly for servers=20 to support BIND requests that cross server boundaries. A redirect reference is a resource, and so can have properties of its=20 own. Properties of the redirect reference can contain such information = as who created the reference, when, and why. Since redirect references = are implemented using HTTP 302 responses, it generally takes two round=20 trips to submit a request to the intended resource. Servers are not=20 required to enforce the integrity of redirect references. Redirect=20 references work equally well for local resources and for resources that = reside on a different server from the reference. The remainder of this specification is organized as follows. Section 3 = defines terminology used in the rest of the specification, while = Section=20 4 briefly overviews bindings. Section 5 specifies the BIND method, = used=20 to create bindings. Sections 6 through 9 discuss the relationships=20 between bindings and other HTTP and WebDAV methods. Sections 10 and 11 = define mechanisms for tracking bindings. Sections 12 through 14 define = the new status codes, properties, and XML elements needed to support=20 bindings. Section 15 discusses compliance and capability discovery. =20 Security concerns, internationalization issues, and IANA considerations = are described in Sections 16 through 18. The remaining sections = provide=20 other supporting information. 3 Terminology The terminology used here follows and extends that in the WebDAV=20 Distributed Authoring Protocol specification [WebDAV]. Definitions of=20 the terms resource, Uniform Resource Identifier (URI), and Uniform=20 Resource Locator (URL) are provided in [URI]. URI Mapping A relation between an absolute URI and a resource. For an=20 absolute URI U and the resource it identifies R, the URI mapping=20 can be thought of as (U =3D> R). Since a resource can represent=20 Slein et al. Page 4 =0CInternet-Draft WebDAV Bindings December = 1999 items that are not network retrievable, as well as those that are, = it is possible for a resource to have zero, one, or many URI=20 mappings. Mapping a resource to an "http" scheme URL makes it=20 possible to submit HTTP protocol requests to the resource using=20 the URL. Path Segment Informally, the characters found between slashes ("/") in a URI. =20 Formally, as defined in section 3.3 of [URI]. Binding A relation between a single path segment (in a collection) and a=20 resource. A binding is part of the state of a collection. If two = different collections contain a binding between the same path=20 segment and the same resource, these are two distinct bindings. =20 So for a collection C, a path segment S, and a resource R, the=20 binding can be thought of as C:(S -> R). Bindings create URI=20 mappings, and hence allow requests to be sent to a single resource = from multiple locations in a URI namespace. For example, given=20 o collection C, accessible through the URI=20 http://www.srv.com/coll/,=20 o path segment S, equal to "foo.html", and=20 o resource R,=20 creating the binding C: (S -> R) makes it possible to use the URI=20 http://www.srv.com/coll/foo.html to access R. The following figure illustrates a more complex example of how=20 bindings create URI mappings. +-----------------------------+ | root collection | |-----------------------------| | bindings: | | | | Coll1 Coll2 Coll3 | | | | \ | +---|-------|--------\--------+ | | \ | | \ +-------------------+ +----------------------+ | collection C1 | | collection C2 | |-------------------| |----------------------| | bindings: | | bindings: | | | | | | foo bar | | foo | | | \ | | / | +--|------\---------+ +-/--------------------+ | \ / | \ / | \ / | \ / +--------------+ +---------------+ | resource R1 | | resource R2 | Slein et al. Page 5 =0CInternet-Draft WebDAV Bindings December = 1999 +--------------+ +---------------+ Figure 1 Since there are two bindings in the root collection, Coll1 and=20 Coll2, to collection C1, the single binding C1:(foo -> R1) between = foo and resource R1 in collection C1 creates two URI mappings,=20 /Coll1/foo and /Coll2/foo, to resource R1. Each of these URI=20 mappings can be used to submit requests to R1. The binding=20 C1:(bar -> R2) between bar and resource R2 in collection C1 and=20 the binding C2:(foo -> R2) between foo and resource R2 in=20 collection C2 create altogether 3 URI mappings to resource R2:=20 /Coll1/bar, /Coll2/bar, and /Coll3/foo. All 3 URI mappings can be = used to submit requests to resource R2. =20 =20 Collection A resource that contains, as part of its state, a set of bindings=20 that identify member resources. Internal Member URI Informally, the complete set of URLs by which a collection member=20 is known. Formally, the URI U of a URI mapping (U =3D> R), created = by a binding that is contained in a collection. The following=20 figure illustrates the relationship between bindings and internal=20 member URIs in a collection: +-----------------------------+ | root collection | |-----------------------------| | internal member URIs: | | | | /Coll1/ | | /Coll2/ | | /Coll3/ | |-----------------------------| | bindings: | | | | Coll1 Coll2 Coll3 | | | | \ | +---|-------|--------\--------+ | | \ | | \ +----------------------+ +----------------------+ | collection C1 | | collection C2 | |----------------------| |----------------------| | internal member URIs:| | internal member URIs:| | | | | | /Coll1/foo | | /Coll3/foo | | /Coll2/foo | |----------------------| | /Coll1/bar | | bindings: | | /Coll2/bar | | | |----------------------| | foo | | bindings: | | / | | | +-/--------------------+ | foo bar | / Slein et al. Page 6 =0CInternet-Draft WebDAV Bindings December = 1999 | | \ | / +--|------\------------+ / | \ / | \ / | \ / | \ / +--------------+ +---------------+ | resource R1 | | resource R2 | +--------------+ +---------------+ Figure 2 The URIs of all URI mappings created by a collection's bindings=20 are internal member URIs of the collection. =20 However, for a given request, only the URIs from those URI=20 mappings that incorporate the Request-URI are treated as internal=20 member URIs. This is done to prevent large amounts of duplicate=20 information from being returned for operations on collections. =20 The problem would occur if a PROPFIND on a collection to which=20 there are multiple URI mappings returned information for every URI = mapping. For example, in Figure 2 above, if a PROPFIND request with "Depth: = infinity" is submitted to collection C1 using the Request-URI=20 /Coll1/, only the URI mappings starting with the Request-URI would = be listed as internal member URIs. The response would include=20 only /Coll1/ itself and the internal member URIs /Coll1/foo and=20 /Coll1/bar. It would not include /Coll2/, /Coll2/foo, or=20 /Coll2/bar, even though the URI /Coll2/ does map to the=20 collection, and /Coll2/foo and /Coll2/bar are internal member URIs = of the collection. In [WebDAV], a collection is defined as containing a list of=20 internal member URIs, where an internal member URI is the URI of=20 the collection, plus a single path segment. This definition=20 combines the two concepts of binding and URI mapping that are=20 separated in this specification. As a result, this specification=20 redefines a collection's state to be a set of bindings, and=20 redefines an internal member URI to be the URI of a URI mapping=20 derived from a binding. After this redefinition, an internal=20 member URI can be used when reading [WebDAV] without loss of=20 meaning. For purposes of interpretation, when [WebDAV] discusses a = collection "containing" an internal member URI, this should be=20 read as the collection containing a binding whose mapping to a URI = creates an internal member URI, in this sense "containing" the=20 internal member URI. The authors of this specification anticipate = and recommend that future revisions of [WebDAV] perform a full=20 reconciliation of terms between these two specifications. 3.1 Rationale for Distinguishing Bindings from URI Mappings Consider again collection C1 in Figure 2. If we had only the notion of = URI mappings, we would be forced to say that C1's membership was = defined=20 by the list of internal member URIs. If these URIs identify the=20 Slein et al. Page 7 =0CInternet-Draft WebDAV Bindings December = 1999 membership, and are part of the state of the collection, then the act = of=20 making the collection available via a new URI has the effect of = changing=20 the collection's membership, hence changing the collection's state. = This=20 is undesirable, since ideally a collection's membership should remain=20 the same, if suddenly a new URI can be used to access the collection.=20 What is needed is a way to separate the final segment of a URI from the = collection's URI contribution. The notion of binding is introduced to separate the final segment of a=20 URI from its parent collection=92s contribution. This done, a = collection=20 can be defined as containing a set of bindings, thus permitting new=20 mappings to a collection without modifying its membership. We introduce = the concept of URI mapping to combine together the collection's URI and = a binding's segment to create a full URI that can be used in protocol=20 requests. Finally, the internal member URI, first defined in [WebDAV], = is redefined here to maintain backward compatibility with that=20 specification. 4 Overview of Bindings Bindings are part of the state of a collection. In general, there is a=20 one-to-many correspondence between a collection's bindings and its=20 internal member URIs, as illustrated in Figure 2 above. The URI = segment=20 associated with a resource by one of a collection's bindings is also = the=20 final segment of one or more of the collection's internal member URIs. = The final segment of each internal member URI identifies one of the=20 bindings that is part of the collection's state. Bindings are not unique to advanced collections, although the BIND=20 method for explicitly creating bindings is introduced here. Existing=20 methods that create resources, such as PUT, MOVE, COPY, and MKCOL,=20 implicitly create bindings. There is no difference between implicitly=20 created bindings and bindings created with BIND. The identity of a binding C:(S -> R) is determined by the URI segment=20 (in its collection) and the resource that the binding associates. If=20 the resource goes out of existence (as a result of some out-of-band=20 operation), the binding also goes out of existence. If the URI segment = comes to be associated with a different resource, the original binding=20 ceases to exist and another binding is created. It would be very undesirable if one binding could be destroyed as a = side=20 effect of operating on the resource through a different binding. It is = not acceptable for moving a resource through one binding to disrupt=20 another binding, turning that binding into a dangling path segment. = Nor=20 is it acceptable for a server, after removing one binding, to reclaim=20 the system resources associated with its resource while other bindings=20 to the resource remain. Implementations MUST ensure the integrity of=20 bindings. 5 BIND Method 5.1 Overview of BIND The BIND method creates a new binding between the resource identified = by=20 Slein et al. Page 8 =0CInternet-Draft WebDAV Bindings December = 1999 the Request-URI and the final segment of the Destination header (minus=20 any trailing slash). This binding is added to the collection = identified=20 by the Destination header minus its trailing slash (if present) and=20 final segment. The Destination header is defined in Section 9.3 of=20 [WebDAV]. If a server cannot guarantee the binding behavior specified here,=20 including the guarantee of the integrity of the binding, the BIND=20 request MUST fail. Note: It is especially difficult to maintain the integrity of cross- server bindings. Unless the server where the resource resides knows=20 about all bindings on all servers to that resource, it may unwittingly=20 destroy the resource or move it without notifying another server that=20 manages a binding to the resource. For example, if server A permits=20 creation of a binding to a resource on server B, server A must notify=20 server B about its binding and must have an agreement with B that B = will=20 not destroy the resource while A's binding exists. Otherwise server B=20 may receive a DELETE request that it thinks removes the last binding to = the resource and destroy the resource while A's binding still exists.=20 Status code 507 (Cross-server Binding Forbidden) is defined in Section=20 12.2 for cases where servers must fail cross-server BIND requests=20 because they cannot guarantee the integrity of cross-server bindings. If the Destination header does not contain a path segment (i.e., it=20 consists simply of a slash "/"), the BIND operation MUST fail and = report=20 a 400 (Bad Request) status code. A binding consists of a (collection,=20 segment, resource) triple, and the Destination header is required to=20 specify the collection and segment of this triple. =20 If the Destination header minus its final path segment does not = identify=20 a collection, the BIND operation MUST fail and report a 400 (Bad=20 Request) status code. Note: Section 5.1 of [WebDAV] defines a consistent namespace to be one=20 such that "for every URL in the HTTP hierarchy there exists a = collection=20 that contains that URL as an internal member," but [WebDAV] does not=20 require namespaces to be consistent. There can exist URIs that map to=20 resources, but do not depend on the existence of collections for the=20 mapping. For example, the URI http://www.svr.com/x/y.html may map to=20 resource R even if the URI http://www.svr.com/x/ does not map to any=20 resource. This specification does not support the creation of such URI = mappings. The BIND method can be used only in consistent sections of a = namespace. After successful processing of a BIND request, it MUST be possible for=20 clients to use the URI in the Destination header to submit requests to=20 the resource identified by the Request-URI. By default, if the Destination header identifies an existing binding,=20 the new binding replaces the existing binding. This default binding=20 replacement behavior can be overridden using the Overwrite header=20 defined in Section 9.6 of [WebDAV].=20 5.2 Bindings to Collections Slein et al. Page 9 =0CInternet-Draft WebDAV Bindings December = 1999 Bindings to collections can result in loops. If a server wants to=20 prevent a loop from being created, it MAY fail the BIND request with a=20 403 (Forbidden) status code. If a server allows a loop to be created,=20 it MUST detect the loop when processing "Depth: infinity" requests that = encounter the loop. It is sometimes possible to complete an operation=20 in spite of the presence of a loop. However, the 506 (Loop Detected)=20 status code is defined in Section 12.1 for use in contexts where an=20 operation is terminated because a loop was encountered. =20 Creating a new binding to a collection makes each resource associated=20 with a binding in that collection accessible via a new URI, and thus=20 creates new URI mappings to those resources but no new bindings. For example, suppose a new binding COLLX is created for collection C1 = in=20 the figure below. It immediately becomes possible to access resource = R1=20 using the URI /COLLX/x.gif and to access resource R2 using the URI=20 /COLLX/y.jpg, but no new bindings for these child resources were=20 created. This is because bindings are part of the state of a=20 collection, and associate a URI that is relative to that collection = with=20 its target resource. No change to the bindings in Collection C1 is=20 needed to make its children accessible using /COLLX/x.gif and=20 /COLLX/y.jpg. +-------------------------+ | Root Collection | | (properties) | | bindings: | | coll1 COLLX | +-------------------------+ | / =20 | /=20 | /=20 +------------------+ =20 | Collection C1 | =20 | (properties) | =20 | bindings: | | x.gif y.jpg | =20 +------------------+ =20 | \ =20 | \ =20 | \ =20 +-------------+ +-------------+ | Resource R1 | | Resource R2 | +-------------+ +-------------+=20 Figure 3 5.3 URI Mappings Created by a BIND Suppose a BIND request causes a binding from "Binding-Name" to resource = R to be added to a collection, C. Then if C-MAP is the set of URI's=20 that were mapped to C before the BIND request, then for each URI = "C-URI"=20 in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R = following=20 the BIND request. Slein et al. Page 10 =0CInternet-Draft WebDAV Bindings December = 1999 Note that if R is a collection, additional URI mappings are created to=20 the descendents of R. Also note that if a binding is made in = collection=20 C to C itself (or to a parent of C), an infinite number of mappings is=20 introduced. 5.4 Example: URI Mappings Created by a BIND For example, if a binding from "foo.html" to R is added to a collection = C, and if the following URI's are mapped to C: http://www.fuzz.com/A/1 http://fuzz.com/A/one then the following new mappings to R are introduced: http://www.fuzz.com/A/1/foo.html http://fuzz.com/A/one/foo.html If a binding from "myself" to C is then added to C, the following=20 infinite number of additional mappings to C are introduced: http://www.fuzz.com/A/1/myself http://www.fuzz.com/A/1/myself/myself ... and the following infinite number of additional mappings to R are=20 introduced: http://www.fuzz.com/A/1/myself/foo.html http://www.fuzz.com/A/1/myself/myself/foo.html ... 5.5 BIND Status Codes 201 (Created): The binding was successfully created. 400 (Bad Request): The client set an invalid value for the Destination=20 header or Request-URI. 403 (Forbidden): This server has a policy that forbids creation of=20 bindings that would result in loops. 412 (Precondition Failed): The Overwrite header is "F", and a binding=20 already exists for the Destination header. 507 (Cross-Server Binding Forbidden): The server is unable to create = the=20 requested binding because it would bind a segment in a collection on = one=20 server to a resource on a different server. 5.6 Example: BIND=20 >> Request: BIND /pub/i-d/draft-webdav-protocol-08.txt HTTP/1.1 Slein et al. Page 11 =0CInternet-Draft WebDAV Bindings December = 1999 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/~whitehead/dav/spec08.txt >> Response: HTTP/1.1 201 Created The server created a new binding, associating "spec08.txt" with the=20 resource identified by the URL "http://www.ics.uci.edu/pub/i-d/draft- webdav-protocol-08.txt". Clients can now use the URI in the = Destination=20 header, "http://www.ics.uci.edu/~whitehead/dav/spec08.txt", to submit=20 requests to that resource. As part of this operation, the server added = the binding "spec08.txt" to collection /~whitehead/dav/. 6 DELETE and Bindings The DELETE method was originally defined in [HTTP]. This section=20 redefines the behavior of DELETE in terms of bindings, an abstraction=20 not available when writing [HTTP]. [HTTP] states that "the DELETE = method=20 requests that the origin server delete the resource identified by the=20 Request-URI." Because [HTTP] did not distinguish between bindings and=20 resources, the intent of its definition of DELETE is unclear. The=20 definition presented here is a clarification of the definition in=20 [HTTP]. The DELETE method requests that the server remove the binding between=20 the resource identified by the Request-URI and the binding name, the=20 last path segment of the Request-URI. The binding MUST be removed from=20 its parent collection, identified by the Request-URI minus its trailing = slash (if present) and final segment.=20 Once a resource is unreachable by any URI mapping, the server MAY=20 reclaim system resources associated with that resource. If DELETE=20 removes a binding to a resource, but there remain URI mappings to that=20 resource, the server MUST NOT reclaim system resources associated with=20 the resource. Although [WebDAV] allows a DELETE to be a non-atomic operation, the=20 DELETE operation defined here is atomic. In particular, a DELETE on a=20 hierarchy of resources is simply the removal of a binding to the=20 collection identified by the Request-URI, and so is a single (and=20 therefore atomic) operation.=20 Section 8.6.1 of [WebDAV] states that during DELETE processing, a = server=20 "MUST remove any URI for the resource identified by the Request-URI = from=20 collections which contain it as a member." Servers that support=20 bindings MUST NOT follow this requirement. 7 COPY and Bindings As defined in Section 8.8 of [WebDAV], COPY causes the resource=20 identified by the Request-URI to be duplicated, and makes the new=20 resource accessible using the URI specified in the Destination header. = Upon successful completion of a COPY, a new binding is created between=20 the last path segment of the Destination header, and the destination=20 Slein et al. Page 12 =0CInternet-Draft WebDAV Bindings December = 1999 resource. The new binding is added to its parent collection, identified = by the Destination header minus its trailing slash (if present) and=20 final segment. Figure 4 below shows an example: Suppose that a COPY is issued to URI 3 = for resource R (which is also mapped to URI 1 and URI 2), with the=20 Destination header set to URIX. After successful completion of the = COPY=20 operation, resource R is duplicated to create resource R', and a new=20 binding has been created which creates at least the URI mapping between = URIX and the new resource (although other URI mappings may also have=20 been created). URI 1 URI 2 URI 3 URIX | | | | | | | <---- URI Mappings ----> | | | | | +---------------------+ +------------------------+ | Resource R | | Resource R' | +---------------------+ +------------------------+ Figure 4 It might be thought that a COPY request with "Depth: 0" on a collection = would duplicate its bindings, since bindings are part of the=20 collection's state. This is not the case, however. The definition of=20 Depth in [WebDAV] makes it clear that a "Depth: 0" request does not=20 apply to a collection's members. Consequently, a COPY with "Depth: 0"=20 does not duplicate the bindings contained by the collection. 8 MOVE and Bindings The MOVE method has the effect of creating a new binding to a resource=20 (at the Destination), and removing an existing binding (at the Request- URI). The name of the new binding is the last path segment of the=20 Destination header, and the new binding is added to its parent=20 collection, identified by the Destination header minus its trailing=20 slash (if present) and final segment. =20 As an example, suppose that a MOVE is issued to URI 3 for resource R=20 below (which is also mapped to URI 1 and URI 2), with the Destination=20 header set to URIX. After successful completion of the MOVE operation, = a new binding has been created which creates at least the URI mapping=20 between URIX and resource R (although other URI mappings may also have=20 been created). The binding corresponding to the final segment of URI 3 = has been removed, which also causes the URI mapping between URI 3 and R = to be removed. >> Before Request: URI 1 URI 2 URI 3 | | | =20 | | | <---- URI Mappings | | | +---------------------+ =20 | Resource R | Slein et al. Page 13 =0CInternet-Draft WebDAV Bindings December = 1999 +---------------------+ =20 >> After Request: URI 1 URI 2 URIX | | | =20 | | | <---- URI Mappings | | | +---------------------+ =20 | Resource R | +---------------------+ =20 Figure 5 Although [WebDAV] allows a MOVE on a collection to be a non-atomic=20 operation, the MOVE operation defined here MUST be atomic. Even when=20 the Request-URI identifies a collection, the MOVE operation involves=20 only removing one binding to that collection and adding another. There = are no operations on bindings to any of its children, so the case of=20 MOVE on a collection is the same as the case of MOVE on a = non-collection=20 resource. Both are atomic. 9 Bindings and Other Methods This section describes the interaction of bindings with those HTTP=20 methods not yet explicitly discussed. The semantics of the methods = GET,=20 HEAD, PUT, POST and OPTIONS are specified in [HTTP]. The semantics of=20 PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV]. For these methods, no new complexities are introduced by allowing=20 explicit creation of multiple bindings to the same resource. When=20 applied to static resources (that is, resources that are not CGI=20 scripts, Active Server Pages, etc.), they obey the following rule:=20 o A method submitted through one URI mapping, on success, MUST produce=20 the same results as the same method, with the same headers and entity = body, submitted through any other URI mapping to the same resource. When applied to dynamic resources, it is not possible to state any such = rule. For any method, a dynamic resource may be sensitive to the URI=20 mapping used to access it. The resource may produce different results=20 depending upon which URI mapping was used to submit the request. Nevertheless, servers MAY allow new bindings to dynamic resources to be = created using BIND. 10 Determining Whether Two Bindings Are to the Same Resource It is useful to have some way of determining whether two bindings are = to=20 the same resource. Two different resources might have identical=20 contents and identical values for the properties defined in [WebDAV]. =20 Although the DAV:bindings property defined in Section 13.1 provides = this=20 information, it is an optional property. The REQUIRED DAV:resourceid property defined in Section 13.2 is a=20 Slein et al. Page 14 =0CInternet-Draft WebDAV Bindings December = 1999 resource identifier, which MUST be unique across all resources for all=20 time. If the values of DAV:resourceid returned by PROPFIND requests=20 through two bindings are identical, the client can be assured that the=20 two bindings are to the same resource. The DAV:resourceid property is created, and its value assigned, when = the=20 resource is created. The value of DAV:resourceid MUST NOT be changed. = Even after the resource is no longer accessible through any URI, that=20 value MUST NOT be reassigned to another resource's DAV:resourceid=20 property. Any method that creates a new resource MUST assign a new, unique value=20 to its DAV:resourceid property. For example, a PUT that creates a new=20 resource must assign a new, unique value to its DAV:resourceid = property. =20 A COPY, since it creates a new resource at the Destination URI, must=20 assign a new, unique value to its DAV:resourceid property. On the other hand, any method that affects an existing resource MUST = NOT=20 change the value of its DAV:resourceid property. For example, a PUT=20 that updates an existing resource must not change the value of its=20 DAV:resourceid property. A MOVE, since it does not create a new=20 resource, but only changes the location of an existing resource, must=20 not change the value of its DAV:resourceid property. 10.1 resourceid URI Scheme The value of DAV:resourceid is a URI and may use any URI scheme that=20 guarantees the uniqueness of the value across all resources for all=20 time. The resourceid URI scheme defined here is an example of an=20 acceptable URI scheme. The resourceid URI scheme requires the use of the Universal Unique=20 Identifier (UUID) mechanism, as described in [ISO-11578]. UUID=20 generators may choose between two methods of creating the identifiers. = They can either generate a new UUID for every identifier they create or = they can create a single UUID and then add extension characters. If = the=20 second method is selected, then the program generating the extensions=20 MUST guarantee that the same extension will never be used twice with = the=20 associated UUID. resourceid-URI =3D "resourceid:" UUID [Extension] ; The UUID production = is=20 the string representation of a UUID, as defined in [ISO-11578]. Note=20 that white space (LWS) is not allowed between elements of this=20 production. Extension =3D path ; path is defined in Section 3.3 of [URI]. 11 Discovering the Bindings to a Resource An OPTIONAL DAV:bindings property on a resource provides a list of the=20 bindings that associate URI segments with that resource. If the=20 DAV:bindings property exists on a given resource, it MUST contain a=20 complete list of all bindings to that resource. A PROPFIND requesting=20 DAV:bindings MUST return only those bindings that the client is=20 authorized to see. By retrieving this property, a client can discover=20 Slein et al. Page 15 =0CInternet-Draft WebDAV Bindings December = 1999 the bindings that point to the resource and the collections that = contain=20 bindings to the resource. =20 Rationale: A number of scenarios require clients to navigate from a=20 resource to the bindings that point to it, and to the collections that=20 contain those bindings. This capability is particularly important for=20 Document Management Systems. Their clients may need to determine, for=20 any object in the DMS, what collections contain bindings to that = object. =20 This information can be used for upward navigation through a hierarchy=20 or to discover related documents in other collections. Risks: When deciding whether to support the DAV:bindings property,=20 server implementers / administrators should balance the benefits it=20 provides against the cost of maintaining the property and the security=20 risks enumerated in Sections 16.4 and 16.5. 12 Status Codes 12.1 506 Loop Detected The 506 (Loop Detected) status code indicates that the server = terminated=20 an operation because it encountered an infinite loop while processing a = request with "Depth: infinity".=20 When this status code is the top-level status code for the operation, = it=20 indicates that the entire operation failed. =20 When this status code occurs inside a multistatus response, it = indicates=20 only that a loop is being terminated, but does not indicate failure of=20 the operation as a whole. For example, consider a PROPFIND request on the following collection: Coll-1 (bound to collection C) Foo (bound to resource R) Bar (bound to collection C) >> Request: PROPFIND /Coll-1/ HTTP/1.1 Host: www.somehost.com Depth: infinity Content-Type: text/xml; charset=3D"utf-8" Content-Length: xxx >> Response: HTTP/1.1 207 Multi-Status Slein et al. Page 16 =0CInternet-Draft WebDAV Bindings December = 1999 Content-Type: text/xml; charset=3D"utf-8" Content-Length: xxx http://www.somehost.com/Coll-1/ Loop Demo HTTP/1.1 200 OK http://www.somehost.com/Coll-1/Foo Bird Inventory HTTP/1.1 200 OK http://www.somehost.com/Coll-1/Bar HTTP/1.1 506 Loop Detected 12.2 507 Cross-Server Binding Forbidden The server is unable to create the requested binding because it would=20 bind a segment in a collection on one server to a resource on a=20 different server. 13 Properties 13.1 bindings Property Name: bindings Namespace: DAV: Purpose: Enables clients to discover, for any resource, what = bindings point to it and what collections contain those bindings. =20 This is an optional property. If present on a given=20 resource, it is a read-only property, maintained by the=20 server, and contains a complete list of all bindings to = that resource. Value: List of href / segment pairs for all of the bindings that=20 associate URI segments with the resource. The href is an=20 absolute URI for one URI mapping of the collection=20 Slein et al. Page 17 =0CInternet-Draft WebDAV Bindings December = 1999 containing the binding. Since there may be multiple URI=20 mappings for this collection, it is necessary to select one = (preferably the URI mapping contained in the Request-URI of = the BIND request) for use in the DAV:bindings property. The = segment is the URI segment that identifies the binding=20 within that collection.=20 13.2 resourceid Property Name: resourceid Namespace: DAV: Purpose: Enables clients to determine whether two bindings are for = =20 the same resource. Value: URI that is guaranteed unique across all resources for all=20 time. It may be of the resourceid URI scheme =20 defined in Section 10.1 or any other URI scheme that=20 guarantees this uniqueness. 14 XML Elements 14.1 segment XML Element Name: segment Namespace: DAV: Purpose: The segment that names a binding, used in the DAV:bindings=20 property. Value: segment ; as defined in section 3.3 of [URI]. 15 Capability Discovery Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes=20 with the DAV header in responses to OPTIONS, to indicate which parts of = the WebDAV Distributed Authoring protocol the resource supports. This=20 specification defines an OPTIONAL extension to [WebDAV]. It defines a=20 new compliance class, called bindings, for use with the DAV header in=20 responses to OPTIONS requests. If a resource does support bindings, = its=20 response to an OPTIONS request may indicate that it does, by listing = the=20 new BIND method as one it supports, and by listing the new bindings=20 compliance class in the DAV header. When responding to an OPTIONS request, any type of resource can include = bindings in the value of the DAV header. Doing so indicates that the=20 server permits a binding at the request URI. 15.1 Example: Discovery of Support for Bindings >> Request: OPTIONS /somecollection/someresource HTTP/1.1 Slein et al. Page 18 =0CInternet-Draft WebDAV Bindings December = 1999 HOST: somehost.org >> Response: HTTP/1.1 200 OK Date: Tue, 20 Jan 1998 20:52:29 GMT Connection: close Accept-Ranges: none Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, = PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, = MKCOL,=20 PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH DAV: 1, 2, bindings The DAV header in the response indicates that the resource=20 /somecollection/someresource is level 1 and level 2 compliant, as=20 defined in [WebDAV]. In addition, /somecollection/someresource = supports=20 bindings. The Allow header indicates that BIND requests can be=20 submitted to /somecollection/someresource. The Public header shows = that=20 other Request-URIs on the server support additional methods. 16 Security Considerations This section is provided to make WebDAV applications aware of the=20 security implications of this protocol.=20 All of the security considerations of HTTP/1.1 and the WebDAV=20 Distributed Authoring Protocol specification also apply to this = protocol=20 specification. In addition, bindings introduce several new security=20 concerns and increase the risk of some existing threats. These issues=20 are detailed below. 16.1 Privacy Concerns In a context where cross-server bindings are supported, creating=20 bindings on a trusted server may make it possible for a hostile agent = to=20 induce users to send private information to a target on a different=20 server. 16.2 Redirect Loops Although redirect loops were already possible in HTTP 1.1, the=20 introduction of the BIND method creates a new avenue for clients to=20 create loops accidentally or maliciously. If the binding and its = target=20 are on the same server, the server may be able to detect BIND requests=20 that would create loops. Servers are required to detect loops that are = caused by bindings to collections during the processing of any requests = with "Depth: infinity". 16.3 Bindings, and Denial of Service Denial of service attacks were already possible by posting URLs that=20 were intended for limited use at heavily used Web sites. The=20 introduction of BIND creates a new avenue for similar denial of service = attacks. If cross-server bindings are supported, clients can now = create=20 Slein et al. Page 19 =0CInternet-Draft WebDAV Bindings December = 1999 bindings at heavily used sites to target locations that were not=20 designed for heavy usage. 16.4 Private Locations May Be Revealed If the DAV:bindings property is maintained on a resource, the owners of = the bindings risk revealing private locations. The directory = structures=20 where bindings are located are available to anyone who has access to = the=20 DAV:bindings property on the resource. Moving a binding may reveal its = new location to anyone with access to DAV:bindings on its resource. 16.5 DAV:bindings and Denial of Service If the server maintains the DAV:bindings property in response to=20 bindings created in other administrative domains, it is exposed to=20 hostile attempts to make it devote resources to adding bindings to the=20 list. 17 Internationalization Considerations This specification follows the practices of [WebDAV] in encoding all=20 human-readable content using XML [XML] and in the treatment of names. =20 Consequently, this specification complies with the IETF Character Set=20 Policy [RFC2277]. WebDAV applications MUST support the character set tagging, character=20 set encoding, and the language tagging functionality of the XML=20 specification. This constraint ensures that the human-readable content = of this specification complies with [RFC2277]. As in [WebDAV], names in this specification fall into three categories: = names of protocol elements such as methods and headers, names of XML=20 elements, and names of properties. Naming of protocol elements follows = the precedent of HTTP, using English names encoded in USASCII for=20 methods and headers. The names of XML elements used in this=20 specification are English names encoded in UTF-8. For error reporting, [WebDAV] follows the convention of HTTP/1.1 status = codes, including with each status code a short, English description of=20 the code (e.g., 423 Locked). Internationalized applications will = ignore=20 this message, and display an appropriate message in the user's language = and character set. This specification introduces no new strings that are displayed to = users=20 as part of normal, error-free operation of the protocol. =20 For rationales for these decisions and advice for application=20 implementors, see [WebDAV]. 18 IANA Considerations This document uses the namespaces defined by [WebDAV] for properties = and=20 XML elements. All other IANA considerations mentioned in [WebDAV] also = apply to this document. Slein et al. Page 20 =0CInternet-Draft WebDAV Bindings December = 1999 In addition, this document defines the new resourceid URI Scheme in=20 Section 10.1 and the new HTTP/1.1 status codes 506 and 507in Section = 12. 19 Copyright To be supplied by the RFC Editor. 20 Intellectual Property To be supplied by the RFC Editor. 21 Acknowledgements This draft has benefited from thoughtful discussion by Jim Amsden, = Peter=20 Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Dan=20 Connolly, Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David = Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James = Hunt,=20 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel=20 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra Koduru=20 Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John=20 Stracke, John Tigue, John Turner, Kevin Wiggen, and others. 22 References [RFC2277] H.T. Alvestrand, "IETF Policy on Character Sets and=20 Languages." RFC 2277, BCP 18. Uninett. January, 1998. [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource=20 Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine,=20 Xerox. August, 1998. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate = Requirement=20 Levels." RFC 2119, BCP 14. Harvard University. March, 1997. [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup=20 Language (XML)." World Wide Web Consortium Recommendation REC-xml- 19980210. http://www.w3.org/TR/1998/REC-xml-19980210. [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.=20 Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC=20 2616. UC Irvine, Compaq, W3C, Xerox, Microsoft. June, 1999. [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. = Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518. = =20 Microsoft, U.C. Irvine, Netscape, Novell. February, 1999. [ISO-11578] ISO (International Organization for Standardization),=20 ISO/IEC 11578:1996. "Information technology - Open Systems=20 Interconnection - Remote Procedure Call (RPC)." [RR] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.=20 Crawford, "WebDAV Redirect References." Internet Draft (work=20 in progress) draft-ietf-webdav-redirectref-protocol-02. Xerox, UC=20 Irvine, CourseNet, Rational, FileNet, IBM. December, 1999. Slein et al. Page 21 =0CInternet-Draft WebDAV Bindings December = 1999 23 Authors' Addresses J. Slein Xerox Corporation 800 Phillips Road, 105-50C Webster, NY 14580 Email: jslein@crt.xerox.com E. J. Whitehead, Jr. Dept. of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 Email: ejw@ics.uci.edu J. Davis CourseNet Systems 170 Capp Street San Francisco, CA 94110 Email: jrd3@alum.mit.edu G. Clemm Rational Software Corporation 20 Maguire Road Lexington, MA 02173-3104 Email: gclemm@rational.com C. Fay FileNet Corporation 3565 Harbor Boulevard Costa Mesa, CA 92626-1420 Email: cfay@filenet.com J. Crawford IBM Research P.O. Box 704 Yorktown Heights, NY 10598 Email: ccjason@us.ibm.com 24 Appendices 24.1 Appendix 1: Extensions to the WebDAV Document Type Definition Expires June 17, 2000 Slein et al. Page 22 =0C ------_=_NextPart_000_01BF4C86.0BC75850-- From w3c-dist-auth-request@w3.org Thu Dec 23 06:48:17 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20269 for ; Thu, 23 Dec 1999 06:48:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA10523; Thu, 23 Dec 1999 06:37:06 -0500 (EST) Resent-Date: Thu, 23 Dec 1999 06:37:06 -0500 (EST) Resent-Message-Id: <199912231137.GAA10523@www19.w3.org> Message-Id: <199912231136.GAA20135@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 23 Dec 1999 06:36:56 -0500 Subject: I-D ACTION:draft-ietf-webdav-binding-protocol-02.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3743 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Bindings Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford Filename : draft-ietf-webdav-binding-protocol-02.txt Pages : 22 Date : 22-Dec-99 This is one of a pair of specifications that extend the WebDAV Distributed Authoring Protocol to enable clients to create new access paths to existing resources. The two protocol extensions have very different characteristics that make them useful for different sorts of applications. The present specification defines bindings, and the BIND method for creating them. Creating a new binding to a resource indirectly creates one or more new URIs mapped to that resource, which can then be used to access it. Servers are required to insure the integrity of any bindings that they allow to be created. The related specification, RFC xxxx, defines redirect reference resources. A redirect reference resource is a resource whose default response is an HTTP/1.1 302 (Found) status code, redirecting the client to a different resource, the target resource. A redirect reference makes it possible to access the target resource indirectly, through any URI mapped to the redirect reference resource. There are no integrity guarantees associated with redirect reference resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-binding-protocol-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-binding-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-binding-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991222095803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-binding-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-binding-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991222095803.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Mon Dec 27 16:51:40 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08443 for ; Mon, 27 Dec 1999 16:51:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21601; Mon, 27 Dec 1999 16:39:29 -0500 (EST) Resent-Date: Mon, 27 Dec 1999 16:39:29 -0500 (EST) Resent-Message-Id: <199912272139.QAA21601@www19.w3.org> Date: Mon, 27 Dec 1999 16:39:17 -0500 Message-Id: <9912272139.AA15162@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org Subject: Exclusive Locking ... per lock type? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3744 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Did section 8.10.6 of 2518 meant to say that an exclusive lock will fail if there already is a lock *of that locktype* on that resource, or if there is *any* exclusive lock there? I can see arguments for both directions, and implementors probably haven't thought that much about it since everybody is just doing write locks, but I assume the authors had one or the other in mind? Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Dec 27 18:06:16 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08802 for ; Mon, 27 Dec 1999 18:06:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23048; Mon, 27 Dec 1999 17:55:19 -0500 (EST) Resent-Date: Mon, 27 Dec 1999 17:55:19 -0500 (EST) Resent-Message-Id: <199912272255.RAA23048@www19.w3.org> From: Jim Whitehead To: "Geoffrey M. Clemm" , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Mon, 27 Dec 1999 14:52:02 -0800 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <9912272139.AA15162@tantalum> Importance: Normal Subject: RE: Exclusive Locking ... per lock type? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3745 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > Did section 8.10.6 of 2518 meant to say that an exclusive > lock will fail if there already is a lock *of that locktype* on that > resource, or if there is *any* exclusive lock there? > The intent was for the exclusivity to apply per locktype. So, for example, an exclusive read lock would not affect taking out an exclusive write lock. However, it is possible to imagine lock types that would have semantics that are not orthogonal to existing locks. For example, while read and write are pretty orthogonal, and hence exclusive read and exclusive write locks can co-exist happily on the same resource, a hypothetical "read/write" lock type would interfere with both a write lock and a (equally hypothetical) read lock, and in this case I would expect a request for an exclusive read/write lock to fail if there is either a shared read lock, or a shared write lock, or an exclusive read lock, or an exclusive write lock on the resource. So, the best answer is, when defining a new lock type the interactions of the new lock type with all existing lock types needs to be taken into consideration when creating the lock compatibility table. - Jim From w3c-dist-auth-request@w3.org Mon Dec 27 20:10:32 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09602 for ; Mon, 27 Dec 1999 20:10:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA24153; Mon, 27 Dec 1999 19:59:15 -0500 (EST) Resent-Date: Mon, 27 Dec 1999 19:59:15 -0500 (EST) Resent-Message-Id: <199912280059.TAA24153@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 27 Dec 1999 16:56:04 -0800 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: WG Last Call: Bindings Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3746 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit *** WORKING GROUP LAST CALL FOR COMMENTS *** WEBDAV BINDINGS PROTOCOL SPECIFICATION http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-binding- protocol-02 This is the final call for comments from the working group on the WebDAV Bindings Protocol specification, draft-ietf-webdav-binding-protocol-02. This last call period begins immediately, and ends January 24, 2000, at midnight, US Pacific time. This allows 4 weeks for review of this specification. At the end of the last call period, a new draft will be issued that resolves comments raised during the last call period. Depending on the scope of changes, there will follow either an immediate call for rough consensus (very few changes), or a second last call period (significant changes). Once the document represents the rough consensus of the working group, I will submit this document to the Internet Engineering Steering Group (IESG) for their approval. IESG review involves a (minimum) two week public last call for comments review period. This IESG-initiated last call period is in addition to the working group last call period. This document is intended to be a "Proposed Standard". Quoting from RFC 2026, "The Internet Standards Process -- Revision 3": The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. Many details on the procedures used to develop an IETF standard can be found in RFC 2026, available at: ftp://ftp.ietf.org/rfc/rfc2026.txt If there are any procedural questions or concerns, please do not hesitate to contact me, or raise an issue on the list. Notes: 1) This specification is one of three that have been developed in tandem, the other two being the Redirect References Protocol, draft-ietf-webdav-redirectref-protocol-02 and the Ordered Collections Protocol, draft-ietf-webdav-ordering-protocol-02. It is my intention to bring these documents up for last call in sequence, with the Redirect References Protocol going next, starting its last call on January 25, 2000. While the documents are being brought up for last call in sequence, you may, if you wish, review all three at once, and submit comments on all three during the last call period for the Bindings Protocol Specification. 2) If you've been waiting for a "stable" version of the specification before performing a review, wait no longer. This is it. Review the specification NOW. - Jim Whitehead Chair, IETF WEBDAV Working Group From w3c-dist-auth-request@w3.org Tue Dec 28 00:33:42 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13507 for ; Tue, 28 Dec 1999 00:33:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA26569; Tue, 28 Dec 1999 00:22:24 -0500 (EST) Resent-Date: Tue, 28 Dec 1999 00:22:24 -0500 (EST) Resent-Message-Id: <199912280522.AAA26569@www19.w3.org> Date: Tue, 28 Dec 1999 00:22:00 -0500 Message-Id: <9912280522.AA15294@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (message from Jim Whitehead on Mon, 27 Dec 1999 14:52:02 -0800) Subject: Re: Exclusive Locking ... per lock type? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3747 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list What Jim says is all reasonable, but cannot currently be inferred from the working in 2518. I'd suggest this be added to the issues list. In particular, I think it is reasonable for 2518 to say that an exclusive lock for a given locktype MUST not coexist with another lock of that same locktype. This gives a reasonable minimal semantics to "exclusive", while letting additional locktype specific semantics to be defined. Cheers, Geoff From: Jim Whitehead > Did section 8.10.6 of 2518 meant to say that an exclusive > lock will fail if there already is a lock *of that locktype* on that > resource, or if there is *any* exclusive lock there? The intent was for the exclusivity to apply per locktype. So, for example, an exclusive read lock would not affect taking out an exclusive write lock. However, it is possible to imagine lock types that would have semantics that are not orthogonal to existing locks. For example, while read and write are pretty orthogonal, and hence exclusive read and exclusive write locks can co-exist happily on the same resource, a hypothetical "read/write" lock type would interfere with both a write lock and a (equally hypothetical) read lock, and in this case I would expect a request for an exclusive read/write lock to fail if there is either a shared read lock, or a shared write lock, or an exclusive read lock, or an exclusive write lock on the resource. So, the best answer is, when defining a new lock type the interactions of the new lock type with all existing lock types needs to be taken into consideration when creating the lock compatibility table. From w3c-dist-auth-request@w3.org Tue Dec 28 01:40:58 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15917 for ; Tue, 28 Dec 1999 01:40:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA27878; Tue, 28 Dec 1999 01:28:37 -0500 (EST) Resent-Date: Tue, 28 Dec 1999 01:28:37 -0500 (EST) Resent-Message-Id: <199912280628.BAA27878@www19.w3.org> Message-ID: <024501bf50fc$b7fa5440$9a114498@us.oracle.com> From: "Eric Sedlar" To: "Jim Whitehead" , "WebDAV WG" Cc: "Geoffrey M. Clemm" References: Date: Mon, 27 Dec 1999 22:28:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: Re: WG Last Call: Bindings Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3748 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit This looks pretty good, as it addresses the circular reference issue. I'd still like to see an optional weak binding that is guaranteed not to dangle but that also does not affect the reference count, as I think that is needed when the implementor chooses not to allow circular BINDings affecting references. A couple of other comments: * on the security issue of revealing the set of bindings with the dav:bindings property: I recommend some comment to the effect that BINDings from unreadable collections should not be readable. So, the list of bindings in this property would only show READABLE bindings (and thus would be different depending on who was examining the property) * some comment to the effect that if the URL is a versioned resource, and the currently selected revision is changed, the resourceid will not change. (I'm assuming that is what you want.) So even though two people might see different data from a GET request from the same URL (because they would get a different revision selected), they would still have the same resourceid. Therefore, people should NOT use resourceid to invalidate caches or any other application that assumes a one to one correspondence between resourceid and data. --Eric ----- Original Message ----- From: "Jim Whitehead" To: "WebDAV WG" Sent: Monday, December 27, 1999 4:56 PM Subject: WG Last Call: Bindings Protocol > > *** WORKING GROUP LAST CALL FOR COMMENTS *** > > WEBDAV BINDINGS PROTOCOL SPECIFICATION > > > http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-binding- > protocol-02 > > This is the final call for comments from the working group on the WebDAV > Bindings Protocol specification, draft-ietf-webdav-binding-protocol-02. > This last call period begins immediately, and ends January 24, 2000, at > midnight, US Pacific time. This allows 4 weeks for review of this > specification. > > At the end of the last call period, a new draft will be issued that resolves > comments raised during the last call period. Depending on the scope of > changes, there will follow either an immediate call for rough consensus > (very few changes), or a second last call period (significant changes). Once > the document represents the rough consensus of the working group, I will > submit this document to the Internet Engineering Steering Group (IESG) for > their approval. IESG review involves a (minimum) two week public last call > for comments review period. This IESG-initiated last call period is in > addition to the working group last call period. > > This document is intended to be a "Proposed Standard". Quoting from RFC > 2026, "The Internet Standards Process -- Revision 3": > > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > > Many details on the procedures used to develop an IETF standard can be > found in RFC 2026, available at: > > ftp://ftp.ietf.org/rfc/rfc2026.txt > > If there are any procedural questions or concerns, please do not hesitate > to contact me, or raise an issue on the list. > > Notes: > > 1) This specification is one of three that have been developed in tandem, > the > other two being the Redirect References Protocol, > draft-ietf-webdav-redirectref-protocol-02 > and the Ordered Collections Protocol, > draft-ietf-webdav-ordering-protocol-02. > It is my intention to bring these documents up for last call in sequence, > with the Redirect References Protocol going next, starting its last call on > January 25, 2000. While the documents are being brought up for last call in > sequence, you may, if you wish, review all three at once, and submit > comments on all three during the last call period for the Bindings Protocol > Specification. > > 2) If you've been waiting for a "stable" version of the specification > before performing a review, wait no longer. This is it. Review the > specification NOW. > > > - Jim Whitehead > Chair, IETF WEBDAV Working Group > > From w3c-dist-auth-request@w3.org Tue Dec 28 09:25:28 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29999 for ; Tue, 28 Dec 1999 09:25:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA02407; Tue, 28 Dec 1999 09:13:50 -0500 (EST) Resent-Date: Tue, 28 Dec 1999 09:13:50 -0500 (EST) Resent-Message-Id: <199912281413.JAA02407@www19.w3.org> To: w3c-dist-auth@w3.org Date: Tue, 28 Dec 1999 15:08:37 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <19991228140837.87C40610DB@aachen.heimat.de> From: ruebe@aachen.heimat.de (Christian Scholz) Subject: Announce: python davserver 0.3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3749 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi! This night I've released version 0.3 of my python davserver. Changes are: - rewrite of PROPFIND to make it more standards conform (it now also returns error codes when something is not available/forbidden). - URL in a is now quoted to allow umlauts etc. - some changes to make it work with WebFolders - writing of interface classes should now be easier through providing a superclass with the main functions. - implemented the HEAD request and many changes to existing methods as well as streamlining the implementation (see Changes file in distribution). What's still missing is COPY, MOVE, PROPPATCH but I hope to implement at least COPY and MOVE before the end of this year (my main goal is to make it work with WebFolders as this is needed for demonstration purposes ;-) The package is available at ftp://comlounge.net/webdav/davserver-0.3.tar.gz and the homepage is availabe at http://www.comlounge.net/webdav/ (the former address www.webdav.de was not working yesterday. I really should transfer this domain to my own server..) BTW, I don't know if this is the right place for such announcements. If not please tell me :) best wished for 2000! Christian From w3c-dist-auth-request@w3.org Tue Dec 28 11:17:14 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01543 for ; Tue, 28 Dec 1999 11:17:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA04891; Tue, 28 Dec 1999 11:05:07 -0500 (EST) Resent-Date: Tue, 28 Dec 1999 11:05:07 -0500 (EST) Resent-Message-Id: <199912281605.LAA04891@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Eric Sedlar" cc: "WebDAV WG" Message-ID: <85256855.00584F45.00@D51MTA03.pok.ibm.com> Date: Tue, 28 Dec 1999 11:05:21 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: WG Last Call: Bindings Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3750 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list * some comment to the effect that if the URL is a versioned resource, and the currently selected revision is changed, the resourceid will not change. (I'm assuming that is what you want.) So even though two people might see different data from a GET request from the same URL (because they would get a different revision selected), they would still have the same resourceid. Therefore, people should NOT use resourceid to invalidate caches or any other application that assumes a one to one correspondence between resourceid and data. I agree with this one. I suspect the versioning document is the best place to put that though. Hopefully a versioning person will put this on their todo list. From w3c-dist-auth-request@w3.org Tue Dec 28 20:02:28 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07347 for ; Tue, 28 Dec 1999 20:02:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA12670; Tue, 28 Dec 1999 19:50:54 -0500 (EST) Resent-Date: Tue, 28 Dec 1999 19:50:54 -0500 (EST) Resent-Message-Id: <199912290050.TAA12670@www19.w3.org> To: w3c-dist-auth@w3.org Date: Wed, 29 Dec 1999 01:45:41 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <19991229004541.5C9EA610DB@aachen.heimat.de> From: ruebe@aachen.heimat.de (Christian Scholz) Subject: COPY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3751 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi! Just a little question regarding the COPY method: Under UNIX I can do the following: cp myfile.txt /new/path/ which is the same as cp myfile.txt /new/path/myfile.txt (assuming that the destination file does not exist already). Are such Destinations allowed for DAV also or do clients always have to provide the full path and not end with a collection which should act as new parent collection. As I understand the standard the full URI must be given (thus meaning cp myfile.txt /new/path/myfile.txt). Is this right? best, Christian From w3c-dist-auth-request@w3.org Tue Dec 28 21:17:48 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08053 for ; Tue, 28 Dec 1999 21:17:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA13700; Tue, 28 Dec 1999 21:06:41 -0500 (EST) Resent-Date: Tue, 28 Dec 1999 21:06:41 -0500 (EST) Resent-Message-Id: <199912290206.VAA13700@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DDE@BEG.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: WebDAV WG Date: Tue, 28 Dec 1999 16:43:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF51A1.454E4E4C" Subject: Why are WebDAV's XML namespace rules different than the W3C's? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3752 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF51A1.454E4E4C Content-Type: text/plain; charset="iso-8859-1" I was cleaning up my mail box when I found a letter I had written explaining the differences between the W3C's rules for handling namespaces and WebDAV's. In the end I believe that everyone adopted the W3C's rules but this does introduce a very serious interoperability issue that implementers need to be aware of. Anyone who actually is supporting section 23.4.2 (which, in so far as I know, nobody does) is well advised to re-write their code to maintain the separation between namespace and element name. BTW, this is both an old and a very well known issue. I am not posting this as an alert. Rather this post is yet another entry in the now 50 page or so WebDAV Book of Why explaining how we got ourselves into this fine mess. Yaron This letter discusses how WebDAV's rule for combining namespaces came about. It examines the cultural and technical issues that lead WebDAV to provide for a namespace unification that is not supported by any other XML community that we are aware of. Having now spent some time reflecting back on our reasoning I suspect the prime motivator was a culture class. In the world of HTTP in general and WebDAV in particular things are named with URIs. The idea of a "namespace" with member "names" is foreign to the general thinking of the culture. Separation of namespaces and elements is something that is handled by the person issuing the URI but is not relevant to how one actually handles URIs. That is, I can create a namespace of the form yaron:namespace/element. When I handle this URI I do not know, nor do I generally care, that the thing before the "/" is a namespace name and the thing after the "/" is an element name. All I see is a single, flat, formless string that I throw to my URI resolver who then resolves it. Thus the instinct of the group was to reduce the situation to a known solved problem, in this case, a single URI. There were also technical reasons for wanting to just glue the names together. The primary one was the desire to keep name/value property tables as simple as possible. Had we not glued together the namespace and name then property tables would have to have three rows, namespace, element name and value. This wouldn't work for many existing property systems that only supported simple name/value pairs. Given that one of the group's major goals was to be able to layer WebDAV over existing systems it was important that we be able to use these existing name/value property systems. That is why WebDAV has such primitive property support. These systems had no hope of being able to support partial property value replacement and property query. All they could do was name/value pairs. The value could be a chunk of XML but that was about it. So we needed a name that was a single string so we could work with these systems. WebDAV had adopted XML before namespaces existed. The assumption of the WebDAV WG was that elements would be named with URIs but that the SGML inherited namespace rules didn't allow for element names to include characters like ":", therefore a hack was needed to work around the character limitations. When the W3C introduced namespaces we assumed we had our hack. The only issue was, how to glue the namespace and element name back together to form the URI? The WebDAV WG approached the W3C namespace WG with the question of how to do the gluing but we couldn't get a straight answer. The argument from the W3C had nothing to do with some theoretical separation between the namespace and element names. Rather they argued about which magic character one should use in gluing together the namespace and the name, there were four contenders: "?", "#", "/" or just simply gluing the elements together. The W3C namespace WG's interest in this problem was rooted in their desire to be able to take a namespace and a name and resolve it to some URI they could use to retrieve the definition of the element, say a DTD. One faction wanted to use "?" so you would have http://namespace?elementname. This would be read as a query by the server. The problem with this solution is that there was no standard for what a query should look like and one might want to be able to use a more powerful query format. For example, one might want to ask for a group of element names instead of just one element name. Another faction wanted to use "#" so you would have http://namespace#elementname. This would mean that there was one document which provided the definition for every element in the namespace and the "#" would tell you which anchor to navigate to for the element you were interested in. The problem with this solution was that the definition document could potentially be huge since it would have to contain every element in the entire namespace. Another faction wanted to use "/" so you would have http://namespace/elementname. This would mean that there was a controlled namespace that was structured into directories and that one would ask for a particular file in a particular directory in order to get a name. The problem with this solution was that it mandated a particular directory structure that one had to keep to, forever. As discussed in section 17.7 of RFC 2518, the WebDAV WG didn't believe that the property names were ever going to be resolved in the real world, can you imagine everyone, everywhere actually trying to resolve the same single URI to get the definition of a popular element? This clearly wouldn't work so we weren't worried about the same problem the W3C guys were worried about. We couldn't care less about RESOLVING the namespace/element name pair; we just wanted to somehow get a single string that we could store. As such we were open to whatever rule the W3C wanted to create. The problem was, the W3C wasn't willing to pick any of them and WebDAV needed a solution. At the same time the W3C namespace WG kept missing deadlines for when their spec was supposed to move forward. They were so far off schedule that it looked like they would hold up WebDAV's standardization. Having already gone through so many problems and schedule slips with XML, WebDAV was not going to wait for the W3C to get namespaces out the door. Therefore the WebDAV WG decided to copy the namespace spec by value instead of by reference. That is, the WG copied the entire W3C XML namespace specification into section 23.4 of the WebDAV spec. This freed us up from any W3C dependencies at the cost of possibly having some differences between the WebDAV namespace implementation and the officially blessed W3C namespace implementation. However the W3C swore up and down at the time that there would be no further changes so our action was fine with them. Sensing that it wasn't going to get a solution to its property naming problem from the W3C the WebDAV WG decided to add a new section to 23.4 (23.4.2) which would talk about how to solve the property naming problem. The simplest solution was "all of the above." That is, just glue the namespace and the element name together. If you wanted to use "?" then simply structure your namespace with a "?" in it, the same logic applied to "#" and "/". By using the glue rule WebDAV was able to support all possible namespace structure rules. Unfortunately the application WG of the IETF got completely slammed and WebDAV was delayed for six months due to purely administrative reasons. However the W3C was able to finally get the namespace spec finalized. As promised, it didn't contain any changes. Unfortunately Tim Berners-Lee decided he didn't like the syntax and ordered it completely re-written. The WebDAV WG, thoroughly sick and tired of dealing with the W3C (remind me to write out the story of XML, from the WebDAV perspective, some time...) was ready to just say "to hell with it" and ship with our syntax. However cooler heads prevailed when TBL got his new syntax to recommendation status in record time (it's good to be the king). So at the very end, WebDAV changed over to the new syntax and pulled out our copy of namespaces and just referenced the W3C spec. However this still left section 23.4.2. Unfortunately the W3C namespace spec still failed to address the issue of how to combine the names so WebDAV decided to keep the section. In practice absolutely nobody seems to actually pay attention to 23.4.2. This means that eventually 23.4.2 will have to be removed when WebDAV moves on to draft status. However it is important to understand that 23.4.2 does introduce an interoperability issue when used in conjunction with systems that don't support 23.4.2. For example, A client makes a PROPFIND request and gets back the following property: Alex Hopmann The client records the property in the local property table: Property Name | Value | ------------------------------------------------------------------------ | z3950:majorschema-originalform-author | Alex Hopmann | The client then goes off-line and comes back on-line. The client tries to resynchronize their cache and so makes a PROPFIND request to retrieve the property value: RFC 2518 section 23.4.2 specifies that both of these PROPFIND data structures refer to the same property, z3950:majorschema-originalform-author. To quote from RFC 2518 section 23.4.2: WebDAV compliant XML processors MUST interpret a qualified name as a URI constructed by appending the LocalPart to the namespace name URI. However let's imagine (as is the common case) that the WebDAV server does not support 23.4.2. In the server's mind it sees the PROPFIND request as containing a request for Namespace = z3950, Name = majorschema-originalform-author. Since this obviously doesn't match Namespace=z3950:majorschema-originalform-, Name=author, the server will not return the client the property the client was looking for. The same scenario can be played out in different forms. One client does a PROPPATCH using the namespace z3950: and the element name majorschema-originalform-author and another client does a PROPFIND using the namespace z3950:majorschema- and the element name originalform-author. Using a WebDAV server that doesn't support 23.4.2 and the client and server will never be able to talk to each other since the server will treat the requests as pointing to two unrelated properties. The problem gets worse and worse as you start to try to push data between different systems and the namespaces and element names get mangled beyond all hope as you move from 23.4.2 compliant to 23.4.2 non-compliant clients and servers. Therefore the only solution is for everyone to ignore 23.4.2 and pray really hard that you never come up against a client or server that actually supports it. ------_=_NextPart_001_01BF51A1.454E4E4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why are WebDAV's XML namespace rules different than the W3C's? =

I was cleaning up my mail box when I = found a letter I had written explaining the differences between the = W3C's rules for handling namespaces and WebDAV's. In the end I believe = that everyone adopted the W3C's rules but this does introduce a very = serious interoperability issue that implementers need to be aware of. = Anyone who actually is supporting section 23.4.2 (which, in so far as I = know, nobody does) is well advised to re-write their code to maintain = the separation between namespace and element name.

BTW, this is both an old and a very = well known issue. I am not posting this as an alert. Rather this post = is yet another entry in the now 50 page or so WebDAV Book of Why = explaining how we got ourselves into this fine mess.

        =         =         =         Yaron

<Introduction>
This letter = discusses how WebDAV's rule for combining namespaces came about. It = examines the cultural and technical issues that lead WebDAV to provide = for a namespace unification that is not supported by any other XML = community that we are aware of.

</Introduction>

<Culture = Clash>
Having now spent = some time reflecting back on our reasoning I suspect the prime = motivator was a culture class. In the world of HTTP in general and = WebDAV in particular things are named with URIs. The idea of a = "namespace" with member "names" is foreign to the = general thinking of the culture. Separation of namespaces and elements = is something that is handled by the person issuing the URI but is not = relevant to how one actually handles URIs. That is, I can create a = namespace of the form yaron:namespace/element. When I handle this URI I = do not know, nor do I generally care, that the thing before the = "/" is a namespace name and the thing after the "/" = is an element name. All I see is a single, flat, formless string that I = throw to my URI resolver who then resolves it. Thus the instinct of the = group was to reduce the situation to a known solved problem, in this = case, a single URI.

</Culture = Clash>

<Technical = Reasons>
There were also = technical reasons for wanting to just glue the names together. The = primary one was the desire to keep name/value property tables as simple = as possible. Had we not glued together the namespace and name then = property tables would have to have three rows, namespace, element name = and value. This wouldn't work for many existing property systems that = only supported simple name/value pairs. Given that one of the group's = major goals was to be able to layer WebDAV over existing systems it was = important that we be able to use these existing name/value property = systems. That is why WebDAV has such primitive property support. These = systems had no hope of being able to support partial property value = replacement and property query. All they could do was name/value pairs. = The value could be a chunk of XML but that was about it. So we needed a = name that was a single string so we could work with these systems.

</Technical = Reasons>

<Some = History>
WebDAV had adopted = XML before namespaces existed. The assumption of the WebDAV WG was that = elements would be named with URIs but that the SGML inherited namespace = rules didn't allow for element names to include characters like = ":", therefore a hack was needed to work around the character = limitations. When the W3C introduced namespaces we assumed we had our = hack. The only issue was, how to glue the namespace and element name = back together to form the URI?

The WebDAV WG = approached the W3C namespace WG with the question of how to do the = gluing but we couldn't get a straight answer. The argument from the W3C = had nothing to do with some theoretical separation between the = namespace and element names. Rather they argued about which magic = character one should use in gluing together the namespace and the name, = there were four contenders: "?", "#", "/" = or just simply gluing the elements together. The W3C namespace WG's = interest in this problem was rooted in their desire to be able to take = a namespace and a name and resolve it to some URI they could use to = retrieve the definition of the element, say a DTD.

One faction wanted = to use "?" so you would have http://namespace?elementname. This would be read = as a query by the server. The problem with this solution is that there = was no standard for what a query should look like and one might want to = be able to use a more powerful query format. For example, one might = want to ask for a group of element names instead of just one element = name.

Another faction = wanted to use "#" so you would have http://namespace#elementname. This would mean = that there was one document which provided the definition for every = element in the namespace and the "#" would tell you which = anchor to navigate to for the element you were interested in. The = problem with this solution was that the definition document could = potentially be huge since it would have to contain every element in the = entire namespace.

Another faction = wanted to use "/" so you would have http://namespace/elementname. This would mean = that there was a controlled namespace that was structured into = directories and that one would ask for a particular file in a = particular directory in order to get a name. The problem with this = solution was that it mandated a particular directory structure that one = had to keep to, forever.

As discussed in = section 17.7 of RFC 2518, the WebDAV WG didn't believe that the = property names were ever going to be resolved in the real world, can = you imagine everyone, everywhere actually trying to resolve the same = single URI to get the definition of a popular element? This clearly = wouldn't work so we weren't worried about the same problem the W3C guys = were worried about. We couldn't care less about RESOLVING the = namespace/element name pair; we just wanted to somehow get a single = string that we could store. As such we were open to whatever rule the = W3C wanted to create. The problem was, the W3C wasn't willing to pick = any of them and WebDAV needed a solution.

At the same time the = W3C namespace WG kept missing deadlines for when their spec was = supposed to move forward. They were so far off schedule that it looked = like they would hold up WebDAV's standardization. Having already gone = through so many problems and schedule slips with XML, WebDAV was not = going to wait for the W3C to get namespaces out the door. Therefore the = WebDAV WG decided to copy the namespace spec by value instead of by = reference. That is, the WG copied the entire W3C XML namespace = specification into section 23.4 of the WebDAV spec. This freed us up = from any W3C dependencies at the cost of possibly having some = differences between the WebDAV namespace implementation and the = officially blessed W3C namespace implementation. However the W3C swore = up and down at the time that there would be no further changes so our = action was fine with them.

Sensing that it = wasn't going to get a solution to its property naming problem from the = W3C the WebDAV WG decided to add a new section to 23.4 (23.4.2) which = would talk about how to solve the property naming problem. The simplest = solution was "all of the above." That is, just glue the = namespace and the element name together. If you wanted to use = "?" then simply structure your namespace with a "?" = in it, the same logic applied to "#" and "/". By = using the glue rule WebDAV was able to support all possible namespace = structure rules.

Unfortunately the = application WG of the IETF got completely slammed and WebDAV was = delayed for six months due to purely administrative reasons. However = the W3C was able to finally get the namespace spec finalized. As = promised, it didn't contain any changes. Unfortunately Tim Berners-Lee = decided he didn't like the syntax and ordered it completely re-written. = The WebDAV WG, thoroughly sick and tired of dealing with the W3C = (remind me to write out the story of XML, from the WebDAV perspective, = some time...) was ready to just say "to hell with it" and = ship with our syntax. However cooler heads prevailed when TBL got his = new syntax to recommendation status in record time (it's good to be the = king). So at the very end, WebDAV changed over to the new syntax and = pulled out our copy of namespaces and just referenced the W3C spec. = However this still left section 23.4.2. Unfortunately the W3C namespace = spec still failed to address the issue of how to combine the names so = WebDAV decided to keep the section.

</Some = History>

<So, is this an = interoperability issue?>
In practice = absolutely nobody seems to actually pay attention to 23.4.2. This means = that eventually 23.4.2 will have to be removed when WebDAV moves on to = draft status. However it is important to understand that 23.4.2 does = introduce an interoperability issue when used in conjunction with = systems that don't support 23.4.2.

For example, A = client makes a PROPFIND request and gets back the following = property:

<D:prop = xmlns:R=3D"z3950:majorschema-originalform-">
        <R:author>
        =         Alex Hopmann
        </R:author>
</D:prop>
         &nb= sp;    
The client records = the property in the local property table:

Property = Name           &n= bsp;           &n= bsp;           &n= bsp;   | = Value           &= nbsp;  |
-------------------------------------------------------------------= ----- |
z3950:majorschema-originalform-author     =           | Alex = Hopmann       |

The client then goes = off-line and comes back on-line. The client tries to resynchronize = their cache and so makes a PROPFIND request to retrieve the property = value:

<D:prop = xmlns:R=3D"z3950:">
        <R:majorschema-originalform-author/>
</D:prop>

RFC 2518 section = 23.4.2 specifies that both of these PROPFIND data structures refer to = the same property, z3950:majorschema-originalform-author. To quote from = RFC 2518 section 23.4.2:

        WebDAV compliant XML processors MUST interpret = a qualified name as a
        URI constructed by appending the LocalPart to = the namespace name URI.
   =
However let's = imagine (as is the common case) that the WebDAV server does not support = 23.4.2. In the server's mind it sees the PROPFIND request as containing = a request for Namespace =3D z3950, Name =3D = majorschema-originalform-author. Since this obviously doesn't match = Namespace=3Dz3950:majorschema-originalform-, Name=3Dauthor, the server = will not return the client the property the client was looking = for.

The same scenario = can be played out in different forms. One client does a PROPPATCH using = the namespace z3950: and the element name majorschema-originalform-author = and another client does = a PROPFIND using the namespace z3950:majorschema- and the element = name originalform-author. Using a WebDAV server that doesn't support = 23.4.2 and the client and server will never be able to talk to each = other since the server will treat the requests as pointing to two = unrelated properties.

The problem gets = worse and worse as you start to try to push data between different = systems and the namespaces and element names get mangled beyond all = hope as you move from 23.4.2 compliant to 23.4.2 non-compliant clients = and servers.

Therefore the only = solution is for everyone to ignore 23.4.2 and pray really hard that you = never come up against a client or server that actually supports = it.

<So, is this an = interoperability issue?>


------_=_NextPart_001_01BF51A1.454E4E4C-- From w3c-dist-auth-request@w3.org Tue Dec 28 21:23:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08117 for ; Tue, 28 Dec 1999 21:23:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA14023; Tue, 28 Dec 1999 21:12:19 -0500 (EST) Resent-Date: Tue, 28 Dec 1999 21:12:19 -0500 (EST) Resent-Message-Id: <199912290212.VAA14023@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256856.000C141C.00@d54mta03.raleigh.ibm.com> Date: Tue, 28 Dec 1999 21:12:30 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: COPY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3753 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list You're right, the full path must be given. A client can choose to provide the functionality you describe though. DAV4J does this. ruebe@aachen.heimat.de (Christian Scholz)@w3.org on 12/28/99 07:45:41 PM Sent by: w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: COPY Hi! Just a little question regarding the COPY method: Under UNIX I can do the following: cp myfile.txt /new/path/ which is the same as cp myfile.txt /new/path/myfile.txt (assuming that the destination file does not exist already). Are such Destinations allowed for DAV also or do clients always have to provide the full path and not end with a collection which should act as new parent collection. As I understand the standard the full URI must be given (thus meaning cp myfile.txt /new/path/myfile.txt). Is this right? best, Christian From w3c-dist-auth-request@w3.org Tue Dec 28 21:36:58 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08231 for ; Tue, 28 Dec 1999 21:36:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA14677; Tue, 28 Dec 1999 21:25:54 -0500 (EST) Resent-Date: Tue, 28 Dec 1999 21:25:54 -0500 (EST) Resent-Message-Id: <199912290225.VAA14677@www19.w3.org> Date: Tue, 28 Dec 1999 18:28:36 -0800 (PST) From: Greg Stein To: "Yaron Goland (Exchange)" cc: WebDAV WG In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619DDE@BEG.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Why are WebDAV's XML namespace rules different than the W3C's? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3754 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Tue, 28 Dec 1999, Yaron Goland (Exchange) wrote: > I was cleaning up my mail box when I found a letter I had written explaining > the differences between the W3C's rules for handling namespaces and > WebDAV's. In the end I believe that everyone adopted the W3C's rules but > this does introduce a very serious interoperability issue that implementers > need to be aware of. Anyone who actually is supporting section 23.4.2 > (which, in so far as I know, nobody does) is well advised to re-write their > code to maintain the separation between namespace and element name. Excellent writeup, Yaron. I'll get this added to your Book Of Why on webdav.org :-) FWIW, mod_dav does not obey 23.4.2 -- it treats the namespace and name as a tuple, rather than concatenating them. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Dec 29 08:19:19 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26770 for ; Wed, 29 Dec 1999 08:19:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA20235; Wed, 29 Dec 1999 08:08:12 -0500 (EST) Resent-Date: Wed, 29 Dec 1999 08:08:12 -0500 (EST) Resent-Message-Id: <199912291308.IAA20235@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256856.00481EC4.00@d54mta03.raleigh.ibm.com> Date: Wed, 29 Dec 1999 08:07:46 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Why are WebDAV's XML namespace rules different than the W3C's? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3755 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list It is my understanding that the meaning of an XML namespace with respect to its tags is completely up to the application. Therefore WebDAV is not at odds with W3C namespace rules. WebDAV servers that concatenate namespace with tag to form an identifier will interoperate just fine. The alternative is to keep them separate but always match on both. DAV4J keeps the namespace, prefix, and property identifier separate in the API, but normalizes them in the server for matching. That is, a:foo and b: foo are the same thing if a and b are the same namespace. This is not the case with XML as these are considered different tags, but applications are free to treat them as having the same semantics. From WebDAV's point of view, these different tags represent the same property name. I think it would be a bad thing if this were not true. Greg Stein @w3.org on 12/28/99 09:28:36 PM Sent by: w3c-dist-auth-request@w3.org To: "Yaron Goland (Exchange)" cc: WebDAV WG Subject: Re: Why are WebDAV's XML namespace rules different than the W3C's? On Tue, 28 Dec 1999, Yaron Goland (Exchange) wrote: > I was cleaning up my mail box when I found a letter I had written explaining > the differences between the W3C's rules for handling namespaces and > WebDAV's. In the end I believe that everyone adopted the W3C's rules but > this does introduce a very serious interoperability issue that implementers > need to be aware of. Anyone who actually is supporting section 23.4.2 > (which, in so far as I know, nobody does) is well advised to re-write their > code to maintain the separation between namespace and element name. Excellent writeup, Yaron. I'll get this added to your Book Of Why on webdav.org :-) FWIW, mod_dav does not obey 23.4.2 -- it treats the namespace and name as a tuple, rather than concatenating them. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Dec 29 13:27:08 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01367 for ; Wed, 29 Dec 1999 13:27:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06102; Wed, 29 Dec 1999 13:14:55 -0500 (EST) Resent-Date: Wed, 29 Dec 1999 13:14:55 -0500 (EST) Resent-Message-Id: <199912291814.NAA06102@www19.w3.org> Message-Id: <4.1.19991229174518.00ad4f00@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 29 Dec 1999 18:38:47 +0100 To: "Yaron Goland (Exchange)" , WebDAV WG From: Jim Davis In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619DDE@BEG.platinum.corp .microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Why are WebDAV's XML namespace rules different than the W3C's? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3756 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 04:43 PM 12/28/99 -0800, Yaron Goland (Exchange) wrote: > Anyone who actually is supporting section 23.4.2 (which, in so far as I know, nobody does) Well, the xml library that I wrote to support the Xerox PARC Python WebDAV server does. I saw Greg Stein's email saying mod_dav does not follow 23.4.2 Any one else? > is well advised to re-write their code to maintain the separation between namespace > and element name. So you are proposing that we drop 23.4.2 from WebDAV? Sigh. I suppose that, if the entire rest of the XML world does in fact follow the convention that namespaces are distinct from element names, then WebDAV may as well switch to follow them. What a pain in the neck! From w3c-dist-auth-request@w3.org Wed Dec 29 13:49:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01732 for ; Wed, 29 Dec 1999 13:49:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07204; Wed, 29 Dec 1999 13:37:43 -0500 (EST) Resent-Date: Wed, 29 Dec 1999 13:37:43 -0500 (EST) Resent-Message-Id: <199912291837.NAA07204@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DE2@BEG.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Jim Davis'" , WebDAV WG Date: Wed, 29 Dec 1999 10:36:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF522B.C302397C" Subject: RE: Why are WebDAV's XML namespace rules different than the W3C's ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3757 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF522B.C302397C Content-Type: text/plain Alas, yes, I am proposing that we drop 23.4.2. While, from a technical point of view, it is clearly the wrong thing to do, from the interoperability point of view it is the right thing to do. Since our job is to be interoperable there doesn't seem to be much of a choice. Until we get better at marketing than the W3C, they call the shots. Yaron > -----Original Message----- > From: Jim Davis [mailto:jrd3@alum.mit.edu] > Sent: Wed, December 29, 1999 9:39 AM > To: Yaron Goland (Exchange); WebDAV WG > Subject: Re: Why are WebDAV's XML namespace rules different than the > W3C's? > > > At 04:43 PM 12/28/99 -0800, Yaron Goland (Exchange) wrote: > > Anyone who actually is supporting section 23.4.2 (which, in > so far as I > know, nobody does) > > Well, the xml library that I wrote to support the Xerox PARC > Python WebDAV > server does. > I saw Greg Stein's email saying mod_dav does not follow 23.4.2 > > Any one else? > > > is well advised to re-write their code to maintain the > separation between > namespace > > and element name. > > So you are proposing that we drop 23.4.2 from WebDAV? > > Sigh. I suppose that, if the entire rest of the XML world > does in fact > follow the convention that namespaces are distinct from > element names, then > WebDAV may as well switch to follow them. What a pain in the neck! > ------_=_NextPart_001_01BF522B.C302397C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Why are WebDAV's XML namespace rules different than the = W3C's?

Alas, yes, I am proposing that we drop 23.4.2. While, = from a technical point of view, it is clearly the wrong thing to do, = from the interoperability point of view it is the right thing to do. = Since our job is to be interoperable there doesn't seem to be much of a = choice.

Until we get better at marketing than the W3C, they = call the shots.

        =         =         Yaron


> -----Original Message-----
> From: Jim Davis [mailto:jrd3@alum.mit.edu]
> Sent: Wed, December 29, 1999 9:39 AM
> To: Yaron Goland (Exchange); WebDAV WG
> Subject: Re: Why are WebDAV's XML namespace = rules different than the
> W3C's?
>
>
> At 04:43 PM 12/28/99 -0800, Yaron Goland = (Exchange) wrote:
> > Anyone who actually is supporting section = 23.4.2 (which, in
> so far as I
> know, nobody does)
>
> Well, the xml library that I wrote to support = the Xerox PARC
> Python WebDAV
> server does.
> I saw Greg Stein's email saying mod_dav does = not follow 23.4.2
>
> Any one else?
>
> > is well advised to re-write their code to = maintain the
> separation between
> namespace
> > and element name.
>
> So you are proposing that we drop 23.4.2 from = WebDAV?
>
> Sigh.  I suppose that, if the entire rest = of the XML world
> does in fact
> follow the convention that namespaces are = distinct from
> element names, then
> WebDAV may as well switch to follow them.  = What a pain in the neck!
>

------_=_NextPart_001_01BF522B.C302397C-- From w3c-dist-auth-request@w3.org Wed Dec 29 17:52:15 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04914 for ; Wed, 29 Dec 1999 17:52:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA10974; Wed, 29 Dec 1999 17:40:25 -0500 (EST) Resent-Date: Wed, 29 Dec 1999 17:40:25 -0500 (EST) Resent-Message-Id: <199912292240.RAA10974@www19.w3.org> To: w3c-dist-auth@w3.org Date: Wed, 29 Dec 1999 23:35:08 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <19991229223508.6F4BA610DB@aachen.heimat.de> From: ruebe@aachen.heimat.de (Christian Scholz) Subject: COPY again.. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3758 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi! Thanks for the last answer but I have another question regarding the Overwrite Header: 1. What is the default of the Header if it's not given? From the example I assume it's T 2. When I do an Overwrite and the DELETE fails for some resources, what do I do? Of course I cannot copy the resources for which the destination still exists but what do I return in the multistatus? Do I simply append the DELETE errors to the COPY errors? Assume we have a/b/c/d and want to copy /a to /f/g where still resources like /f/g/h exist. Now h will produce a 403 when trying to delete it. Hm, right now I would say, I cannot delete h thus I cannot delete g and thus I cannot copy anything.. Is this the right solution? ;-) I like the details.. ;-) best, Christian From w3c-dist-auth-request@w3.org Wed Dec 29 21:18:59 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06149 for ; Wed, 29 Dec 1999 21:18:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA13587; Wed, 29 Dec 1999 21:08:00 -0500 (EST) Resent-Date: Wed, 29 Dec 1999 21:08:00 -0500 (EST) Resent-Message-Id: <199912300208.VAA13587@www19.w3.org> Date: Wed, 29 Dec 1999 21:07:29 -0500 Message-Id: <9912300207.AA16121@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <19991229223508.6F4BA610DB@aachen.heimat.de> (ruebe@aachen.heimat.de) Subject: Re: COPY again.. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3759 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: ruebe@aachen.heimat.de (Christian Scholz) 1. What is the default of the Header if it's not given? From the example I assume it's T Yes. Section 9.6: "If the overwrite header is not included in a COPY or MOVE request then the resource MUST treat the request as if it has an overwrite header of value "T"." 2. When I do an Overwrite and the DELETE fails for some resources, what do I do? Of course I cannot copy the resources for which the destination still exists but what do I return in the multistatus? Do I simply append the DELETE errors to the COPY errors? Yes, this is unclear in the spec (there's an exchange between Kevin and Jim on this topic back in the middle of May). Jim added this to the issue list for 2518. Jim's response was: "It should respond with the errors for delete, since these are the conditions which would need to be removed by the client for the operation to proceed." In other words, the delete errors *are* the copy errors. Assume we have a/b/c/d and want to copy /a to /f/g where still resources like /f/g/h exist. Now h will produce a 403 when trying to delete it. Hm, right now I would say, I cannot delete h thus I cannot delete g and thus I cannot copy anything.. Yes. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Dec 30 12:16:48 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00673 for ; Thu, 30 Dec 1999 12:16:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA22834; Thu, 30 Dec 1999 12:04:23 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 12:04:23 -0500 (EST) Resent-Message-Id: <199912301704.MAA22834@www19.w3.org> Date: Thu, 30 Dec 1999 14:45:10 +0000 From: Joe Orton To: w3c-dist-auth@w3.org Message-ID: <19991230170302.C330@ankh.dunno.local> Mail-Followup-To: w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Subject: Creating a lock-null in a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3760 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I have an depth 0 write lock on /foo/. If I do LOCK /foo/bar to create a lock-null resource, do I need to submit the locktoken for /foo/ in the LOCK request? Or only in the PUT to /foo/bar later? (Or is it decided that lock-null resources are going to go away?) joe From w3c-dist-auth-request@w3.org Thu Dec 30 12:48:06 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01557 for ; Thu, 30 Dec 1999 12:48:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA23406; Thu, 30 Dec 1999 12:36:58 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 12:36:58 -0500 (EST) Resent-Message-Id: <199912301736.MAA23406@www19.w3.org> Reply-To: <5chandlers@home.com> From: "David M. Chandler" <5chandlers@home.com> To: Date: Thu, 30 Dec 1999 11:40:48 -0800 Message-ID: <000f01bf52fd$c66f9c30$d6f00218@c786448-a.cdrrpd1.ia.home.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: New WebDAV client spotted at XML '99 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3761 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit A Brief Report on WebDAV at XML '99 Greg Stein's presentation on WebDAV drew a fair amount of interest, but there was little mention of WebDAV otherwise. I was pleased to find one XML editor with WebDAV support (below) and attempted to bring WebDAV to the attention of other vendors. My particular interest is using a WebDAV repository to enable collaboration on hierarchical XML documents, and I was pleased to find a product which does exactly that. Excosoft Documentor is a combination XML/SGML/HTML browser/editor with WebDAV support. The most interesting aspects of the product are 1) It lets you edit in place while browsing. If a WebDAV server is available, you can lock, modify, unlock, and save files easily. 2) When you click on a hyperlink, the browser/editor displays the target file in-line with the file you're already browsing. Thus, a single "document" may actually be composed of many files, each of which may locked, modified, unlocked, and saved to the WebDAV server in place. This lends itself easily to creating structured documents made up of hierarchical elements. You can browse a document thus constructed in its entirety, or by drilling down through the collapsible outline of hyperlinks. This enables applications where many people edit different sections of the same document at once without losing the visual context of the larger document. It's more easily seen than described, as the interface solves a difficult problem in a very clever way. You can download a 30-day evaluation at www.excosoft.com. Excosoft Documentor should also be added to the product list at webdav.org. David Chandler Web Applications Developer Technisource, Inc. From w3c-dist-auth-request@w3.org Thu Dec 30 15:21:19 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04878 for ; Thu, 30 Dec 1999 15:21:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26494; Thu, 30 Dec 1999 15:09:50 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 15:09:50 -0500 (EST) Resent-Message-Id: <199912302009.PAA26494@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DE5@BEG.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Joe Orton'" , w3c-dist-auth@w3.org Date: Thu, 30 Dec 1999 12:04:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5301.25878798" Subject: RE: Creating a lock-null in a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3762 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5301.25878798 Content-Type: text/plain The depth 0 lock controls the ability to add level 1 children to the collection. A lock null resource is a resource and hence is a member of whatever collections it exists within. Therefore to create a lock null resource as a level 1 child of a collection with a depth 0 lock one must have the depth 0 lock. In other words, yes, you must submit the token on the LOCK on /foo/bar. Yaron > -----Original Message----- > From: Joe Orton [mailto:joe@orton.demon.co.uk] > Sent: Thu, December 30, 1999 6:45 AM > To: w3c-dist-auth@w3.org > Subject: Creating a lock-null in a locked collection > > > I have an depth 0 write lock on /foo/. If I do LOCK /foo/bar > to create a > lock-null resource, do I need to submit the locktoken for /foo/ in the > LOCK request? Or only in the PUT to /foo/bar later? > > (Or is it decided that lock-null resources are going to go away?) > > joe > ------_=_NextPart_001_01BF5301.25878798 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Creating a lock-null in a locked collection

The depth 0 lock controls the ability to add level 1 = children to the collection.
A lock null resource is a resource and hence is a = member of whatever collections it exists within.
Therefore to create a lock null resource as a level = 1 child of a collection with a depth 0 lock one must have the depth 0 = lock.

In other words, yes, you must submit the token on the = LOCK on /foo/bar.

        =         =         Yaron

> -----Original Message-----
> From: Joe Orton [mailto:joe@orton.demon.co.uk]<= /FONT>
> Sent: Thu, December 30, 1999 6:45 AM
> To: w3c-dist-auth@w3.org
> Subject: Creating a lock-null in a locked = collection
>
>
> I have an depth 0 write lock on /foo/. If I do = LOCK /foo/bar
> to create a
> lock-null resource, do I need to submit the = locktoken for /foo/ in the
> LOCK request? Or only in the PUT to /foo/bar = later?
>
> (Or is it decided that lock-null resources are = going to go away?)
>
> joe
>

------_=_NextPart_001_01BF5301.25878798-- From w3c-dist-auth-request@w3.org Thu Dec 30 17:45:05 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08663 for ; Thu, 30 Dec 1999 17:45:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA29221; Thu, 30 Dec 1999 17:33:16 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 17:33:16 -0500 (EST) Resent-Message-Id: <199912302233.RAA29221@www19.w3.org> Date: Thu, 30 Dec 1999 17:33:05 -0500 Message-Id: <9912302233.AA16478@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619DE5@BEG.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: Creating a lock-null in a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3763 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list As an addendum to Yaron's response, I'll note that there is a proposal that WebDAV locking is better understood as locks on URL's rather than on resources. This not only makes the current WebDAV locking behavior easier to motivate (e.g. a resource "loses" a lock after a move because it is no longer identified by the locked URL), but removes the need to define a "lock null resource". One effect of this proposal would be that the answer to Joe's question would change, i.e. that a LOCK request *never* requires a lock token. A LOCK request can fail (such as when it would collide with an existing exclusive lock), but no failure would be resolvable through the addition of a lock token. FYI, the current state of the lock proposal is: A lock can be placed on a URL with a LOCK request. This URL is called the "lock base". If the lock is Depth:N, then a lock is induced on any URL that consists of the lock base extended by N or fewer segments. Only an authorized holder of a lock token for a locked URL can modify either the state of the resource identified by the URL, or which resource is identified by the URL. A URL MAY NOT be locked with two exclusive locks with the same locktype. Cheers, Geoff From: "Yaron Goland (Exchange)" The depth 0 lock controls the ability to add level 1 children to the collection. A lock null resource is a resource and hence is a member of whatever collections it exists within. Therefore to create a lock null resource as a level 1 child of a collection with a depth 0 lock one must have the depth 0 lock. In other words, yes, you must submit the token on the LOCK on /foo/bar. Yaron > -----Original Message----- > From: Joe Orton [mailto:joe@orton.demon.co.uk] > Sent: Thu, December 30, 1999 6:45 AM > To: w3c-dist-auth@w3.org > Subject: Creating a lock-null in a locked collection > > > I have an depth 0 write lock on /foo/. If I do LOCK /foo/bar > to create a > lock-null resource, do I need to submit the locktoken for /foo/ in the > LOCK request? Or only in the PUT to /foo/bar later? > > (Or is it decided that lock-null resources are going to go away?) > > joe > From w3c-dist-auth-request@w3.org Thu Dec 30 19:02:26 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09666 for ; Thu, 30 Dec 1999 19:02:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA00623; Thu, 30 Dec 1999 18:48:18 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 18:48:18 -0500 (EST) Resent-Message-Id: <199912302348.SAA00623@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256857.0082BD5E.00@d54mta03.raleigh.ibm.com> Date: Thu, 30 Dec 1999 12:18:21 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Creating a lock-null in a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3764 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list You will need to include the lock token for /foo/ as you are adding a member to this collection even though its a lock-null resource. If you do a PROPFIND with depth:0 on /foo/, you'll see the lock-null resource even before you do the initial PUT proving the collection's members, and therefore it state, were modified. Joe Orton @w3.org on 12/30/99 09:45:10 AM Sent by: w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Creating a lock-null in a locked collection I have an depth 0 write lock on /foo/. If I do LOCK /foo/bar to create a lock-null resource, do I need to submit the locktoken for /foo/ in the LOCK request? Or only in the PUT to /foo/bar later? (Or is it decided that lock-null resources are going to go away?) joe From w3c-dist-auth-request@w3.org Thu Dec 30 20:01:59 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10325 for ; Thu, 30 Dec 1999 20:01:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA01229; Thu, 30 Dec 1999 19:48:38 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 19:48:38 -0500 (EST) Resent-Message-Id: <199912310048.TAA01229@www19.w3.org> Date: Fri, 31 Dec 1999 00:37:59 +0000 From: Joe Orton To: "Yaron Goland (Exchange)" Cc: w3c-dist-auth@w3.org Message-ID: <19991231003759.B4902@ankh.dunno.local> Mail-Followup-To: "Yaron Goland (Exchange)" , w3c-dist-auth@w3.org References: <7DE119D3D0E15543874F7561EECBDBED02619DE5@BEG.platinum.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619DE5@BEG.platinum.corp.microsoft.com>; from yarong@Exchange.Microsoft.com on Thu, Dec 30, 1999 at 12:04:22PM -0800 Subject: Re: Creating a lock-null in a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3765 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > The depth 0 lock controls the ability to add level 1 children to the > collection. > A lock null resource is a resource and hence is a member of whatever > collections it exists within. > Therefore to create a lock null resource as a level 1 child of a collection > with a depth 0 lock one must have the depth 0 lock. > > In other words, yes, you must submit the token on the LOCK on /foo/bar. Okay, thanks. It just seemed slightly weird, that if you LOCK or UNLOCK a lock-null resource, you are modifying the state of the parent collection; when if you do the same to a normal resource, you are not. Regards, joe From w3c-dist-auth-request@w3.org Thu Dec 30 20:38:01 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11147 for ; Thu, 30 Dec 1999 20:37:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA01960; Thu, 30 Dec 1999 20:26:15 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 20:26:15 -0500 (EST) Resent-Message-Id: <199912310126.UAA01960@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DE7@BEG.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Thu, 30 Dec 1999 17:25:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: Locking URIs rather than Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3766 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Before I jump into the fray I want to make sure that I actually understand the proposal. One sentence in particular gave me pause for thought. Geoff stated that "...a LOCK request *never* requires a lock token". I though hard about this, trying to understand exactly what it meant. Below I lay out my thinking process so that if I have misunderstood the proposal my error can be found and corrected. Imagine user U takes out a depth 0 lock on collection C. Collection C has no children. The ramification is that no one but U may add a new child to C. User A then shows up and wants to create a new resource with the URL C/R. Before creating the resource, however, A would like to first reserve the name C/R. To this end A takes out a lock on C/R. In the old system A's request would be rejected. The reason is that in the old system locks are on resources. Therefore for A to lock the name C/R it has to create some resource which 'owns' C/R and then lock that resource. This is where lock-null resources came from. They are the 'stand-in' resource who holds the name C/R until A is ready to transfer ownership of the name to its final destination. However creating the lock-null resource to hold C/R means that the lock-null resource would automatically become a child of C. U, through its lock on C, has reserved the exclusive right to create children of C. Therefore A's request to lock C/R is rejected because the creation of the lock-null resource to hold the name C/R would violate U's lock on C. (Is it just me or does the previous sound like an Abbott and Castello routine? Castello: Who has the lock? Abbott: Who has the lock. Castello: No, who has the lock?!? Abott: Exactly.) But in the new proposal locks aren't on resources, they are on URIs. Therefore when A locks C/R it is not locking a resource, it is locking a name. Names aren't members of collections, resources are. Therefore A can lock C/R without running afoul of U's lock on C because C/R, even though it is locked, is still not a member of the collection. When A will run into trouble is when it attempts, through a COPY, MOVE, PROPPATCH, PUT, MKCOL, etc. to associate the URL C/R with a resource. By associating a resource with C/R A will cause that resource to become a member of C. Of course U has reserved the right to create new members of C, therefore A's request will be rejected. The result is that A can lock C/R without submitting a lock token. However there isn't much A can do with the lock on C/R because doing anything to it would require associating it with a resource, which U's lock prevents. Geoff, did I get it right? Yaron > -----Original Message----- > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > Sent: Thu, December 30, 1999 2:33 PM > To: w3c-dist-auth@w3.org > Subject: Re: Creating a lock-null in a locked collection > > > > As an addendum to Yaron's response, I'll note that there is a proposal > that WebDAV locking is better understood as locks on URL's rather than > on resources. This not only makes the current WebDAV locking behavior > easier to motivate (e.g. a resource "loses" a lock after a move > because it is no longer identified by the locked URL), but removes the > need to define a "lock null resource". > > One effect of this proposal would be that the answer to Joe's question > would change, i.e. that a LOCK request *never* requires a lock token. > A LOCK request can fail (such as when it would collide with > an existing > exclusive lock), but no failure would be resolvable through > the addition > of a lock token. > > FYI, the current state of the lock proposal is: > > A lock can be placed on a URL with a LOCK request. This URL is called > the "lock base". If the lock is Depth:N, then a lock is induced on > any URL that consists of the lock base extended by N or fewer > segments. Only an authorized holder of a lock token for a locked URL > can modify either the state of the resource identified by the URL, or > which resource is identified by the URL. A URL MAY NOT be locked > with two exclusive locks with the same locktype. > > Cheers, > Geoff > > From: "Yaron Goland (Exchange)" > > The depth 0 lock controls the ability to add level 1 > children to the > collection. > A lock null resource is a resource and hence is a member > of whatever > collections it exists within. > Therefore to create a lock null resource as a level 1 > child of a collection > with a depth 0 lock one must have the depth 0 lock. > > In other words, yes, you must submit the token on the LOCK > on /foo/bar. > > Yaron > > > -----Original Message----- > > From: Joe Orton [mailto:joe@orton.demon.co.uk] > > Sent: Thu, December 30, 1999 6:45 AM > > To: w3c-dist-auth@w3.org > > Subject: Creating a lock-null in a locked collection > > > > > > I have an depth 0 write lock on /foo/. If I do LOCK /foo/bar > > to create a > > lock-null resource, do I need to submit the locktoken > for /foo/ in the > > LOCK request? Or only in the PUT to /foo/bar later? > > > > (Or is it decided that lock-null resources are going to go away?) > > > > joe > > > From w3c-dist-auth-request@w3.org Thu Dec 30 22:38:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15145 for ; Thu, 30 Dec 1999 22:38:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA03218; Thu, 30 Dec 1999 22:26:33 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 22:26:33 -0500 (EST) Resent-Message-Id: <199912310326.WAA03218@www19.w3.org> Date: Thu, 30 Dec 1999 22:26:21 -0500 Message-Id: <9912310326.AA16587@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619DE7@BEG.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: Locking URIs rather than Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3767 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I agree with all aspects of Yaron's interpretation of the "URL locking" proposal. It illustrates the fact that in this proposal, a LOCK (and UNLOCK) request never fails due to the absence of a Lock-Token header. A benefit of this approach can be seen if you invert the order in which the locks are issued, namely, instead of: LOCK /x; Depth:0 LOCK /x/y you request: LOCK /x/y LOCK /x; Depth:0 In the current 2518 model, the first sequence would fail (for the reason cited by Yaron) while the second would succeed (I believe ... with 2518, you probably could make good arguments for both failure and success of the second sequence). In contrast, the proposed URI locking model treats these sequences simply and identically: they both succeed, and they both end up in the same state - with a Depth:0 lock on /x and a Depth:infinity lock on /x/y. In this state, if you want to do a PUT to /x/y and /x/y does not identify a resource, you need both lock tokens (reasonably enough, since you are modifying the state of both /x and /x/y). Cheers, Geoff From: "Yaron Goland (Exchange)" Before I jump into the fray I want to make sure that I actually understand the proposal. One sentence in particular gave me pause for thought. Geoff stated that "...a LOCK request *never* requires a lock token". I though hard about this, trying to understand exactly what it meant. Below I lay out my thinking process so that if I have misunderstood the proposal my error can be found and corrected. Imagine user U takes out a depth 0 lock on collection C. Collection C has no children. The ramification is that no one but U may add a new child to C. User A then shows up and wants to create a new resource with the URL C/R. Before creating the resource, however, A would like to first reserve the name C/R. To this end A takes out a lock on C/R. In the old system A's request would be rejected. The reason is that in the old system locks are on resources. Therefore for A to lock the name C/R it has to create some resource which 'owns' C/R and then lock that resource. This is where lock-null resources came from. They are the 'stand-in' resource who holds the name C/R until A is ready to transfer ownership of the name to its final destination. However creating the lock-null resource to hold C/R means that the lock-null resource would automatically become a child of C. U, through its lock on C, has reserved the exclusive right to create children of C. Therefore A's request to lock C/R is rejected because the creation of the lock-null resource to hold the name C/R would violate U's lock on C. (Is it just me or does the previous sound like an Abbott and Castello routine? Castello: Who has the lock? Abbott: Who has the lock. Castello: No, who has the lock?!? Abott: Exactly.) But in the new proposal locks aren't on resources, they are on URIs. Therefore when A locks C/R it is not locking a resource, it is locking a name. Names aren't members of collections, resources are. Therefore A can lock C/R without running afoul of U's lock on C because C/R, even though it is locked, is still not a member of the collection. When A will run into trouble is when it attempts, through a COPY, MOVE, PROPPATCH, PUT, MKCOL, etc. to associate the URL C/R with a resource. By associating a resource with C/R A will cause that resource to become a member of C. Of course U has reserved the right to create new members of C, therefore A's request will be rejected. The result is that A can lock C/R without submitting a lock token. However there isn't much A can do with the lock on C/R because doing anything to it would require associating it with a resource, which U's lock prevents. Geoff, did I get it right? Yaron > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > > A lock can be placed on a URL with a LOCK request. This URL is called > the "lock base". If the lock is Depth:N, then a lock is induced on > any URL that consists of the lock base extended by N or fewer > segments. Only an authorized holder of a lock token for a locked URL > can modify either the state of the resource identified by the URL, or > which resource is identified by the URL. A URL MAY NOT be locked > with two exclusive locks with the same locktype. From w3c-dist-auth-request@w3.org Thu Dec 30 22:47:00 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15288 for ; Thu, 30 Dec 1999 22:46:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA03597; Thu, 30 Dec 1999 22:35:34 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 22:35:34 -0500 (EST) Resent-Message-Id: <199912310335.WAA03597@www19.w3.org> Date: Thu, 30 Dec 1999 22:35:23 -0500 Message-Id: <9912310335.AA16595@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <19991231003759.B4902@ankh.dunno.local> (message from Joe Orton on Fri, 31 Dec 1999 00:37:59 +0000) Subject: Re: Creating a lock-null in a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3768 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: Joe Orton ... It just seemed slightly weird, that if you LOCK or UNLOCK a lock-null resource, you are modifying the state of the parent collection; when if you do the same to a normal resource, you are not. Yes, that is one of the reasons I strongly object to the notion of a "lock null resource". It sometimes acts like a resource (modifies the parent collection), and sometimes does not (returns a 404 when you GET it). This makes it very hard to predict what its behavior should be whenever you extend the protocol (i.e. should it act like a resource, or act like not a resource). For example: - the BIND protocol (can you "BIND" a lock null resource to another URL?) - the versioning protocol (do you have to checkout a versioned collection in order to add a lock null resource to it?) Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Dec 30 23:25:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15502 for ; Thu, 30 Dec 1999 23:25:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA04208; Thu, 30 Dec 1999 23:15:00 -0500 (EST) Resent-Date: Thu, 30 Dec 1999 23:15:00 -0500 (EST) Resent-Message-Id: <199912310415.XAA04208@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256858.00174FF1.00@d54mta03.raleigh.ibm.com> Date: Thu, 30 Dec 1999 23:11:50 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Locking URIs rather than Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3769 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Names aren't members of collections, resources are. This is where you went wrong. Collections don't contain resources, their members are segments that are bound to some resource managed by the server. So from the point of view of locking, adding a member to a locked collection does require a lock token even if locks are on names only. From w3c-dist-auth-request@w3.org Fri Dec 31 01:04:01 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16784 for ; Fri, 31 Dec 1999 01:04:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA05413; Fri, 31 Dec 1999 00:53:10 -0500 (EST) Resent-Date: Fri, 31 Dec 1999 00:53:10 -0500 (EST) Resent-Message-Id: <199912310553.AAA05413@www19.w3.org> Date: Fri, 31 Dec 1999 00:53:00 -0500 Message-Id: <9912310553.AA16640@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <85256858.00174FF1.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: Locking URIs rather than Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3770 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: jamsden@us.ibm.com Names aren't members of collections, resources are. This is where you went wrong. Collections don't contain resources, their members are segments that are bound to some resource managed by the server. So from the point of view of locking, adding a member to a locked collection does require a lock token even if locks are on names only. I agree that the statement "names aren't members of collections" is problematic (the term "member" is ambiguous, since 2518 uses both the term "member URI" and the term "member resource"), but I don't see that Yaron went wrong in any way. He said that in the "URL locking" model, placing a lock on a URL does not add a new member to a collection, and therefore does not affect the state of the collection, and therefore does not require the lock token. I agree with all this. Note that Yaron was not saying that he approved of the URL locking model, but rather was just making sure he understood what was being proposed before commenting on it (a highly commendable modus operandi). Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Dec 31 14:55:27 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05054 for ; Fri, 31 Dec 1999 14:55:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA11727; Fri, 31 Dec 1999 14:37:26 -0500 (EST) Resent-Date: Fri, 31 Dec 1999 14:37:26 -0500 (EST) Resent-Message-Id: <199912311937.OAA11727@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256858.006BBEFD.00@d54mta03.raleigh.ibm.com> Date: Thu, 30 Dec 1999 23:41:03 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Locking URIs rather than Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3771 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Geoff, I didn't follow. Is y a lock-null resource in your example below? It seems according to your definition below that the URL lock scheme would have the same behavior as 2518. If y is a lock-null resource: LOCK /x; Depth:0 LOCK /x/y LOCK /x/y LOCK /x; Depth:0 In the first sequence, the LOCK /x/y request fails (assuming the lock token is not specified or the user is not the owner of the lock) because x is locked and y can't be created in x either as a name or resource with /x/y bound to it. The second sequence, both methods succeed because x isn't locked, so y can be created, lock-null or not. Now x can be locked with depth:0 because there are no conflicting locks. What am I missing? Or are you just saying that LOCK doesn't require a lock token? Why the special case? What happened to your proposal to remove lock-null resources? Now consider the case where y isn't a lock-null resource, but an existing resource. The first sequence could succeed without a lock-token on /x because locking /x/y doesn't change the state of /x in any way. The second sequence would also succeed. Is this what you meant? If we don't have lock-null resources, how will names be reserved? Don't worry about the issue? Now some locking questions. If LOCK applies to the name, not the resource, /x/y.htm is locked, and /b/c.htm is bound to the same resource as /x/y.htm, is /b/c.htm locked too? Probably not. A user not owning the lock on /x/y.htm could DELETE /b/c.htm since that URL isn't locked. What about LOCK /b/c.htm? Say some other user would like this URL to remain fixed, but doesn't want to change the contents of the resource. Would that fail due to a conflict with the lock on /x/y.htm? Probably should. Now what if a user not owning the lock does a PUT on /b/c.htm. According to the definition below, this would fail even though the URL isn't locked. So the user can do a delete, but not a put on /b/c.htm. Sounds a little confusing. Looks like the lock is on both the name and the resource in some way. "Geoffrey M. Clemm" @w3.org on 12/30/99 10:26:21 PM Sent by: w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: Locking URIs rather than Resources I agree with all aspects of Yaron's interpretation of the "URL locking" proposal. It illustrates the fact that in this proposal, a LOCK (and UNLOCK) request never fails due to the absence of a Lock-Token header. A benefit of this approach can be seen if you invert the order in which the locks are issued, namely, instead of: LOCK /x; Depth:0 LOCK /x/y you request: LOCK /x/y LOCK /x; Depth:0 In the current 2518 model, the first sequence would fail (for the reason cited by Yaron) while the second would succeed (I believe ... with 2518, you probably could make good arguments for both failure and success of the second sequence). In contrast, the proposed URI locking model treats these sequences simply and identically: they both succeed, and they both end up in the same state - with a Depth:0 lock on /x and a Depth:infinity lock on /x/y. In this state, if you want to do a PUT to /x/y and /x/y does not identify a resource, you need both lock tokens (reasonably enough, since you are modifying the state of both /x and /x/y). Cheers, Geoff From: "Yaron Goland (Exchange)" Before I jump into the fray I want to make sure that I actually understand the proposal. One sentence in particular gave me pause for thought. Geoff stated that "...a LOCK request *never* requires a lock token". I though hard about this, trying to understand exactly what it meant. Below I lay out my thinking process so that if I have misunderstood the proposal my error can be found and corrected. Imagine user U takes out a depth 0 lock on collection C. Collection C has no children. The ramification is that no one but U may add a new child to C. User A then shows up and wants to create a new resource with the URL C/R. Before creating the resource, however, A would like to first reserve the name C/R. To this end A takes out a lock on C/R. In the old system A's request would be rejected. The reason is that in the old system locks are on resources. Therefore for A to lock the name C/R it has to create some resource which 'owns' C/R and then lock that resource. This is where lock-null resources came from. They are the 'stand-in' resource who holds the name C/R until A is ready to transfer ownership of the name to its final destination. However creating the lock-null resource to hold C/R means that the lock-null resource would automatically become a child of C. U, through its lock on C, has reserved the exclusive right to create children of C. Therefore A's request to lock C/R is rejected because the creation of the lock-null resource to hold the name C/R would violate U's lock on C. (Is it just me or does the previous sound like an Abbott and Castello routine? Castello: Who has the lock? Abbott: Who has the lock. Castello: No, who has the lock?!? Abott: Exactly.) But in the new proposal locks aren't on resources, they are on URIs. Therefore when A locks C/R it is not locking a resource, it is locking a name. Names aren't members of collections, resources are. Therefore A can lock C/R without running afoul of U's lock on C because C/R, even though it is locked, is still not a member of the collection. When A will run into trouble is when it attempts, through a COPY, MOVE, PROPPATCH, PUT, MKCOL, etc. to associate the URL C/R with a resource. By associating a resource with C/R A will cause that resource to become a member of C. Of course U has reserved the right to create new members of C, therefore A's request will be rejected. The result is that A can lock C/R without submitting a lock token. However there isn't much A can do with the lock on C/R because doing anything to it would require associating it with a resource, which U's lock prevents. Geoff, did I get it right? Yaron > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > > A lock can be placed on a URL with a LOCK request. This URL is called > the "lock base". If the lock is Depth:N, then a lock is induced on > any URL that consists of the lock base extended by N or fewer > segments. Only an authorized holder of a lock token for a locked URL > can modify either the state of the resource identified by the URL, or > which resource is identified by the URL. A URL MAY NOT be locked > with two exclusive locks with the same locktype. From w3c-dist-auth-request@w3.org Fri Dec 31 16:57:41 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06159 for ; Fri, 31 Dec 1999 16:57:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA13106; Fri, 31 Dec 1999 16:34:59 -0500 (EST) Resent-Date: Fri, 31 Dec 1999 16:34:59 -0500 (EST) Resent-Message-Id: <199912312134.QAA13106@www19.w3.org> Date: Fri, 31 Dec 1999 16:34:47 -0500 Message-Id: <9912312134.AA16809@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <85256858.006BBEFD.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: Locking URIs rather than Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3772 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: jamsden@us.ibm.com Is y a lock-null resource in your example below? In the "URL locking" proposal, there is no such thing as a lock-null resource. A lock is on a URL. At any given moment, a URL may or may not identify a resource. A lock can be placed on a URL independent of whether or not that URL currently identifies a resource. So there is a lock on the URL /x/y, but there is no resource identified by /x/y (lock null or otherwise). It seems according to your definition below that the URL lock scheme would have the same behavior as 2518. In most ways, but not in this case (i.e. whether or not the sequence: LOCK /x; Depth:0 LOCK /x/y succeeds or fails. If y is a lock-null resource: LOCK /x; Depth:0 LOCK /x/y LOCK /x/y LOCK /x; Depth:0 In the first sequence, the LOCK /x/y request fails (assuming the lock token is not specified or the user is not the owner of the lock) because x is locked and y can't be created in x either as a name or resource with /x/y bound to it. But if locks are on URL's, then "LOCK /x/y" never creates a resource (lock null or otherwise), so no modification is made to the state of /x, so no lock token is required. The second sequence, both methods succeed because x isn't locked, so y can be created, lock-null or not. Now x can be locked with depth:0 because there are no conflicting locks. What am I missing? The only thing you are missing is that a depth:0 lock on /x is not relevant to placing a lock on /x/y. Or are you just saying that LOCK doesn't require a lock token? Yes, because a LOCK never modifies the state of any resource, so a lock request can never require a lock token to succeed. Why the special case? No special case. Just follows from the definition of a write lock. What happened to your proposal to remove lock-null resources? I am still against lock null resources. I am willing to accept locks on URL's, and locks on URL's that currently do not identify a resource. Now consider the case where y isn't a lock-null resource, but an existing resource. The first sequence could succeed without a lock-token on /x because locking /x/y doesn't change the state of /x in any way. The second sequence would also succeed. Is this what you meant? This is true, but not the use case I was referring to (i.e. where /x/y does not currently identify a resource). If we don't have lock-null resources, how will names be reserved? Don't worry about the issue? You can reserve names, but you don't use lock-null resources to do so. Now some locking questions. If LOCK applies to the name, not the resource, /x/y.htm is locked, and /b/c.htm is bound to the same resource as /x/y.htm, is /b/c.htm locked too? Probably not. Correct. But modifying the resource identified by /b/c.htm does require the lock token for the /x/y.htm lock. This does not make /b/c.htm locked. A user not owning the lock on /x/y.htm could DELETE /b/c.htm since that URL isn't locked. Correct. The DELETE of /b/c.htm modifies the state of /b and causes /b/c.htm to no longer identify a resource. What about LOCK /b/c.htm? That is fine. Say some other user would like this URL to remain fixed, but doesn't want to change the contents of the resource. If by "fixed" you mean ensure that it identify the same resource, then you would LOCK it (and this wouldn't change the contents of the resource). Would that fail due to a conflict with the lock on /x/y.htm? Probably should. Not at all. One user has /x/y.htm locked. The other user has /b/c.htm locked. That means you can't modify that resource unless you have both lock tokens. In this model, a LOCK prevents a certain kind of change to something, but does *not* guarantee the ability to make such a change, since other access rights or locks can come into play. Now what if a user not owning the lock does a PUT on /b/c.htm. According to the definition below, this would fail even though the URL isn't locked. So the user can do a delete, but not a put on /b/c.htm. Sounds a little confusing. I don't see why. Being able to add or remove something from a collection is very different from being able to modify its state. Looks like the lock is on both the name and the resource in some way. A lock is on a URL. The *purpose* of a lock on a URL is to control: - what resource is identified by that URL - the state of the resource identified by the URL. Cheers, Geoff "Geoffrey M. Clemm" @w3.org on 12/30/99 10:26:21 PM Sent by: w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: Locking URIs rather than Resources I agree with all aspects of Yaron's interpretation of the "URL locking" proposal. It illustrates the fact that in this proposal, a LOCK (and UNLOCK) request never fails due to the absence of a Lock-Token header. A benefit of this approach can be seen if you invert the order in which the locks are issued, namely, instead of: LOCK /x; Depth:0 LOCK /x/y you request: LOCK /x/y LOCK /x; Depth:0 In the current 2518 model, the first sequence would fail (for the reason cited by Yaron) while the second would succeed (I believe ... with 2518, you probably could make good arguments for both failure and success of the second sequence). In contrast, the proposed URI locking model treats these sequences simply and identically: they both succeed, and they both end up in the same state - with a Depth:0 lock on /x and a Depth:infinity lock on /x/y. In this state, if you want to do a PUT to /x/y and /x/y does not identify a resource, you need both lock tokens (reasonably enough, since you are modifying the state of both /x and /x/y). Cheers, Geoff From: "Yaron Goland (Exchange)" Before I jump into the fray I want to make sure that I actually understand the proposal. One sentence in particular gave me pause for thought. Geoff stated that "...a LOCK request *never* requires a lock token". I though hard about this, trying to understand exactly what it meant. Below I lay out my thinking process so that if I have misunderstood the proposal my error can be found and corrected. Imagine user U takes out a depth 0 lock on collection C. Collection C has no children. The ramification is that no one but U may add a new child to C. User A then shows up and wants to create a new resource with the URL C/R. Before creating the resource, however, A would like to first reserve the name C/R. To this end A takes out a lock on C/R. In the old system A's request would be rejected. The reason is that in the old system locks are on resources. Therefore for A to lock the name C/R it has to create some resource which 'owns' C/R and then lock that resource. This is where lock-null resources came from. They are the 'stand-in' resource who holds the name C/R until A is ready to transfer ownership of the name to its final destination. However creating the lock-null resource to hold C/R means that the lock-null resource would automatically become a child of C. U, through its lock on C, has reserved the exclusive right to create children of C. Therefore A's request to lock C/R is rejected because the creation of the lock-null resource to hold the name C/R would violate U's lock on C. (Is it just me or does the previous sound like an Abbott and Castello routine? Castello: Who has the lock? Abbott: Who has the lock. Castello: No, who has the lock?!? Abott: Exactly.) But in the new proposal locks aren't on resources, they are on URIs. Therefore when A locks C/R it is not locking a resource, it is locking a name. Names aren't members of collections, resources are. Therefore A can lock C/R without running afoul of U's lock on C because C/R, even though it is locked, is still not a member of the collection. When A will run into trouble is when it attempts, through a COPY, MOVE, PROPPATCH, PUT, MKCOL, etc. to associate the URL C/R with a resource. By associating a resource with C/R A will cause that resource to become a member of C. Of course U has reserved the right to create new members of C, therefore A's request will be rejected. The result is that A can lock C/R without submitting a lock token. However there isn't much A can do with the lock on C/R because doing anything to it would require associating it with a resource, which U's lock prevents. Geoff, did I get it right? Yaron > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > > A lock can be placed on a URL with a LOCK request. This URL is called > the "lock base". If the lock is Depth:N, then a lock is induced on > any URL that consists of the lock base extended by N or fewer > segments. Only an authorized holder of a lock token for a locked URL > can modify either the state of the resource identified by the URL, or > which resource is identified by the URL. A URL MAY NOT be locked > with two exclusive locks with the same locktype. From w3c-dist-auth-request@w3.org Fri Dec 31 18:40:01 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07329 for ; Fri, 31 Dec 1999 18:40:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA14184; Fri, 31 Dec 1999 18:22:29 -0500 (EST) Resent-Date: Fri, 31 Dec 1999 18:22:29 -0500 (EST) Resent-Message-Id: <199912312322.SAA14184@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <05256858.00804FA6.00@D51MTA03.pok.ibm.com> Date: Fri, 31 Dec 1999 18:22:06 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Locking URIs rather than Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3773 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Now some locking questions. If LOCK applies to the name, not the resource, /x/y.htm is locked, and /b/c.htm is bound to the same resource as /x/y.htm, is /b/c.htm locked too? Probably not. Correct. But modifying the resource identified by /b/c.htm does require the lock token for the /x/y.htm lock. This does not make /b/c.htm locked. Geoff, you agreed that "/b/c.html" is not locked. In this case I think we'd preferably say the "the resource at" either/both URI's is locked... but only one of those URI's is locked. My point is that we should probably come up clearer vocabulary/notation for making a distinction between the URI and the resource. For example, we used to say the URI was protected and/or the resource was locked. ... What about LOCK /b/c.htm? That is fine. Hmmm. Jim said they are the same resource. I don't think he meant a null-mapped resource. That being the case, I think you mean to say that the second lock can only be placed if it doesn't conflict with the lock already acting on the resource at that URI. I think you must have assumed he meant a shared lock when you said that is fine. Not at all. One user has /x/y.htm locked. The other user has /b/c.htm locked. That means you can't modify that resource unless you have both lock tokens. In this model, a LOCK prevents a certain kind of change to something, but does *not* guarantee the ability to make such a change, since other access rights or locks can come into play. I agree with what you said about not guarantee'ing a right to change, but what about requiring two tokens? As far as I know, the situation you outlined can only happen if shared locks are used. In that case, only one lock token is required.