From w3c-dist-auth-request@w3.org Wed Mar 1 13:32:23 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10080 for ; Wed, 1 Mar 2000 13:32:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11894; Wed, 1 Mar 2000 13:24:36 -0500 (EST) Resent-Date: Wed, 1 Mar 2000 13:24:36 -0500 (EST) Resent-Message-Id: <200003011824.NAA11894@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 1 Mar 2000 10:18:57 -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: Redirect References Issues List Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4174 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 Based on the comments received from the working group last call on the Redirect References protocol, Judy Slein has prepared an issues list, with links off to the original email messages, available at: http://www.ics.uci.edu/pub/ietf/webdav/collection/redirect-issues.html - Jim From w3c-dist-auth-request@w3.org Wed Mar 1 16:14:40 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13301 for ; Wed, 1 Mar 2000 16:14:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA24445; Wed, 1 Mar 2000 16:08:33 -0500 (EST) Resent-Date: Wed, 1 Mar 2000 16:08:33 -0500 (EST) Resent-Message-Id: <200003012108.QAA24445@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 1 Mar 2000 13:02:50 -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: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4175 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 Advanced Collections Teleconference March 1, 2000 Present: Chuck Fay, Geoff Clemm, Judy Slein, Jim Whitehead, Jason Crawford Minutes recorded by Jim Whitehead *** Note that decisions made during the teleconference are always subject to review on the mailing list. The mailing list is the final arbiter of consensus on any issue. Note also, that the revised Bindings Protocol specification, and Redirect References protocol produced as a result of this conference call will also be subject to review by the mailing list. *** Bindings protocol issues: Geoff Clemm read some language for delete on bindings. Discussed introducing an UNBIND method. Some concern over the "mixed mode" case, where say collections are not bindable, but non-collection resources are. Geoff will send some proposed language out on this. Issue 7 (Yaron5.3Huh?): Agreed that Geoff's new language, in http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0392.html, will be proposed as a substitute for the current language. Major change is to bulletize existing text, spelling out the existing text more clearly. No change to issue 8, since we feel this will be clear after the change to 5.3. Discussion on feedback from Roy on the nature of resources. Then discussed the dav:resourceid, whch seems to be his last major concern. Discussed having a check for equivalence method, and having an identifier for the set of URLs mapped to a particular resource. Also discussed having a URN instead of the dav:resourceid. Discussed whether the property should be required. Agreed to have a URN instead of a dav:resourceid, this will be accessible in a property, which is a SHOULD implement, not a MUST (due to filesystem implementation such as WebRFM), as well as a separate method that returns a boolean, yes/no, for two URLs mapping/not mapping to the same resource. Discussion on whether the bindings property should be called the mappings property. Concern that the "bindings" name on the bound-to resource might suggest that the individual resource holds the state of the bindings, rather than the collection. Thus, some name like "binder", or "bindings-to" might be more appropriate. Geoff will submit some name ideas for this. Redirect References protocol: Issue #1: Discussion over whether redirect resources should or should not have bodies. There don't appear to be compelling reasons for having this capability. It does add complexity to the protocol, and to implementations. So, agreement that a redirect reference MUST NOT have a body. Agreement to Yaron's proposal that Redirect Resources should be authorable on non-WebDAV servers, by non-WebDAV clients. Issue #1A: Issue goes away, since MKRESOURCE will be replaced by MKREF. Issue #2: Use policy from Binding protocol for listing status codes. Issue #3: Yes, change caching to MUST NOT cache response from MKREF/MKRESOURCE. Issue #4, 5: Not relevant once we switch to MKREF. Issue #6: Need to add rationale for why we use relative URLs. Server is required to store it as a relative URL. Server MUST NOT change the relative URL during a MOVE. Raises the issue of needing separate methods for getting the value of a reference, and modifying the value of a reference. Tentatively agreed on REFGET, REFSET (but noone likes these too much). Issue #7, 8, 9: Agreed that we will remove cross references between specs. Also will remove any mention of other specifications, since this is now intended to be a standalone specification. Will expand discussion of redirect references. Agreed to move notational conventions after the introduction. Issue #10: Will use "revealing private locations" instead. Issue #11: Will continue to follow IETF rules, but will try to produce a nicely formatted specification as well for review. Issue #12: Agreed, although these paragraphs will end up being changed due to the move to make this a standalone specification. Issue #13: Accepted change. Issue #14: Agreement that we won't discuss bindings at all in the redirect references specification. Issue #15: Agreement that we won't mention Direct Reference Resources in the specification. Probably also means that the definition of Reference goes away as well. Some discussion of whether to allow authoring of other than 302 redirects. 303, 304, and 305 don't seem to make sense for remote authoring. 303 is intended for POST output. 304 is for conditional GET requests. 305 says to use a proxy to access a resource (though perhaps this would be useful to author). 300 would involve sending the multiple choices when the resource was created, and would complicate MKREF. Next week's teleconference: Tuesday at 11-1 Pacific. *** End of teleconference *** From w3c-dist-auth-request@w3.org Wed Mar 1 16:38:38 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13771 for ; Wed, 1 Mar 2000 16:38:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA26129; Wed, 1 Mar 2000 16:33:24 -0500 (EST) Resent-Date: Wed, 1 Mar 2000 16:33:24 -0500 (EST) Resent-Message-Id: <200003012133.QAA26129@www19.w3.org> Date: Wed, 1 Mar 2000 13:35:50 -0800 (PST) From: Greg Stein To: WebDAV WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4176 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 Wed, 1 Mar 2000, Jim Whitehead wrote: >... > Some discussion of whether to allow authoring of other than 302 redirects. > 303, 304, and 305 don't seem to make sense for remote authoring. 303 is > intended for POST output. 304 is for conditional GET requests. 305 says to > use a proxy to access a resource (though perhaps this would be useful to > author). 300 would involve sending the multiple choices when the resource > was created, and would complicate MKREF. I'd like to be able to author 301 (Moved Permanently) redirects. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Mar 1 19:13:17 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18549 for ; Wed, 1 Mar 2000 19:13:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA03931; Wed, 1 Mar 2000 19:06:12 -0500 (EST) Resent-Date: Wed, 1 Mar 2000 19:06:12 -0500 (EST) Resent-Message-Id: <200003020006.TAA03931@www19.w3.org> Date: Thu, 2 Mar 2000 00:04:32 +0000 From: Joe Orton To: WebDAV WG Message-ID: <20000302000432.B1058@ankh.dunno.local> Mail-Followup-To: WebDAV WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from ejw@ics.uci.edu on Wed, Mar 01, 2000 at 01:02:50PM -0800 Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4177 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > Issue #6: Need to add rationale for why we use relative URLs. Server is > required to store it as a relative URL. Server MUST NOT change the relative > URL during a MOVE. > > Raises the issue of needing separate methods for getting the value of a > reference, and modifying the value of a reference. Tentatively agreed on > REFGET, REFSET (but noone likes these too much). The original -00 spec allowed MKREF with Overwrite, could this be used instead of REFSET? joe From w3c-dist-auth-request@w3.org Thu Mar 2 17:39:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00159 for ; Thu, 2 Mar 2000 17:39:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA07696; Thu, 2 Mar 2000 17:30:29 -0500 (EST) Resent-Date: Thu, 2 Mar 2000 17:30:29 -0500 (EST) Resent-Message-Id: <200003022230.RAA07696@www19.w3.org> Date: Thu, 2 Mar 2000 14:32:56 -0800 (PST) From: Greg Stein To: Jim Whitehead cc: WebDAV WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Redirect References Issues List Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4178 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 Wed, 1 Mar 2000, Jim Whitehead wrote: > Based on the comments received from the working group last call on the > Redirect References protocol, Judy Slein has prepared an issues list, with > links off to the original email messages, available at: > > http://www.ics.uci.edu/pub/ietf/webdav/collection/redirect-issues.html This is now linked off the WebDAV specs page at: http://www.webdav.org/specs/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Mar 2 18:03:44 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00924 for ; Thu, 2 Mar 2000 18:03:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA09116; Thu, 2 Mar 2000 17:56:14 -0500 (EST) Resent-Date: Thu, 2 Mar 2000 17:56:14 -0500 (EST) Resent-Message-Id: <200003022256.RAA09116@www19.w3.org> Date: Thu, 2 Mar 2000 14:58:43 -0800 (PST) From: Greg Stein To: Yaron Goland cc: "W3c-Dist-Auth (E-mail)" In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED0261A197@BEG.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: The WebDAV Book of Why - V. Alpha 3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4179 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 Thu, 17 Feb 2000, Yaron Goland wrote: > The WebDAV Book of Why > > V.Alpha 3 - 2/17/2000 2:39 PM >... The WebDAV Book of Why at http://www.webdav.org/papers/#misc has now been updated. Thanx for the updates, Yaron! Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Mar 2 23:34:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06552 for ; Thu, 2 Mar 2000 23:34:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA15485; Thu, 2 Mar 2000 23:29:29 -0500 (EST) Resent-Date: Thu, 2 Mar 2000 23:29:29 -0500 (EST) Resent-Message-Id: <200003030429.XAA15485@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256897.0018A134.00@d54mta03.raleigh.ibm.com> Date: Thu, 2 Mar 2000 23:20:03 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Case sensitive names and authoring Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4180 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 URLs aren't case sensitive, but some resources are. For example, Java source managed by a WebDAV server must retain the case in the package and class names or the code won't compile. mod_dav foldes all resource names to lower case, so .java files on the server won't compile. It seems that WebDAV could, like HTTP, be case insensitive while at the same time require that the server retain the case of resource URLs. That is, the URL segments in the bindings would retain the case in the target when it was entered, but access to those resources would be case insensitive. If this is not the case, WebDAV can't be used to store Java. That would be a real bummer! Would the proposal above be acceptable, and in the spirit of HTTP? From w3c-dist-auth-request@w3.org Thu Mar 2 23:58:36 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06795 for ; Thu, 2 Mar 2000 23:58:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA15771; Thu, 2 Mar 2000 23:53:33 -0500 (EST) Resent-Date: Thu, 2 Mar 2000 23:53:33 -0500 (EST) Resent-Message-Id: <200003030453.XAA15771@www19.w3.org> Date: Thu, 2 Mar 2000 20:56:11 -0800 (PST) From: Greg Stein To: jamsden@us.ibm.com cc: w3c-dist-auth@w3.org In-Reply-To: <85256897.0018A134.00@d54mta03.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Case sensitive names and authoring Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4181 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 Thu, 2 Mar 2000 jamsden@us.ibm.com wrote: > > HTTP URLs aren't case sensitive, RFC 2616, S3.2.3 states "When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: ..." In other words: they *are* case-sensitive. Apache certainly treats them that way. Try these two URLs: http://www.webdav.org/other/proxy.html http://www.webdav.org/other/Proxy.html You'll find the latter fails. Note that HTTP servers running on an MSFT platform typically treat URLs in a case-insensitive fashion (due to the filesystem being insensitive). > but some resources are. For example, Java > source managed by a WebDAV server must retain the case in the package and > class names or the code won't compile. mod_dav foldes all resource names to > lower case, so .java files on the server won't compile. WHAT?!! mod_dav does NOT do any case-folding. Euh... what made you think it does? > It seems that WebDAV could, like HTTP, be case insensitive while at the > same time require that the server retain the case of resource URLs. That > is, the URL segments in the bindings would retain the case in the target > when it was entered, but access to those resources would be case > insensitive. If this is not the case, WebDAV can't be used to store Java. > That would be a real bummer! > > Would the proposal above be acceptable, and in the spirit of HTTP? No and no. (IMO) I certainly do not want to take the performance hit to start doing case-insensitive work in mod_dav and Apache. I am in great favor of continuing to operate in a case-sensitive fashion, and I believe the relevant RFCs encourage that, too. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Mar 3 06:23:48 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22402 for ; Fri, 3 Mar 2000 06:23:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA22400; Fri, 3 Mar 2000 06:19:22 -0500 (EST) Resent-Date: Fri, 3 Mar 2000 06:19:22 -0500 (EST) Resent-Message-Id: <200003031119.GAA22400@www19.w3.org> Message-ID: <38BFA154.BBC26AD1@Golux.Com> Date: Fri, 03 Mar 2000 06:26:12 -0500 From: Rodent of Unusual Size Organization: The Apache Software Foundation X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <85256897.0018A134.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Case sensitive names and authoring Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4182 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 jamsden@us.ibm.com wrote: > > HTTP URLs aren't case sensitive Eh??? Rubbish. The scheme isn't, the net_loc portion isn't, but absolutely the rest of the URI is opaque and must be treated as case-sensitive. It ought to be treated as a set of octets, but we can use the 'case' nomenclature because we know the URI character set limitations. -- #ken P-)} Ken Coar Apache Software Foundation "Apache Server for Dummies" Come to the first official Apache Software Foundation Conference! From w3c-dist-auth-request@w3.org Fri Mar 3 07:13:53 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23701 for ; Fri, 3 Mar 2000 07:13:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA24006; Fri, 3 Mar 2000 07:09:35 -0500 (EST) Resent-Date: Fri, 3 Mar 2000 07:09:35 -0500 (EST) Resent-Message-Id: <200003031209.HAA24006@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256897.0042C4B7.00@d54mta03.raleigh.ibm.com> Date: Fri, 3 Mar 2000 07:09:11 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id HAA23986 Subject: Re: Case sensitive names and authoring Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4183 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: 8bit Greg, This is great. I didn't have an HTTP spec in front of me when I wrote the note (need to get one by the bed I guess). We're probably running into the MSFT problem. Maybe this doesn't happen on Windows2000 which seems to leave you file names alone a little better. I'll investigate. |------------------------+------------------------> | | Greg Stein | | | | | | | | | 03/02/2000 11:56 PM | | | | |------------------------+------------------------> >------------------------| | | |         To: | | Jim | | Amsden/Raleigh/IBM@IB| | MUS | |         cc: | | w3c-dist-auth@w3.org | |         Subject: | | Re: Case sensitive | | names and authoring | >------------------------| On Thu, 2 Mar 2000 jamsden@us.ibm.com wrote: > > HTTP URLs aren't case sensitive, RFC 2616, S3.2.3 states "When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: ..." In other words: they *are* case-sensitive. Apache certainly treats them that way. Try these two URLs:   http://www.webdav.org/other/proxy.html  http://www.webdav.org/other/Proxy.html You'll find the latter fails. Note that HTTP servers running on an MSFT platform typically treat URLs in a case-insensitive fashion (due to the filesystem being insensitive). > but some resources are. For example, Java > source managed by a WebDAV server must retain the case in the package and > class names or the code won't compile. mod_dav foldes all resource names to > lower case, so .java files on the server won't compile. WHAT?!!  mod_dav does NOT do any case-folding. Euh... what made you think it does? > It seems that WebDAV could, like HTTP, be case insensitive while at the > same time require that the server retain the case of resource URLs. That > is, the URL segments in the bindings would retain the case in the target > when it was entered, but access to those resources would be case > insensitive. If this is not the case, WebDAV can't be used to store Java. > That would be a real bummer! > > Would the proposal above be acceptable, and in the spirit of HTTP? No and no.  (IMO) I certainly do not want to take the performance hit to start doing case-insensitive work in mod_dav and Apache. I am in great favor of continuing to operate in a case-sensitive fashion, and I believe the relevant RFCs encourage that, too. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Mar 3 09:57:31 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29211 for ; Fri, 3 Mar 2000 09:57:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA29583; Fri, 3 Mar 2000 09:52:01 -0500 (EST) Resent-Date: Fri, 3 Mar 2000 09:52:01 -0500 (EST) Resent-Message-Id: <200003031452.JAA29583@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F984@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Joe Orton'" , WebDAV WG Date: Fri, 3 Mar 2000 09:51:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4184 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's certainly a possibility. The only problem I can see with relying on MKREF is that it would not just update the target, but would replace the resource with a new resource. That's probably harmless if it's an HTTP resource with no properties, but if it is a WebDAV resource it might have properties that you would like to preserve while updating its target. --Judy -----Original Message----- From: Joe Orton [mailto:joe@orton.demon.co.uk] Sent: Wednesday, March 01, 2000 7:05 PM To: WebDAV WG Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > Issue #6: Need to add rationale for why we use relative URLs. Server is > required to store it as a relative URL. Server MUST NOT change the relative > URL during a MOVE. > > Raises the issue of needing separate methods for getting the value of a > reference, and modifying the value of a reference. Tentatively agreed on > REFGET, REFSET (but noone likes these too much). The original -00 spec allowed MKREF with Overwrite, could this be used instead of REFSET? joe From w3c-dist-auth-request@w3.org Fri Mar 3 13:43:22 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05997 for ; Fri, 3 Mar 2000 13:43:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA09892; Fri, 3 Mar 2000 13:34:39 -0500 (EST) Resent-Date: Fri, 3 Mar 2000 13:34:39 -0500 (EST) Resent-Message-Id: <200003031834.NAA09892@www19.w3.org> Message-ID: <012d01bf853e$d8bbb4f0$9a114498@us.oracle.com> From: "Eric Sedlar" To: , References: <85256897.0042C4B7.00@d54mta03.raleigh.ibm.com> Date: Fri, 3 Mar 2000 10:32:34 -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: Case sensitive names and authoring Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4185 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 One possibility we're toying with is to store a boolean property with a collection resource indicating whether or not its bindings are case-sensitive or case-insensitive. For example, it might be the case that part of your hierarchical namespace is implementing Windows filesystem semantics, which require case-insensitive matching (although they are case-preserving), and another part implementing UNIX filesystem semantics. Otherwise, there will always be some loss of information when moving data in and out of the WebDAV server. --Eric ----- Original Message ----- From: To: Sent: Friday, March 03, 2000 4:09 AM Subject: Re: Case sensitive names and authoring Greg, This is great. I didn't have an HTTP spec in front of me when I wrote the note (need to get one by the bed I guess). We're probably running into the MSFT problem. Maybe this doesn't happen on Windows2000 which seems to leave you file names alone a little better. I'll investigate. On Thu, 2 Mar 2000 jamsden@us.ibm.com wrote: > > HTTP URLs aren't case sensitive, RFC 2616, S3.2.3 states "When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: ..." In other words: they *are* case-sensitive. Apache certainly treats them that way. Try these two URLs: http://www.webdav.org/other/proxy.html http://www.webdav.org/other/Proxy.html You'll find the latter fails. Note that HTTP servers running on an MSFT platform typically treat URLs in a case-insensitive fashion (due to the filesystem being insensitive). > but some resources are. For example, Java > source managed by a WebDAV server must retain the case in the package and > class names or the code won't compile. mod_dav foldes all resource names to > lower case, so .java files on the server won't compile. WHAT?!! mod_dav does NOT do any case-folding. Euh... what made you think it does? > It seems that WebDAV could, like HTTP, be case insensitive while at the > same time require that the server retain the case of resource URLs. That > is, the URL segments in the bindings would retain the case in the target > when it was entered, but access to those resources would be case > insensitive. If this is not the case, WebDAV can't be used to store Java. > That would be a real bummer! > > Would the proposal above be acceptable, and in the spirit of HTTP? No and no. (IMO) I certainly do not want to take the performance hit to start doing case-insensitive work in mod_dav and Apache. I am in great favor of continuing to operate in a case-sensitive fashion, and I believe the relevant RFCs encourage that, too. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Mar 3 15:53:06 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08930 for ; Fri, 3 Mar 2000 15:53:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA19989; Fri, 3 Mar 2000 15:46:50 -0500 (EST) Resent-Date: Fri, 3 Mar 2000 15:46:50 -0500 (EST) Resent-Message-Id: <200003032046.PAA19989@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org Message-ID: <85256897.00721822.00@d54mta03.raleigh.ibm.com> Date: Fri, 3 Mar 2000 15:45:48 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: 47th IETF: DRAFT AGENDA Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4186 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hope to see many of you there! ----- Forwarded by Jim Amsden/Raleigh/IBM on 03/03/2000 03:44 PM ----- |--------+--------------------------> | | agenda@ietf.org | | | Sent by: | | | mbeaulie@cnri.re| | | ston.va.us | | | | | | | | | 03/02/2000 03:16| | | PM | | | | |--------+--------------------------> >------------------------------------------------------------| | | | To: wgchairs@ietf.org, bofchairs@ietf.org | | cc: | | Subject: 47th IETF: DRAFT AGENDA | >------------------------------------------------------------| Here is the latest agenda. Changes have been made since the last posted agenda. This agenda is still a draft and subject to change. REMINDER: Agenda scheduling closes tomorrow, Friday, March 3 at 1700 ET. Agendas for the working groups are due by March 17 at 1200 ET (BOF agendas are due at time of request). ++++++++++++++++++++++++++++++++++++++++++++++++++ This is a Draft Agenda and is subject to change. ++++++++++++++++++++++++++++++++++++++++++++++++++ Draft Agenda of the Forty-seventh IETF March 26-31, 2000 As of 3/2/00 WEDNESDAY, March 29, 2000 0800-1700 IETF Registration - Foyer 1 0800-0900 Continental Breakfast - Foyer and Circulation Area 0900-1130 Morning Sessions APP deltav Web Versioning and Configuration Management WG * Designates Multicast Sessions AREA DIRECTORS APP Applications Keith Moore/UTK and Patrik Faltstrom/Tele2/Swipnet GEN General Interest Fred Baker/Cisco Systems INT Internet Thomas Narten/IBM Corp. and Erik Nordmark/Sun Microsystems OPS Operations & Management Randy Bush/Verio, Inc. and Bert Wijnen/IBM Netherlands RTG Routing Rob Coltun/Siara Systems and Dave Oran/Cisco Systems SEC Security Marcus Leech/Nortel and Jeff Schiller/MIT TSV Transport Scott Bradner/Harvard Univ. and Vern Paxson/ACIRI/LBNL USV User Services April Marine/Internet Engines, Inc. ========================================================================= From w3c-dist-auth-request@w3.org Fri Mar 3 16:24:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09836 for ; Fri, 3 Mar 2000 16:24:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA22707; Fri, 3 Mar 2000 16:17:16 -0500 (EST) Resent-Date: Fri, 3 Mar 2000 16:17:16 -0500 (EST) Resent-Message-Id: <200003032117.QAA22707@www19.w3.org> Date: Fri, 3 Mar 2000 13:19:44 -0800 (PST) From: Greg Stein To: w3c-dist-auth@w3.org cc: new-httpd@apache.org In-Reply-To: <85256897.0042C4B7.00@d54mta03.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by www19.w3.org id QAA22684 Subject: Re: Case sensitive names and authoring Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4187 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: 8bit I'll backtrack from my statement just a bit... :-) Tim Ellison sent me an off-list email saying that Apache 1.3.6 and mod_dav 0.9.15 on WinNT 4.0 SP5 *does* case-fold on a PUT. I just tracked this down. While mod_dav doesn't do the case-folding, Apache *does*. Thus, when mod_dav gets to the filename, it has been munged to the lower-cased form. [ specifically: http_request.c, line 401 in the CVS version ] IMO, I call this a bug in Apache. The protocol and behaviors should be case-sensitive. I'm not sure how/when Apache will be fixed, but we'll look into it. Cheers, -g On Fri, 3 Mar 2000 jamsden@us.ibm.com wrote: > Greg, > This is great. I didn't have an HTTP spec in front of me when I wrote the > note (need to get one by the bed I guess). We're probably running into the > MSFT problem. Maybe this doesn't happen on Windows2000 which seems to leave > you file names alone a little better. I'll investigate. Greg Stein wrote: > On Thu, 2 Mar 2000 jamsden@us.ibm.com wrote: > > > > HTTP URLs aren't case sensitive, > > RFC 2616, S3.2.3 states "When comparing two URIs to decide if they match > or not, a client SHOULD use a case-sensitive octet-by-octet comparison of > the entire URIs, with these exceptions: ..." > > In other words: they *are* case-sensitive. > > Apache certainly treats them that way. Try these two URLs: > >   http://www.webdav.org/other/proxy.html >  http://www.webdav.org/other/Proxy.html > > You'll find the latter fails. > > Note that HTTP servers running on an MSFT platform typically treat URLs in > a case-insensitive fashion (due to the filesystem being insensitive). > > > but some resources are. For example, Java > > source managed by a WebDAV server must retain the case in the package and > > class names or the code won't compile. mod_dav foldes all resource names > to > > lower case, so .java files on the server won't compile. > > WHAT?!!  mod_dav does NOT do any case-folding. Euh... what made you think > it does? > > > It seems that WebDAV could, like HTTP, be case insensitive while at the > > same time require that the server retain the case of resource URLs. That > > is, the URL segments in the bindings would retain the case in the target > > when it was entered, but access to those resources would be case > > insensitive. If this is not the case, WebDAV can't be used to store Java. > > That would be a real bummer! > > > > Would the proposal above be acceptable, and in the spirit of HTTP? > > No and no.  (IMO) > > I certainly do not want to take the performance hit to start doing > case-insensitive work in mod_dav and Apache. I am in great favor of > continuing to operate in a case-sensitive fashion, and I believe the > relevant RFCs encourage that, too. > > Cheers, > -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Mar 3 17:33:58 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11276 for ; Fri, 3 Mar 2000 17:33:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA27237; Fri, 3 Mar 2000 17:27:48 -0500 (EST) Resent-Date: Fri, 3 Mar 2000 17:27:48 -0500 (EST) Resent-Message-Id: <200003032227.RAA27237@www19.w3.org> Date: Fri, 3 Mar 2000 14:29:53 -0800 (PST) From: Greg Stein To: "Slein, Judith A" cc: "'Joe Orton'" , WebDAV WG In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DB0211F984@crte147.wc.eso.mc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4188 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 would it have to delete the properties? Overwrite is defined to "... overwrite the state of a non-null destination resource ...". It is specified in terms of a COPY/MOVE, and we can state that for a MKREF, it *only* overwrites the target. There is no other language that forces us to interpret Overwrite as "DELETE the resource first [implying the props are deleted]". I really like Joe's idea. Cheers, -g On Fri, 3 Mar 2000, Slein, Judith A wrote: > It's certainly a possibility. > > The only problem I can see with relying on MKREF is that it would not just > update the target, but would replace the resource with a new resource. > That's probably harmless if it's an HTTP resource with no properties, but if > it is a WebDAV resource it might have properties that you would like to > preserve while updating its target. > > --Judy > > -----Original Message----- > From: Joe Orton [mailto:joe@orton.demon.co.uk] > Sent: Wednesday, March 01, 2000 7:05 PM > To: WebDAV WG > Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > > Issue #6: Need to add rationale for why we use relative URLs. Server is > > required to store it as a relative URL. Server MUST NOT change the > relative > > URL during a MOVE. > > > > Raises the issue of needing separate methods for getting the value of a > > reference, and modifying the value of a reference. Tentatively agreed on > > REFGET, REFSET (but noone likes these too much). > > The original -00 spec allowed MKREF with Overwrite, could this be used > instead of REFSET? > > joe > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Mar 6 00:54:11 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17356 for ; Mon, 6 Mar 2000 00:54:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA09926; Mon, 6 Mar 2000 00:44:57 -0500 (EST) Resent-Date: Mon, 6 Mar 2000 00:44:57 -0500 (EST) Resent-Message-Id: <200003060544.AAA09926@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC02191F40@chef.lex.rational.com> From: "Clemm, Geoff" To: WebDAV WG Date: Mon, 6 Mar 2000 00:13:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4189 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list For both current uses of the Overwrite header (COPY and MOVE), the use of Overwrite means to first delete the resource (if any) that exists at that location. I.e.: 8.9.3 MOVE and the Overwrite Header If a resource exists at the destination and the Overwrite header is "T" then prior to performing the move the server MUST perform a DELETE with "Depth: infinity" on the destination resource. 8.8.4 COPY and the Overwrite Header If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource. To define its semantics for MKREF to differ in this regard seems likely to result in confusion and errors on the part of implementors. In the past, I've proposed that we extend the Overwrite header to allow a "Merge" value (i.e. Overwrite:Merge). If we did so, then the use of of "Overwrite:Merge" would allow us to consistently use MKREF and an Overwrite header to update the value of the redirect reference. Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Friday, March 03, 2000 5:30 PM To: Slein, Judith A Cc: 'Joe Orton'; WebDAV WG Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Why would it have to delete the properties? Overwrite is defined to "... overwrite the state of a non-null destination resource ...". It is specified in terms of a COPY/MOVE, and we can state that for a MKREF, it *only* overwrites the target. There is no other language that forces us to interpret Overwrite as "DELETE the resource first [implying the props are deleted]". I really like Joe's idea. Cheers, -g On Fri, 3 Mar 2000, Slein, Judith A wrote: > It's certainly a possibility. > > The only problem I can see with relying on MKREF is that it would not just > update the target, but would replace the resource with a new resource. > That's probably harmless if it's an HTTP resource with no properties, but if > it is a WebDAV resource it might have properties that you would like to > preserve while updating its target. > > --Judy > > -----Original Message----- > From: Joe Orton [mailto:joe@orton.demon.co.uk] > Sent: Wednesday, March 01, 2000 7:05 PM > To: WebDAV WG > Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > > Issue #6: Need to add rationale for why we use relative URLs. Server is > > required to store it as a relative URL. Server MUST NOT change the > relative > > URL during a MOVE. > > > > Raises the issue of needing separate methods for getting the value of a > > reference, and modifying the value of a reference. Tentatively agreed on > > REFGET, REFSET (but noone likes these too much). > > The original -00 spec allowed MKREF with Overwrite, could this be used > instead of REFSET? > > joe > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Mar 6 15:27:32 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25610 for ; Mon, 6 Mar 2000 15:27:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA09394; Mon, 6 Mar 2000 15:19:00 -0500 (EST) Resent-Date: Mon, 6 Mar 2000 15:19:00 -0500 (EST) Resent-Message-Id: <200003062019.PAA09394@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 6 Mar 2000 12:18:50 -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: <65B141FB11CCD211825700A0C9D609BC02191F40@chef.lex.rational.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4190 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 agree with Geoff -- the Overwrite header isn't ideal for this case, since it has "delete first" semantics, and is always associated with the Destination of a COPY/MOVE, not the Request-URI. - Jim > For both current uses of the Overwrite header (COPY and MOVE), the use > of Overwrite means to first delete the resource (if any) that exists at > that location. I.e.: > > 8.9.3 MOVE and the Overwrite Header > > If a resource exists at the destination and the Overwrite header is > "T" then prior to performing the move the server MUST perform a > DELETE with "Depth: infinity" on the destination resource. > > 8.8.4 COPY and the Overwrite Header > > If a resource exists at the destination and the Overwrite header is > "T" then prior to performing the copy the server MUST perform a > DELETE with "Depth: infinity" on the destination resource. > > To define its semantics for MKREF to differ in this regard > seems likely to result in confusion and errors on the part of > implementors. > > In the past, I've proposed that we extend the Overwrite header to allow > a "Merge" value (i.e. Overwrite:Merge). If we did so, then the use of > of "Overwrite:Merge" would allow us to consistently use MKREF and an > Overwrite header to update the value of the redirect reference. > > Cheers, > Geoff > > > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Friday, March 03, 2000 5:30 PM > To: Slein, Judith A > Cc: 'Joe Orton'; WebDAV WG > Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > Why would it have to delete the properties? > > Overwrite is defined to "... overwrite the state of a non-null destination > resource ...". It is specified in terms of a COPY/MOVE, and we can state > that for a MKREF, it *only* overwrites the target. > > There is no other language that forces us to interpret Overwrite as > "DELETE the resource first [implying the props are deleted]". > > I really like Joe's idea. > > Cheers, > -g > > On Fri, 3 Mar 2000, Slein, Judith A wrote: > > It's certainly a possibility. > > > > The only problem I can see with relying on MKREF is that it > would not just > > update the target, but would replace the resource with a new resource. > > That's probably harmless if it's an HTTP resource with no > properties, but > if > > it is a WebDAV resource it might have properties that you would like to > > preserve while updating its target. > > > > --Judy > > > > -----Original Message----- > > From: Joe Orton [mailto:joe@orton.demon.co.uk] > > Sent: Wednesday, March 01, 2000 7:05 PM > > To: WebDAV WG > > Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > > > > > Issue #6: Need to add rationale for why we use relative URLs. > Server is > > > required to store it as a relative URL. Server MUST NOT change the > > relative > > > URL during a MOVE. > > > > > > Raises the issue of needing separate methods for getting the > value of a > > > reference, and modifying the value of a reference. Tentatively agreed > on > > > REFGET, REFSET (but noone likes these too much). > > > > The original -00 spec allowed MKREF with Overwrite, could this be used > > instead of REFSET? > > > > joe > > > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Mon Mar 6 16:38:24 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05218 for ; Mon, 6 Mar 2000 16:38:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA12669; Mon, 6 Mar 2000 16:30:04 -0500 (EST) Resent-Date: Mon, 6 Mar 2000 16:30:04 -0500 (EST) Resent-Message-Id: <200003062130.QAA12669@www19.w3.org> Date: Mon, 6 Mar 2000 13:32:37 -0800 (PST) From: Greg Stein To: WebDAV WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4191 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 read the section 9.6 in the spec about the Overwrite header itself. It doesn't mention anything about DELETE. You guys are (IMO, incorrectly) associating Overwrite with MOVE/COPY. I feel that the right way to look at it is "what does MOVE/COPY do when Overwrite is present?" Another way to say it is that you're creating too strong of a binding between the semantics of the COPY/MOVE methods and the presence of that header. By your logic, every method should have its own set of associated headers. We should never share headers. We'll have Overwrite, MKREF-Overwrite, etc. I wouldn't be upset with a "merge" definition, but I did have to respond to the way you guys are approaching the problem :-) Cheers, -g On Mon, 6 Mar 2000, Jim Whitehead wrote: > I agree with Geoff -- the Overwrite header isn't ideal for this case, since > it has "delete first" semantics, and is always associated with the > Destination of a COPY/MOVE, not the Request-URI. > > - Jim > > > For both current uses of the Overwrite header (COPY and MOVE), the use > > of Overwrite means to first delete the resource (if any) that exists at > > that location. I.e.: > > > > 8.9.3 MOVE and the Overwrite Header > > > > If a resource exists at the destination and the Overwrite header is > > "T" then prior to performing the move the server MUST perform a > > DELETE with "Depth: infinity" on the destination resource. > > > > 8.8.4 COPY and the Overwrite Header > > > > If a resource exists at the destination and the Overwrite header is > > "T" then prior to performing the copy the server MUST perform a > > DELETE with "Depth: infinity" on the destination resource. > > > > To define its semantics for MKREF to differ in this regard > > seems likely to result in confusion and errors on the part of > > implementors. > > > > In the past, I've proposed that we extend the Overwrite header to allow > > a "Merge" value (i.e. Overwrite:Merge). If we did so, then the use of > > of "Overwrite:Merge" would allow us to consistently use MKREF and an > > Overwrite header to update the value of the redirect reference. > > > > Cheers, > > Geoff > > > > > > -----Original Message----- > > From: Greg Stein [mailto:gstein@lyra.org] > > Sent: Friday, March 03, 2000 5:30 PM > > To: Slein, Judith A > > Cc: 'Joe Orton'; WebDAV WG > > Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > > > > Why would it have to delete the properties? > > > > Overwrite is defined to "... overwrite the state of a non-null destination > > resource ...". It is specified in terms of a COPY/MOVE, and we can state > > that for a MKREF, it *only* overwrites the target. > > > > There is no other language that forces us to interpret Overwrite as > > "DELETE the resource first [implying the props are deleted]". > > > > I really like Joe's idea. > > > > Cheers, > > -g > > > > On Fri, 3 Mar 2000, Slein, Judith A wrote: > > > It's certainly a possibility. > > > > > > The only problem I can see with relying on MKREF is that it > > would not just > > > update the target, but would replace the resource with a new resource. > > > That's probably harmless if it's an HTTP resource with no > > properties, but > > if > > > it is a WebDAV resource it might have properties that you would like to > > > preserve while updating its target. > > > > > > --Judy > > > > > > -----Original Message----- > > > From: Joe Orton [mailto:joe@orton.demon.co.uk] > > > Sent: Wednesday, March 01, 2000 7:05 PM > > > To: WebDAV WG > > > Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > > > > > > > > Issue #6: Need to add rationale for why we use relative URLs. > > Server is > > > > required to store it as a relative URL. Server MUST NOT change the > > > relative > > > > URL during a MOVE. > > > > > > > > Raises the issue of needing separate methods for getting the > > value of a > > > > reference, and modifying the value of a reference. Tentatively agreed > > on > > > > REFGET, REFSET (but noone likes these too much). > > > > > > The original -00 spec allowed MKREF with Overwrite, could this be used > > > instead of REFSET? > > > > > > joe > > > > > > > -- > > Greg Stein, http://www.lyra.org/ > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Mar 6 23:56:12 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26183 for ; Mon, 6 Mar 2000 23:56:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA23168; Mon, 6 Mar 2000 23:46:32 -0500 (EST) Resent-Date: Mon, 6 Mar 2000 23:46:32 -0500 (EST) Resent-Message-Id: <200003070446.XAA23168@www19.w3.org> Date: Mon, 6 Mar 2000 23:45:57 -0500 (EST) Message-Id: <200003070445.XAA14613@tantalum.atria.com> X-Authentication-Warning: tantalum.atria.com: gclemm set sender to geoffrey.clemm@rational.com using -f From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-reply-to: (message from Greg Stein on Mon, 6 Mar 2000 13:32:37 -0800 (PST)) References: Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4192 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: Greg Stein I read the section 9.6 in the spec about the Overwrite header itself. It doesn't mention anything about DELETE. You guys are (IMO, incorrectly) associating Overwrite with MOVE/COPY. In understanding the meaning of a header, I believe it is valid to consider both what the definition of the header says, as well as what the header means when used with current methods. If all defined uses of the Overwrite:T header means to delete the current resource at the Destination location before performing the request, then I think one should be cautious about having it mean something else for a new method. Now if there is something about the current usage that doesn't apply to the new method, then I think it is reasonable to ignore that aspect of the current usage. For example, I wouldn't be that concerned about having Overwrite:T apply to the Request-URL for MKREF, since there is no Destination header. But I'd be concerned about the ignoring the "delete existing resource" usage. This is a very reasonable behavior for a MKREF request. In particular, what if a client *wanted* to say to "delete the current resource at this location and then create a redirect reference there". Having the Overwrite:T header mean this for some methods, and mean "update the existing resource" for other methods seems likely to cause errors and confusion. But I continue to be supportive of an Overwrite:Merge or Overwrite:Update form of the Overwrite header to handle this case. I believe it is appropriate for this to be an alternative Overwrite value rather than a new header, since this an alternative to Overwrite:T or Overwrite:F, not some orthogonal behavior. I feel that the right way to look at it is "what does MOVE/COPY do when Overwrite is present?" Another way to say it is that you're creating too strong of a binding between the semantics of the COPY/MOVE methods and the presence of that header. By your logic, every method should have its own set of associated headers. We should never share headers. We'll have Overwrite, MKREF-Overwrite, etc. I certainly think we should share headers, but that `MKREF Overwrite:F' should mean "fail the MKREF if there already is a resource at that location", and `MKREF Overwrite:T' should mean "delete the resource at that location, and then perform the MKREF" (since that's what they mean for COPY and MOVE). I wouldn't be upset with a "merge" definition, but I did have to respond to the way you guys are approaching the problem :-) Does the approach sound more reasonable with this additional explanation, or do you still object? (It sounds like at least 2 of us are OK with the "Merge" suggestion, but I think JimW doesn't like it ... although I'm not sure why not ... maybe it's time to put him on the spot :-). Cheers, Geoff On Mon, 6 Mar 2000, Jim Whitehead wrote: > I agree with Geoff -- the Overwrite header isn't ideal for this case, since > it has "delete first" semantics, and is always associated with the > Destination of a COPY/MOVE, not the Request-URI. > > - Jim > > > For both current uses of the Overwrite header (COPY and MOVE), the use > > of Overwrite means to first delete the resource (if any) that exists at > > that location. I.e.: > > > > 8.9.3 MOVE and the Overwrite Header > > > > If a resource exists at the destination and the Overwrite header is > > "T" then prior to performing the move the server MUST perform a > > DELETE with "Depth: infinity" on the destination resource. > > > > 8.8.4 COPY and the Overwrite Header > > > > If a resource exists at the destination and the Overwrite header is > > "T" then prior to performing the copy the server MUST perform a > > DELETE with "Depth: infinity" on the destination resource. > > > > To define its semantics for MKREF to differ in this regard > > seems likely to result in confusion and errors on the part of > > implementors. > > > > In the past, I've proposed that we extend the Overwrite header to allow > > a "Merge" value (i.e. Overwrite:Merge). If we did so, then the use of > > of "Overwrite:Merge" would allow us to consistently use MKREF and an > > Overwrite header to update the value of the redirect reference. > > > > Cheers, > > Geoff > > > > > > -----Original Message----- > > From: Greg Stein [mailto:gstein@lyra.org] > > Sent: Friday, March 03, 2000 5:30 PM > > To: Slein, Judith A > > Cc: 'Joe Orton'; WebDAV WG > > Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > > > > Why would it have to delete the properties? > > > > Overwrite is defined to "... overwrite the state of a non-null destination > > resource ...". It is specified in terms of a COPY/MOVE, and we can state > > that for a MKREF, it *only* overwrites the target. > > > > There is no other language that forces us to interpret Overwrite as > > "DELETE the resource first [implying the props are deleted]". > > > > I really like Joe's idea. > > > > Cheers, > > -g > > > > On Fri, 3 Mar 2000, Slein, Judith A wrote: > > > It's certainly a possibility. > > > > > > The only problem I can see with relying on MKREF is that it > > would not just > > > update the target, but would replace the resource with a new resource. > > > That's probably harmless if it's an HTTP resource with no > > properties, but > > if > > > it is a WebDAV resource it might have properties that you would like to > > > preserve while updating its target. > > > > > > --Judy > > > > > > -----Original Message----- > > > From: Joe Orton [mailto:joe@orton.demon.co.uk] > > > Sent: Wednesday, March 01, 2000 7:05 PM > > > To: WebDAV WG > > > Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000 > > > > > > > > > > Issue #6: Need to add rationale for why we use relative URLs. > > Server is > > > > required to store it as a relative URL. Server MUST NOT change the > > > relative > > > > URL during a MOVE. > > > > > > > > Raises the issue of needing separate methods for getting the > > value of a > > > > reference, and modifying the value of a reference. Tentatively agreed > > on > > > > REFGET, REFSET (but noone likes these too much). > > > > > > The original -00 spec allowed MKREF with Overwrite, could this be used > > > instead of REFSET? > > > > > > joe > > > > > > > -- > > Greg Stein, http://www.lyra.org/ > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Mar 7 14:01:12 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04871 for ; Tue, 7 Mar 2000 14:01:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA13209; Tue, 7 Mar 2000 13:55:28 -0500 (EST) Resent-Date: Tue, 7 Mar 2000 13:55:28 -0500 (EST) Resent-Message-Id: <200003071855.NAA13209@www19.w3.org> From: Jim Whitehead To: Patrick Collins , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Tue, 7 Mar 2000 10:55:19 -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: <38C24C2D.20B183F5@web.fairfax.com.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: DAV Perl Module - HTTP::Dav.pm Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4193 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 > My problem is this. Gisle's LibWWW modules only supports HTTP/1.0. But > so far I haven't noticed a problem communicating as an HTTP/1.0 WebDAV > client to an HTTP/1.1 WebDAV server (well mod_dav 0.9.14 actually). > > Can you please tell me, why was WebDAV built on top of HTTP/1.1 instead > of just HTTP/1.0. Or more specifically, are there specific features > available in HTTP/1.1 that will prevent my client from being a fully > Class1 and Class2 compliant WebDAV client? If so, I've got a lot more > work because I'll have to write an HTTP/1.1 version of Gisle's LibWWW. There were several reasons for using HTTP/1.1. 1) HTTP/1.0 is an Informational standard, and not a standards track document within the IETF. Since we wanted WebDAV to be a standards track protocol, we needed to build upon another standards track protocol. HTTP/1.1 is standards track. 2) HTTP/1.1 provides persistent connections, which provide significant performance improvements over HTTP/1.0, since a TCP connection does not need to be created for each method. Since WebDAV clients often send bursts of several methods, it is better for WebDAV clients to use HTTP/1.1 style persistent connections. 3) Digest authentication was defined to work with HTTP/1.1 (although I suspect it would also work with HTTP/1.0), and WebDAV needed to require a better authentication mechanism than HTTP Basic authentication. 4) HTTP/1.1 requires HTTP/1.1 compliant proxies to pass through unknown methods. HTTP/1.0 proxies have no such restriction. This allows new methods, such as those defined in WebDAV, to be passed through proxies. 5) The Host header, required for HTTP/1.1 clients, allows servers to manage multiple DNS hosts at the same time. Which of these features do you need to implement to be compliant? - you must ensure the Host header is sent with every method - you must implement Digest authentication - you must support persistent connections There may be other features too (these are just the most important ones that I can remember off the top of my head). - Jim From w3c-dist-auth-request@w3.org Wed Mar 8 19:31:52 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00682 for ; Wed, 8 Mar 2000 19:31:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA17232; Wed, 8 Mar 2000 19:26:49 -0500 (EST) Resent-Date: Wed, 8 Mar 2000 19:26:49 -0500 (EST) Resent-Message-Id: <200003090026.TAA17232@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 8 Mar 2000 16:26:28 -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: Redirect Ref. teleconference, Mar. 8, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4194 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 Redirect References Teleconference March 8, 2000 Present: Judy Slein, Chuck Fay, Jason Crawford, Jim Whitehead, Geoff Clemm Minutes recorded by Jim Whitehead *** Note that decisions made during the teleconference are always subject to review on the mailing list. The mailing list is the final arbiter of consensus on any issue. Note also, that the revised Redirect References protocol produced as a result of this conference call will also be subject to review by the mailing list. *** Issue #16: We accept the proposed language. There is no way we can guarantee that redirect references will be easy to implement for all implementations. Issue #17: There is a need for both the Location header, which alway returns an absolute URL, and some means of getting the actual value of the Redirect Target, which can be a relative URL. This is why just using the Location header to retrieve this value is insufficient, since it cannot return a relative URL. We will eed some mechanism (REFGET method?) for retrieving the relative URL value. Issue #18: Agreed that we should not create a registration procedure for resource types. New resource types are not created that often, and need to be defined by an RFC, and are not expected to be created by end-users. However, we agree that this should be listed in the IANA considerations section. Of course, in general, there is a need for registration proceedures for new HTTP methods, headers, as well as for DAV properties. Issue #19: Agree that the language needs to be changed, and we will revise it. Issue #20: Disagree. We are creating a document that will be used for many years, and 5-10 years from now, MKRESOURCE will not be a "new" method. But, we will add language stating that the method is defined normatively in this document. Issue #21: It is an oversight that these sentences are still present. They will be removed. Everything except for the first sentence of the paragraph can be deleted. Issue #23: There most frequently used HTTP clients do not display the response body on a redirect, and thus it doesn't seem to make much sense to provide remote authoring capability for this. However, it is a SHOULD level requirement in HTTP/1.1 that a 302 return a body that might be displayed. There are 4 cases here: GET, GET with Apply-to-RR, PUT, PUT with Apply-to-RR. GET needs to be able to return a body, due to HTTP/1.1 requirements. GET with Apply-to-RR we feel should fail (403 or 405). PUT should fail, as should PUT with Apply-to-RR. Issue #26: Will take this under advisement when we revise this section. Issue #27: Will evaluate this in its use cases to see if it clarifies the language. Issue #28: Agreed. Will change the language to reflect this. Issue #29: Agreed that it is obvious. Will remove it. Issue #30: Will keep up to "MUST be returned", then remove the rest of the sentence. Issue #31: Agreed that this section can be removed, it does list obvious consequences. Issue #32: Agreed that we will remove the mention of ORDERPATCH. Issue #33: Agreed, will replace "forward" with "redirect" throughout where it is appropriate. Issue #34: Agreed, we will remove all references to bindings from this specification. Issue #35: Agreed to remove these paragraphs (this is a consequence of resolution to Issue #34). Issue #36: We will re-write the specification to remove the use of the term "server" as much as possible. Issue #37: The key issue is that the target value is completely under the control of the client, the server must not modify the value of the redirect reference. We will rewrite the integrity statement to say this instead. Issue #38: We will rewrite this to retain the motivation of having something in a collection by-reference, but remove discussion of hierarchy. But, should motivate the HTTP/1.1 uses of redirect references first, then go on to WebDAV motivations later in the introduction. Issue #39: Already agreed to do this in issue #15 resolution. Issue #40: Will remove word server. We will look at uses of "forward" in this section to see if they should be "redirect". Will also remove discussion of direct reference resources in this section.Will mention the difference between the definition of "forward" and "redirect" in the spec (perhaps in this section). Issue #43: Went back on our discussion of last week, and agreed that we would like to have a DAV:Reftarget property available for WebDAV compliant servers. This would allow a client to quickly retrieve the Reftargets of all Redirect Reference resources in a particular collection. This property would, of course, not be available for HTTP/1.1 only servers. Issue #44: Did not find arguments against the current marshalling to be compelling, will keep this as-is. There do not appear, in general, to be compelling reasons to choose one marshalling over another. Issue #45: We found the note to be incorrect. A request on a redirect reference resource with the Apply-to-RR header must behave according to the specification, and hence by definition there is no case where you can receive a 302 back without following the behavior of the spec. So, we will not include the proposed note. Issue #46: We have agreed to remove all references to bindings from this specification. Issue #47: The comment about 207 no longer applies, since MKRESOURCE has been replaced with MKREF. Will add to the text of the 409 response to note that some of the conditions only apply to WebDAV collection cases. Issue #48: Agreed that most of the text in Section 6 can be removed. Will provisionally accept Yaron's text (excepting the word "blindly"). Will keep the requirements about the Redirect-Ref and Location header being (relative|absolute) and absolute URLs respectively. *** End of teleconference *** From w3c-dist-auth-request@w3.org Fri Mar 10 11:31:50 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10545 for ; Fri, 10 Mar 2000 11:31:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA15905; Fri, 10 Mar 2000 11:26:35 -0500 (EST) Resent-Date: Fri, 10 Mar 2000 11:26:35 -0500 (EST) Resent-Message-Id: <200003101626.LAA15905@www19.w3.org> Message-ID: From: Fisher Mark To: "'Greg Stein'" , jamsden@us.ibm.com Cc: w3c-dist-auth@w3.org Date: Fri, 10 Mar 2000 11:26:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Case sensitive names and authoring Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4195 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Note that HTTP servers running on an MSFT platform typically treat URLs in >a case-insensitive fashion (due to the filesystem being insensitive). Just a refresher, here, folks. The actual NTFS filesystem code on WinNT is case-sensitive, but the Win32 subsystem that is normally used to access it is case-preserving but case-insensitive. That is, if you have a file named "Makefile", you can use any of "makefile", "Makefile", "makeFile", "MakeFile", etc. to access that file with the Win32 subsystem. I think that the NT POSIX subsystem is case-sensitive, but I don't know of any webservers that run under the NT POSIX subsystem. As far as I know, Windows2000 preserves these semantics. The upshot being that Apache on NT, as it runs under the Win32 subsystem, will case-fold on a PUT -- it can't help itself. ========================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@tce.com Indianapolis, IN "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_ From w3c-dist-auth-request@w3.org Fri Mar 10 16:09:30 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18281 for ; Fri, 10 Mar 2000 16:09:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA23829; Fri, 10 Mar 2000 16:03:37 -0500 (EST) Resent-Date: Fri, 10 Mar 2000 16:03:37 -0500 (EST) Resent-Message-Id: <200003102103.QAA23829@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F99B@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'w3c-dist-auth@w3.org'" Cc: "Hall, Shaun" Date: Fri, 10 Mar 2000 16:03:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: UNLOCK from the middle of a locked tree Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4196 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 this question from a product team in my company. Any opinions? I would say that (b) is not an option, but failing the unlock request might be. --Judy Section 8.11 UNLOCK Method. The first sentence states "...and all other resources included in the lock". Does this mean that a client should only Unlock from the point where the lock starts? For example, in a hierarchy: Collection 1 | | Collection 2 Collection 3 | | Resource 4 Resource 5 If the lock was created with a Depth of infinity on "Collection 1", should the user only perform the UNLOCK on "Collection 1"? We're concerned that a client may try and unlock from a sub-point within the hierarchy eg UNLOCK "Collection 2", which means to meet the first sentence in the RFC, we either: a) Have to traverse the entire hierarchy (parents and all) removing the lock from all resources (in the above example, "Collection 1", "Collection 3" and "File 5"). b) Only remove the lock from "Collection 2" and "File 4". From w3c-dist-auth-request@w3.org Fri Mar 10 16:37:02 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28291 for ; Fri, 10 Mar 2000 16:37:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA24388; Fri, 10 Mar 2000 16:32:58 -0500 (EST) Resent-Date: Fri, 10 Mar 2000 16:32:58 -0500 (EST) Resent-Message-Id: <200003102132.QAA24388@www19.w3.org> Date: Fri, 10 Mar 2000 13:17:29 -0800 From: Kevin Wiggen In-reply-to: <8E3CFBC709A8D21191A400805F15E0DB0211F99B@crte147.wc.eso.mc.xerox.com> To: "Slein, Judith A" , w3c-dist-auth@w3.org Cc: "Hall, Shaun" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Priority: 3 (Normal) Subject: RE: UNLOCK from the middle of a locked tree Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4197 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 think the spec is trying to state A. In fact that is what Xythos does (well we don't need to traverse hierarchies, but that's an implementation point). From anywhere in a depth lock, if you send a correct lock token with a unlock request, the lock is removed, thus unlocking the entire tree. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Slein, Judith A Sent: Friday, March 10, 2000 1:03 PM To: 'w3c-dist-auth@w3.org' Cc: Hall, Shaun Subject: UNLOCK from the middle of a locked tree I have this question from a product team in my company. Any opinions? I would say that (b) is not an option, but failing the unlock request might be. --Judy Section 8.11 UNLOCK Method. The first sentence states "...and all other resources included in the lock". Does this mean that a client should only Unlock from the point where the lock starts? For example, in a hierarchy: Collection 1 | | Collection 2 Collection 3 | | Resource 4 Resource 5 If the lock was created with a Depth of infinity on "Collection 1", should the user only perform the UNLOCK on "Collection 1"? We're concerned that a client may try and unlock from a sub-point within the hierarchy eg UNLOCK "Collection 2", which means to meet the first sentence in the RFC, we either: a) Have to traverse the entire hierarchy (parents and all) removing the lock from all resources (in the above example, "Collection 1", "Collection 3" and "File 5"). b) Only remove the lock from "Collection 2" and "File 4". From w3c-dist-auth-request@w3.org Fri Mar 10 17:11:30 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10729 for ; Fri, 10 Mar 2000 17:11:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA25008; Fri, 10 Mar 2000 17:06:34 -0500 (EST) Resent-Date: Fri, 10 Mar 2000 17:06:34 -0500 (EST) Resent-Message-Id: <200003102206.RAA25008@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D760@chef.lex.rational.com> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 10 Mar 2000 17:05:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: UNLOCK from the middle of a locked tree Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4198 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 Kevin. Cheers, Geoff -----Original Message----- From: Kevin Wiggen [mailto:wiggs@wiggenout.com] Sent: Friday, March 10, 2000 4:17 PM To: Slein, Judith A; w3c-dist-auth@w3.org Cc: Hall, Shaun Subject: RE: UNLOCK from the middle of a locked tree I think the spec is trying to state A. In fact that is what Xythos does (well we don't need to traverse hierarchies, but that's an implementation point). From anywhere in a depth lock, if you send a correct lock token with a unlock request, the lock is removed, thus unlocking the entire tree. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Slein, Judith A Sent: Friday, March 10, 2000 1:03 PM To: 'w3c-dist-auth@w3.org' Cc: Hall, Shaun Subject: UNLOCK from the middle of a locked tree I have this question from a product team in my company. Any opinions? I would say that (b) is not an option, but failing the unlock request might be. --Judy Section 8.11 UNLOCK Method. The first sentence states "...and all other resources included in the lock". Does this mean that a client should only Unlock from the point where the lock starts? For example, in a hierarchy: Collection 1 | | Collection 2 Collection 3 | | Resource 4 Resource 5 If the lock was created with a Depth of infinity on "Collection 1", should the user only perform the UNLOCK on "Collection 1"? We're concerned that a client may try and unlock from a sub-point within the hierarchy eg UNLOCK "Collection 2", which means to meet the first sentence in the RFC, we either: a) Have to traverse the entire hierarchy (parents and all) removing the lock from all resources (in the above example, "Collection 1", "Collection 3" and "File 5"). b) Only remove the lock from "Collection 2" and "File 4". From w3c-dist-auth-request@w3.org Fri Mar 10 19:34:00 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28809 for ; Fri, 10 Mar 2000 19:33:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA27466; Fri, 10 Mar 2000 19:29:41 -0500 (EST) Resent-Date: Fri, 10 Mar 2000 19:29:41 -0500 (EST) Resent-Message-Id: <200003110029.TAA27466@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Kevin Wiggen cc: "Slein, Judith A" , w3c-dist-auth@w3.org, "Hall, Shaun" Message-ID: <8525689F.000299CD.00@D51MTA03.pok.ibm.com> Date: Fri, 10 Mar 2000 19:27:10 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: UNLOCK from the middle of a locked tree Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4199 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. (b) is not an option. UNLOCK is all or nothing. Whether the unlock is/shouldbe sensitive to the request URI is not clear to me. I'll agree with whatever the majority prefers. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat Mar 11 12:17:19 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18452 for ; Sat, 11 Mar 2000 12:17:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA10542; Sat, 11 Mar 2000 12:11:50 -0500 (EST) Resent-Date: Sat, 11 Mar 2000 12:11:50 -0500 (EST) Resent-Message-Id: <200003111711.MAA10542@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525689F.005E6C21.00@d54mta03.raleigh.ibm.com> Date: Sat, 11 Mar 2000 12:11:14 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id MAA10522 Subject: RE: UNLOCK from the middle of a locked tree Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4201 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: 8bit I didn't read the spec exactly this way. I considered depth locks a convenience for setting many locks on the same resource using the same lock token in a single request. Depth in all other methods applies to the target resource and recursively all its children. It never applies to a parent of the target. DAV4J gives an error if you attempt to unlock a depth locked resource from any resource but the one that was originally locked. It does this by checking to see if the immediate parent of the target resource is locked with the same lock token. |------------------------+------------------------> | | Kevin Wiggen | | | | | | Sent by: | | | w3c-dist-auth-request| | | @w3.org | | | | | | 03/10/2000 04:17 PM | | | | |------------------------+------------------------> >------------------------| | | |         To: | | "Slein, Judith A" | | , | | w3c-dist-auth@w3.org | |         cc: | | "Hall, Shaun" | | | |         Subject: | | RE: UNLOCK from the | | middle of a locked | | tree | >------------------------| I think the spec is trying to state A.  In fact that is what Xythos does (well we don't need to traverse hierarchies, but that's an implementation point). From anywhere in a depth lock, if you send a correct lock token with a unlock request, the lock is removed, thus unlocking the entire tree. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Slein, Judith A Sent: Friday, March 10, 2000 1:03 PM To: 'w3c-dist-auth@w3.org' Cc: Hall, Shaun Subject: UNLOCK from the middle of a locked tree I have this question from a product team in my company.  Any opinions?  I would say that (b) is not an option, but failing the unlock request might be. --Judy Section 8.11 UNLOCK Method. The first sentence states "...and all other resources included in the lock". Does this mean that a client should only Unlock from the point where the lock starts? For example, in a hierarchy:                 Collection 1                |          |            Collection 2        Collection 3                |          |            Resource 4        Resource 5 If the lock was created with a Depth of infinity on "Collection 1", should the user only perform the UNLOCK on "Collection 1"? We're concerned that a client may try and unlock from a sub-point within the hierarchy eg UNLOCK "Collection 2", which means to meet the first sentence in the RFC, we either: a) Have to traverse the entire hierarchy (parents and all) removing the lock from all resources (in the above example, "Collection 1", "Collection 3" and "File 5"). b) Only remove the lock from "Collection 2" and "File 4". From w3c-dist-auth-request@w3.org Mon Mar 13 06:15:49 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13730 for ; Mon, 13 Mar 2000 06:15:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA12869; Mon, 13 Mar 2000 06:04:56 -0500 (EST) Resent-Date: Mon, 13 Mar 2000 06:04:56 -0500 (EST) Resent-Message-Id: <200003131104.GAA12869@www19.w3.org> From: "Mike Evans" To: Date: Mon, 13 Mar 2000 11:14:17 -0000 Message-ID: <000401bf8cdd$45d7e0e0$6b31a38d@see.plym.ac.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BF8CDD.45D96780" 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 V5.00.2314.1300 Subject: WebDAV and disconnected/asynchronous operation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4202 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 is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF8CDD.45D96780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello all, I am a Ph.D student at the University of Plymouth, UK, and I was wondering if anybody could help me with some questions I have regarding WebDAV. I need to know if any work is currently being conducted into using WebDAV over slow/intermittent connections? From what I have read from the archives, the discussion on this topic seemed to end in 1997, with a small discussion on 'email access to DAV functionality' and 'disconnected operation', but I can't find any outcome to these discussions. Was any decision reached to include/preclude such operation in the spec, or was it decided to leave it to specific impementations to handle in their own way? To give you some context, my Ph.D work is centred around managing information on the web. Hardly new, I know, but part of the work is based on developing a resource migration mechanism for the web. Before you all switch off, I am currently designing a resource migration protocol that manages the migration process, with WebDAV being used to handle the physical movement of the resource across servers during a migration. The idea is that an agent manages the process on behalf of a client. The client could be a user, or a programmatic client (such as a distributed object). If it's the latter, it will need to send a 'Migrate' message to the agent (which could be on a different host to the client), and wait for the response. What concerns me is the potential delay in receiving this response. The migration process comprises several DAV commands, some authorisation along the way, and the updating of a suitable name service, which could potentially take some time. Waiting for the response may not be a good idea, but I'd hate to go ahead and implement my own asyncronous operation if it conflicts with what has already been developed (and why reinvent the wheel anyway?!) Could anybody inform me, therefore, if any work has been carried out into disconnected operation, as I will gratefully use it. If not, I'll have to come up with my own solution. Clearly, as I'm working on automatic operation of the migration process, I can't use e-mail notification. BTW, I was wondering what (if anything) I should do with the migration protocol once it's complete? The protocol _uses_ WebDAV, it doesn't _extend_ it, but it does extend HTTP (minimally), and it does define cross-server operations, so it may be useful to others. Should I write an Internet draft? Would it be useful to this group? If not, who would it be useful for? (the IETF and W3C seem a bit quiet on the resource migration front, and the URN group seems a bit contentious! Would they welcome such a draft?). Many thanks in advance for any help you can offer. Regards, Mike Evans Network Research Group University of Plymouth Room 505, The Moneycentre Building Drake Circus Plymouth Devon Mike.Evans@jack.see.plym.ac.uk ------=_NextPart_000_0005_01BF8CDD.45D96780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=20 all,
 
I am a = Ph.D student=20 at the University of Plymouth, UK, and I was wondering if anybody could = help me=20 with some questions I have regarding WebDAV.
 
I need = to=20 know if any work is currently being conducted into = using WebDAV=20 over slow/intermittent connections?  From what I have read from the = archives, the discussion on this topic seemed to end in 1997, with a = small=20 discussion on 'email access to DAV functionality' and 'disconnected=20 operation', but I can't find any = outcome=20 to these discussions.  Was any decision reached to = include/preclude=20 such operation in the spec, or was it decided to leave it to specific=20 impementations to handle in their own way?
 
To = give you some=20 context, my Ph.D work is centred around managing information on the web. = Hardly=20 new, I know, but part of the work is based on developing a resource = migration=20 mechanism for the web.  Before you all switch off, I am currently = designing=20 a resource migration protocol that manages the migration = process, with WebDAV being used to handle the physical movement of the = resource=20 across servers during a migration.  The idea is that an agent = manages the=20 process on behalf of a client.  The client could be a user, or a=20 programmatic client (such as a distributed object).  If it's the = latter, it=20 will need to send a 'Migrate' message to the agent (which could be on a=20 different host to the client), and wait for the response.  What = concerns me=20 is the potential delay in receiving this response.  The migration = process=20 comprises several DAV commands, some authorisation along the way, and = the=20 updating of a suitable name service, which could potentially take some=20 time.  Waiting for the response may not be a good idea, but I'd = hate to go=20 ahead and implement my own asyncronous operation if it conflicts with = what has=20 already been developed (and why reinvent the wheel = anyway?!)
 
Could = anybody inform=20 me, therefore, if any work has been carried out into disconnected = operation, as=20 I will gratefully use it.  If not, I'll have to come up with my own = solution. Clearly, as I'm = working on=20 automatic operation of the migration process, I can't use e-mail=20 notification.
 
BTW, I = was wondering=20 what (if anything) I should do with the migration protocol once it's = complete?=20 The protocol _uses_ WebDAV, it doesn't _extend_ it, but it does extend = HTTP=20 (minimally), and it does define cross-server operations, so it may be = useful to=20 others.  Should I write an Internet draft? Would it be useful to = this=20 group? If not, who would it be useful for? (the IETF and W3C seem a bit = quiet on=20 the resource migration front, and the URN group seems a bit contentious! = Would=20 they welcome such a draft?).
 
Many = thanks in=20 advance for any help you can offer.
 
Regards,
 
Mike=20 Evans
 
Network Research=20 Group
University of=20 Plymouth
Room = 505, The=20 Moneycentre Building
Drake=20 Circus
Plymouth
Devon
 
Mike.Evans@jack.see.plym.a= c.uk
 
 
 
------=_NextPart_000_0005_01BF8CDD.45D96780-- From w3c-dist-auth-request@w3.org Mon Mar 13 13:12:15 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23400 for ; Mon, 13 Mar 2000 13:12:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA24064; Mon, 13 Mar 2000 13:07:24 -0500 (EST) Resent-Date: Mon, 13 Mar 2000 13:07:24 -0500 (EST) Resent-Message-Id: <200003131807.NAA24064@www19.w3.org> From: Jim Whitehead To: Mike Evans , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Mon, 13 Mar 2000 10:06:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01BF8CD3.DA6E19E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <000401bf8cdd$45d7e0e0$6b31a38d@see.plym.ac.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: WebDAV and disconnected/asynchronous operation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4203 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 is a multi-part message in MIME format. ------=_NextPart_000_008D_01BF8CD3.DA6E19E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mike Evans writes: I need to know if any work is currently being conducted into using WebDAV over slow/intermittent connections? From what I have read from the archives, the discussion on this topic seemed to end in 1997, with a small discussion on 'email access to DAV functionality' and 'disconnected operation', but I can't find any outcome to these discussions. Was any decision reached to include/preclude such operation in the spec, or was it decided to leave it to specific impementations to handle in their own way? The final decision was to design the specification in such a way that someone could come back later and add email access if they desired (to date no one has done this). The concern at the time was that some large fraction of the Internet only had intermittent access, and would not be able to access WebDAV functionality if it were limited to HTTP. The designers of WebDAV didn't agree with this assessment, since while the protocol was being developed there was an increasing trend towards higher modem speeds, and high speed access. However, it still seems quite possible to add in email transport for WebDAV operations. One approach is to package up WebDAV requests and responses as message/http MIME messages (defined in the HTTP specification), and email them from client to server. Note that email access and disconnected access aren't the same thing. WebDAV has the potential for being used in a disconnected manner using HTTP. One scenario is for a client to connect to the server, perform a LOCK/PROPFIND/GET sequence, then completely disconnect. The lock stays active during this time, since locks are not associated with network connections. Then, when the client is ready to finish, it reconnects, and does a PUT/PROPPATCH/UNLOCK sequence. I'm not sure what affect an intermittent connection would have. WebDAV, like HTTP, assumes it is running over TCP/IP, which is a reliable transport. An intermittent connection suggests that the connection isn't reliable. I suspect the best place to solve this is below the application layer. To give you some context, my Ph.D work is centred around managing information on the web. Hardly new, I know, but part of the work is based on developing a resource migration mechanism for the web. Before you all switch off, I am currently designing a resource migration protocol that manages the migration process, with WebDAV being used to handle the physical movement of the resource across servers during a migration. The idea is that an agent manages the process on behalf of a client. The client could be a user, or a programmatic client (such as a distributed object). If it's the latter, it will need to send a 'Migrate' message to the agent (which could be on a different host to the client), and wait for the response. What concerns me is the potential delay in receiving this response. The migration process comprises several DAV commands, some authorisation along the way, and the updating of a suitable name service, which could potentially take some time. Waiting for the response may not be a good idea, but I'd hate to go ahead and implement my own asyncronous operation if it conflicts with what has already been developed (and why reinvent the wheel anyway?!) I suspect there is some overlap between Web site migration, and cache replication (in both you are trying to duplicate a Web site) -- there is some discussion of cache replication protocols in this Internet Protocol Journal article: "Web Caching" Geoff Huston http://www.cisco.com/warp/public/759/ipj_2-3/ipj_2-3_webcaching.html Due to the time involved to perform the 'migrate' operation, I think you're right, typical remote procedure call semantics aren't ideal, since there is too large a time between request and response. What you'd like to do is send off the request, and receive an asynchronous event notification once it's completed. Unfortunately, there is currently no generic event notification protocol standard, although plenty of work has been done on this topic (see http://www.cs.caltech.edu/~adam/isen/event-systems.html for a survey of 144 of them). Could anybody inform me, therefore, if any work has been carried out into disconnected operation, as I will gratefully use it. If not, I'll have to come up with my own solution. Clearly, as I'm working on automatic operation of the migration process, I can't use e-mail notification. Well, email doesn't necessarily preclude automatic handling. You could have an email sent to a particular address, and have email to that address handled by a program, not some email user interface. BTW, I was wondering what (if anything) I should do with the migration protocol once it's complete? The protocol _uses_ WebDAV, it doesn't _extend_ it, but it does extend HTTP (minimally), and it does define cross-server operations, so it may be useful to others. Should I write an Internet draft? Would it be useful to this group? If not, who would it be useful for? (the IETF and W3C seem a bit quiet on the resource migration front, and the URN group seems a bit contentious! Would they welcome such a draft?). A detailed description of using WebDAV to perform Web site migration would be a useful document for others to read. Since it doesn't sound like you're adding much protocol mechanism, this would likely end up as an Informational (not standards track) RFC. But, once you've written it up, it would be much easier to see what trajectory it should take. - Jim ------=_NextPart_000_008D_01BF8CD3.DA6E19E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Mike=20 Evans writes:
I need to=20 know if any = work is currently being conducted into = using WebDAV=20 over slow/intermittent connections?  From what I have read from = the=20 archives, the discussion on this topic seemed to end in 1997, with a = small=20 discussion on 'email access to DAV functionality' and 'disconnected operation', but I can't find any outcome to = these=20 discussions.  Was any decision reached to include/preclude = such=20 operation in the spec, or was it decided to leave it to specific=20 impementations to handle in their own way? 
 
The final decision was = to design=20 the specification in such a way that someone could come back later and = add email=20 access if they desired (to date no one has done this).  The = concern at=20 the time was that some large fraction of the Internet only had = intermittent=20 access, and would not be able to access WebDAV functionality if it = were=20 limited to HTTP. The designers of WebDAV didn't agree with this = assessment,=20 since while the protocol was being developed there was an increasing = trend=20 towards higher modem speeds, and high speed=20 access.
 
However, it still seems = quite=20 possible to add in email transport for WebDAV operations. One approach = is to=20 package up WebDAV requests and responses as message/http MIME messages = (defined=20 in the HTTP specification), and email them from client to server.=20
 
Note=20 that email access and disconnected access aren't the same thing. = WebDAV has=20 the potential for being used in a disconnected manner using HTTP.  = One=20 scenario is for a client to connect to the server, perform a = LOCK/PROPFIND/GET=20 sequence, then completely disconnect.  The lock stays active during = this=20 time, since locks are not associated with network connections.  = Then, when=20 the client is ready to finish, it reconnects, and does a = PUT/PROPPATCH/UNLOCK=20 sequence.
 
I'm=20 not sure what affect an intermittent connection would have. WebDAV, = like=20 HTTP, assumes it is running over TCP/IP, which is a reliable = transport. An=20 intermittent connection suggests that the connection isn't = reliable.  I=20 suspect the best place to solve this is below the application=20 layer.
 
To give you=20 some context, my Ph.D work is centred around managing information on = the web.=20 Hardly new, I know, but part of the work is based on developing a = resource=20 migration mechanism for the web.  Before you all switch off, I am = currently designing a resource migration protocol that manages the = migration=20 process, with = WebDAV being used to handle the physical movement of the = resource=20 across servers during a migration.  The idea is that an agent = manages the=20 process on behalf of a client.  The client could be a user, or a=20 programmatic client (such as a distributed object).  If it's the = latter,=20 it will need to send a 'Migrate' message to the agent (which could be = on a=20 different host to the client), and wait for the response.  What = concerns=20 me is the potential delay in receiving this response.  The = migration=20 process comprises several DAV commands, some authorisation along the = way, and=20 the updating of a suitable name service, which could potentially take = some=20 time.  Waiting for the response may not be a good idea, but I'd = hate to=20 go ahead and implement my own asyncronous operation if it conflicts = with what=20 has already been developed (and why reinvent the wheel anyway?!) 
 
I suspect there = is some=20 overlap between Web site migration, and cache replication (in both = you are=20 trying to duplicate a Web site) -- there is some discussion of cache = replication=20 protocols in this Internet Protocol Journal=20 article:
"Web Caching"  = Geoff=20 Huston
http://www.cisco.com/warp/public/759/ipj_2-3/ipj_2-3_webcaching.html=
 
Due to=20 the time involved to perform the 'migrate' operation, I think you're=20 right, typical remote procedure call semantics aren't ideal, since = there is=20 too large a time between request and response.  What you'd like to = do is=20 send off the request, and receive an asynchronous event notification = once it's=20 completed.  Unfortunately, there is currently no generic event = notification=20 protocol standard, although plenty of work has been done on this topic = (see http://w= ww.cs.caltech.edu/~adam/isen/event-systems.html for=20 a survey of 144 of them). 
 
Could=20 anybody inform me, therefore, if any work has been carried out into=20 disconnected operation, as I will gratefully use it.  If not, = I'll have=20 to come up with my own solution.=20 Clearly, as I'm working on automatic operation of the migration = process, I can't use e-mail notification. 
 
Well, email = doesn't=20 necessarily preclude automatic handling.  You could have an email = sent to a=20 particular address, and have email to that address handled by a = program,=20 not some email user interface.
 
BTW, I was=20 wondering what (if anything) I should do with the migration protocol = once it's=20 complete? The protocol _uses_ WebDAV, it doesn't _extend_ it, but it = does=20 extend HTTP (minimally), and it does define cross-server operations, = so it may=20 be useful to others.  Should I write an Internet draft? Would it = be=20 useful to this group? If not, who would it be useful for? (the IETF = and W3C=20 seem a bit quiet on the resource migration front, and the URN group = seems a=20 bit contentious! Would they welcome such a draft?). 
A detailed = description of=20 using WebDAV to perform Web site migration would be a useful document = for others=20 to read.  Since it doesn't sound like you're adding much protocol=20 mechanism, this would likely end up as an Informational (not standards = track)=20 RFC.  But, once you've written it up, it would be much easier to = see what=20 trajectory it should take.
 
-=20 Jim
  ------=_NextPart_000_008D_01BF8CD3.DA6E19E0-- From w3c-dist-auth-request@w3.org Tue Mar 14 07:46:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23077 for ; Tue, 14 Mar 2000 07:46:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA19524; Tue, 14 Mar 2000 07:41:11 -0500 (EST) Resent-Date: Tue, 14 Mar 2000 07:41:11 -0500 (EST) Resent-Message-Id: <200003141241.HAA19524@www19.w3.org> Message-ID: <38CE32E4.9FDB8D16@adobe.com> Date: Tue, 14 Mar 2000 13:39:00 +0100 From: Hartmut Warncke Reply-To: hwarncke@Adobe.COM Organization: Adobe Systems X-Mailer: Mozilla 4.7 [en]C-CCK-MCD SGI (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: PROPPATCH problems with the IIS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4204 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 all, I have the following problem with Microsoft-IIS/5.0: If I send the following PROPPATCH command: content the server response contains a "200 OK" although the next PROPFIND (allprop) request on this resource results in the following server response: ... ... HTTP/1.1 200 OK 2333 ... So suddenly the "testa" property is empty. Does the IIS has any known problems with properties which are not flat? Hartmut From w3c-dist-auth-request@w3.org Tue Mar 14 13:56:19 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20087 for ; Tue, 14 Mar 2000 13:56:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05582; Tue, 14 Mar 2000 13:51:06 -0500 (EST) Resent-Date: Tue, 14 Mar 2000 13:51:06 -0500 (EST) Resent-Message-Id: <200003141851.NAA05582@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 14 Mar 2000 10:50:38 -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: Access control: moving forward again Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4205 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 Pretty much from the beginning, people have recognized that WebDAV needs access control capability. If you're going to remotely author resources, then you need the ability to add and remove collaborators. Previous efforts have resulted in a goals document and a preliminary protocol document: WebDAV Access Control Goals, Lisa Lippert http://www.ics.uci.edu/pub/ietf/webdav/acl/draft-ietf-webdav-acl-reqts-00.tx t WebDAV ACL Protocol, Paul Leach, Yaron Goland http://www.ics.uci.edu/pub/ietf/webdav/acl/draft-ietf-webdav-acl-00.txt Recently a number of people have asked me about access control, and so I believe that now there is a critical mass of people who want to see access control finished quickly, and who are willing to work towards this goal. To get things moving again, an access control teleconference will be held Friday, March 24, 2000, at 11AM-12noon Pacific. Agenda/access number/etc. will be forthcoming. Many thanks to Eric Sedlar for hosting the teleconference. Greg Stein has agreed to set up a separate mailing list for access control discussions, and will be emailing details on this to the mailing list. If you're interested in working on an access control protocol for WebDAV, I encourage you to attend the teleconference, and to join the mailing list. They are both open to all. - Jim From w3c-dist-auth-request@w3.org Tue Mar 14 15:12:07 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20250 for ; Tue, 14 Mar 2000 15:11:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA08663; Tue, 14 Mar 2000 15:07:27 -0500 (EST) Resent-Date: Tue, 14 Mar 2000 15:07:27 -0500 (EST) Resent-Message-Id: <200003142007.PAA08663@www19.w3.org> Message-ID: <00c501bf8df1$362f0870$ab171990@us.oracle.com> From: "Eric Sedlar" To: References: Date: Tue, 14 Mar 2000 12:09:32 -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: Access Control teleconf. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4206 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 Here is the conference call information for WebDAV ACLs: Phone number: 888-700-6725 Meeting ID: 932328225 Password: 2518 There are 8 voice ports allocated. Let me know if we will have more callers, and I can increase this number. --Eric ----- Original Message ----- From: Jim Whitehead To: Eric Sedlar ; Geoff Clemm ; Anne Hopkins ; Chris Kaler ; Greg Stein Sent: Tuesday, March 14, 2000 10:34 AM Subject: Access Control teleconf. > Super -- sounds like holding an access control teleconf. on Friday, March > 24th, from 11AM-12noon Pacific works well for everyone (Joe Orton declined > to participate). > > Greg: please do set up a mailing list and archive on webdav.org, that'd be a > big help > > Eric: thanks for hosting the teleconferences -- please send a message out to > the WebDAV list once you know the phone # and password #. > > I'll send an email out to the WebDAV list letting people know that we'll be > holding a teleconference. > > It feels good to be getting things rolling on access control again! > > - Jim > > From w3c-dist-auth-request@w3.org Tue Mar 14 19:21:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21794 for ; Tue, 14 Mar 2000 19:21:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA21933; Tue, 14 Mar 2000 19:17:09 -0500 (EST) Resent-Date: Tue, 14 Mar 2000 19:17:09 -0500 (EST) Resent-Message-Id: <200003150017.TAA21933@www19.w3.org> Date: Tue, 14 Mar 2000 16:20:43 -0800 (PST) From: Greg Stein To: WebDAV WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Access control: moving forward again Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4207 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, 14 Mar 2000, Jim Whitehead wrote: >... > Greg Stein has agreed to set up a separate mailing list for access control > discussions, and will be emailing details on this to the mailing list. > > If you're interested in working on an access control protocol for WebDAV, I > encourage you to attend the teleconference, and to join the mailing list. > They are both open to all. The mailing list has been created. Information on subscribing and the archives are at: http://mailman.webdav.org/mailman/listinfo/acl You can send a message to the list via mailto:acl@webdav.org Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Mar 14 21:10:37 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01119 for ; Tue, 14 Mar 2000 21:10:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA24591; Tue, 14 Mar 2000 21:06:31 -0500 (EST) Resent-Date: Tue, 14 Mar 2000 21:06:31 -0500 (EST) Resent-Message-Id: <200003150206.VAA24591@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 14 Mar 2000 18:05:56 -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 In-Reply-To: Subject: RE: Access control: moving forward again Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4208 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 Thanks Greg! Again, if you're interested in working on access control for WebDAV, I encourage you to join this discussion list! - Jim > The mailing list has been created. Information on subscribing and the > archives are at: > > http://mailman.webdav.org/mailman/listinfo/acl > > You can send a message to the list via mailto:acl@webdav.org > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Wed Mar 15 15:40:01 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18159 for ; Wed, 15 Mar 2000 15:40:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA19559; Wed, 15 Mar 2000 15:35:00 -0500 (EST) Resent-Date: Wed, 15 Mar 2000 15:35:00 -0500 (EST) Resent-Message-Id: <200003152035.PAA19559@www19.w3.org> To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: "Tim Ellison/OTT/OTI" Date: Wed, 15 Mar 2000 15:33:39 -0500 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at 03/15/2000 03:33:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Loops II Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4210 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list An observation: Although infinite loops are broken using Loop Detected rules, since all (non-circular) paths are returned by deep operations it is trivial to construct an n**m walks graph by having n levels with m bindings between each. This would be a prime candidate for denial of service type attacks against a server. Tim From w3c-dist-auth-request@w3.org Wed Mar 15 15:40:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18388 for ; Wed, 15 Mar 2000 15:40:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA19452; Wed, 15 Mar 2000 15:30:59 -0500 (EST) Resent-Date: Wed, 15 Mar 2000 15:30:59 -0500 (EST) Resent-Message-Id: <200003152030.PAA19452@www19.w3.org> To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: "Tim Ellison/OTT/OTI" Date: Wed, 15 Mar 2000 15:28:30 -0500 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at 03/15/2000 03:28:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Loop Detected Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4209 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 example given in section 12.1 of draft-ietf-webdav-binding-protocol-02 of a PROPFIND depth infinity in the presence of a loop implies that the propstat for the loop detected resource only contains the property names and not their values (again). Although I can understand the point of this in the majority of cases, it does prevent the client from reconstructing the graph of resources since they cannot determine the destination of the binding. If the properties were returned the client could PROPFIND depth infinity on the resource identifier and reconstruct the graph. Tim From w3c-dist-auth-request@w3.org Wed Mar 15 16:13:21 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01479 for ; Wed, 15 Mar 2000 16:13:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA20818; Wed, 15 Mar 2000 16:07:58 -0500 (EST) Resent-Date: Wed, 15 Mar 2000 16:07:58 -0500 (EST) Resent-Message-Id: <200003152107.QAA20818@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 15 Mar 2000 13:07:28 -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. March 15, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4211 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 Advanced Collections Teleconference March 15, 2000 Present: Judy Slein, Jason Crawford, Geoff Clemm, Jim Whitehead, Chuck Fay Minutes recorded by Jim Whitehead *** Note that decisions made during the teleconference are always subject to review on the mailing list. The mailing list is the final arbiter of consensus on any issue. Note also, that the revised Bindings Protocol specification, and Redirect References protocol produced as a result of this conference call will also be subject to review by the mailing list. *** BINDINGS: Began with some discussion of Geoff Clemm's proposed language for binding "integrity". His proposed language is: If a DELETE request, MOVE request, or a request with an Overwrite:T header is applied to a resource identified by the URL /path/x, and /path identifies a collection that supports the BIND/UNBIND methods, then the request MUST have the same effect as an UNBIND of x from /path. In particular, if the request succeeds, the binding named x MUST be removed from the collection indentified by /path, and whether or not the request succeeds, no other bindings from any other collection may be removed. Hashed around this language a bit. Batted around the language, "if BIND to a resource is supported, then a DELETE/MOVE/Overwrite:T to that resource MUST have the same effect as an UNBIND." But, this doesn't capture the fact that the collection containing the resource must also support BIND for this assertion to be true. REDIRECT REFERENCES: Issue #49: Section 6.2 is going away (based on discussion last week), so this issue no longer applies. Issue #50: Discussed having the Redirect-Ref header give the value of the redirection (i.e., the relative or absolute URL), and thus not require a separate method just to read the value of the redirect resource. Agreed that this is a good idea, and will put this into the spec. Decided to disagree with Yaron, and not accept his wording change. Felt that his wording suggestion did not make things more clear. Issue #51: Agreed to delete the first paragraph of section 7. Issue #52: Disagree with Yaron. Important use cases for relative URLs have been posted to the mailing list. Need relative URLs to allow a redirect resource to behave correctly if it has multiple URL mappings, and is referring to a resource within its local namespace. Issue #53: Decided to make this functionality "SHOULD" behavior, since it is potentially expensive to implement, and is difficult to modularize, as was pointed out in the comment. Will also add language describing what happens if the SHOULD behavior is not implemented (i.e., a 404 is returned). Issue #54: This was resolved in a discussion on the mailing list. No changes needed here. Issue #55: Agreed to accept Yaron's suggestion and extend the IANA considerations section with methods, headers, and XML elements. Issue #56: Agreed that we will add an example showing use of non-HTTP URLs in a Redirect Reference. Issue #57: Previously agreed that we will add language forbidding servers to do redirect reference cleanup. Issue #58: Agreed that we will provide a mechanism for update of the value of a Redirect Reference. Issue #59: Disagreed. This is too complex, and doesn't appear to address a pressing use scenario. Issue #60: Agreed to delete the paragraph containing Also discussed what should be returned by a PROPFIND multistatus response that includes a redirect reference resource. Agreed that only the location information, and nothing else, should be returned. The rationale is that the location is necessary to return, since this tells you where the location would be redirected. But, if you need to know whether it is a redirect reference, or an ordinary resource, it is possible to submit a PROPFIND asking for the redirect value. Agreed to table this, and reconsider next week. Issue #61: Decided to no longer call DAV:location a "psuedoproperty", and just define a new XML element for this. This contradicts an earlier decision (Yaron raised this issue previously). But, we'll still encourage the WebDAV Distributed Authoring protocol to add this in for 302 responses. Issue #62: Agreed to delete the sentence, "Until then, non-referencing clients will not ..." Issue #63: Agreed to delete section 7.1. Will reword 7.2 to avoid concerns with "poses special problems" and "due to atomicity". Issue #64: We need relative URIs. As a result of needing relative URIs, we need a different mechanism from the Location header, which must be an absolute URI. So, do not accept this suggestion. Issue #65: This issue was discussed in the past, and even made it into some previous drafts. In the end, the difficulty of having some special cases that differ from a consistent set of semantics outweighed the advantage of the special cases. So, we disagree with the suggestion. Issue #66: Agreed, will make this change. Issue #67: Wording right now is wrong, so we agree with this suggestion. Need to get rid of the end of the 2nd to last sentence, and the beginning of the last sentence, mushing them together. Issue #68: This issue has been noted on the WebDAV issues list as "DEEP_LOCK_ERROR_STATUS". Will keep using 207, and will encourage RFC 2518 to be changed to use 207 in this case. Issue #69: Disagree. The use of 424 in this case is correct (see def'n of 424 in RFC 2518) Issue #70: Agreed that we feel that no additional text is needed in this case. The draft as-is is adequate. Issue #71: We accept this change, it's right. Issue #72: Add a note about not wanting two slashes in a row. Use this for rationale for warning against ending a redirect reference target with a slash, since this will result in two slashes in a row. *** End of teleconference *** From w3c-dist-auth-request@w3.org Wed Mar 15 16:34:37 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10375 for ; Wed, 15 Mar 2000 16:34:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21191; Wed, 15 Mar 2000 16:29:58 -0500 (EST) Resent-Date: Wed, 15 Mar 2000 16:29:58 -0500 (EST) Resent-Message-Id: <200003152129.QAA21191@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D777@chef.lex.rational.com> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 15 Mar 2000 16:29:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Loop Detected Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4212 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 Tim. Furthermore, I would suggest that the example use the DAV:urn property (aka DAV:resource-id), since that illustrates the value of the DAV:urn property (the DAV:display-name is not a reliable way of identifying a resource). Cheers, Geoff -----Original Message----- From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com] Sent: Wednesday, March 15, 2000 3:29 PM To: w3c-dist-auth@w3.org Subject: Loop Detected The example given in section 12.1 of draft-ietf-webdav-binding-protocol-02 of a PROPFIND depth infinity in the presence of a loop implies that the propstat for the loop detected resource only contains the property names and not their values (again). Although I can understand the point of this in the majority of cases, it does prevent the client from reconstructing the graph of resources since they cannot determine the destination of the binding. If the properties were returned the client could PROPFIND depth infinity on the resource identifier and reconstruct the graph. Tim From w3c-dist-auth-request@w3.org Wed Mar 15 18:07:41 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15413 for ; Wed, 15 Mar 2000 18:07:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA24748; Wed, 15 Mar 2000 18:02:31 -0500 (EST) Resent-Date: Wed, 15 Mar 2000 18:02:31 -0500 (EST) Resent-Message-Id: <200003152302.SAA24748@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D778@chef.lex.rational.com> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 15 Mar 2000 18:01:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Loops II Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4213 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'm probably not as concerned by the denial of service attack as I am that the client will be burdened with large numbers of duplicates when they try a PROPFIND in this case. Perhaps instead of (in addition to?) "Loop Detected", we could have a "Duplicate Detected" status, which would provide a way for a server to say that this resource has already appeared in the PROPFIND. If we returned all properties with duplicates, this would still result in much redundancy in the PROPFIND result. I guess I'd like to modify my earlier response to say we *only* return the DAV:urn property in the case of duplicates. As a final thought, shouldn't "Duplicate Detected" be a 2xx status, since it is not an error, but rather just an abbreviation? Cheers, Geoff -----Original Message----- From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com] Sent: Wednesday, March 15, 2000 3:34 PM To: w3c-dist-auth@w3.org Subject: Loops II An observation: Although infinite loops are broken using Loop Detected rules, since all (non-circular) paths are returned by deep operations it is trivial to construct an n**m walks graph by having n levels with m bindings between each. This would be a prime candidate for denial of service type attacks against a server. Tim From w3c-dist-auth-request@w3.org Thu Mar 16 09:40:45 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26472 for ; Thu, 16 Mar 2000 09:40:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA15678; Thu, 16 Mar 2000 09:36:15 -0500 (EST) Resent-Date: Thu, 16 Mar 2000 09:36:15 -0500 (EST) Resent-Message-Id: <200003161436.JAA15678@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F9AD@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Clemm, Geoff'" , w3c-dist-auth@w3.org Date: Thu, 16 Mar 2000 09:35:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Loop Detected Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4214 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list We can make it that the property values get returned for the 506 resource, but as you say that will not in general be helpful to the client in reconstructing the graph. It would just be a matter of luck if the properties requested allowed you to identify the resource bound to the href. As you say, the only property that allows this is DAV:urn. So it's not just a matter of changing the example to one where DAV:urn was requested. I know you will hate this suggestion, but we could have servers always return DAV:urn, whether it was requested or not, for all the resources if there is a 506 anywhere in the response. Or we could add a note suggesting to clients that if they want to reconstruct the graph, they should submit another PROPFIND Depth: infinity to the same resource, requesting DAV:urn. -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Wednesday, March 15, 2000 4:29 PM To: w3c-dist-auth@w3.org Subject: RE: Loop Detected I agree with Tim. Furthermore, I would suggest that the example use the DAV:urn property (aka DAV:resource-id), since that illustrates the value of the DAV:urn property (the DAV:display-name is not a reliable way of identifying a resource). Cheers, Geoff -----Original Message----- From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com] Sent: Wednesday, March 15, 2000 3:29 PM To: w3c-dist-auth@w3.org Subject: Loop Detected The example given in section 12.1 of draft-ietf-webdav-binding-protocol-02 of a PROPFIND depth infinity in the presence of a loop implies that the propstat for the loop detected resource only contains the property names and not their values (again). Although I can understand the point of this in the majority of cases, it does prevent the client from reconstructing the graph of resources since they cannot determine the destination of the binding. If the properties were returned the client could PROPFIND depth infinity on the resource identifier and reconstruct the graph. Tim From w3c-dist-auth-request@w3.org Thu Mar 16 09:55:26 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02738 for ; Thu, 16 Mar 2000 09:55:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA16181; Thu, 16 Mar 2000 09:51:23 -0500 (EST) Resent-Date: Thu, 16 Mar 2000 09:51:23 -0500 (EST) Resent-Message-Id: <200003161451.JAA16181@www19.w3.org> To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: "Tim Ellison/OTT/OTI" Date: Thu, 16 Mar 2000 09:48:20 -0500 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at 03/16/2000 09:48:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Loop Detected Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4215 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 think the simplest solution is to say that the server answers the property values in a Loop Detected propstat. This is probably simpler for the server anyway (not having to strip out values because it is a loop detected status). A note in the spec can point out that if clients want to reconstruct the graph they can deep propfind the dav:urn. I don't think it is a good idea to return a property the client didn't ask for. Tim "Slein, Judith A" , com> w3c-dist-auth@w3.org Sent by: cc: w3c-dist-auth-requ Subject: RE: Loop Detected est@w3.org 16-03-00 09:35 AM We can make it that the property values get returned for the 506 resource, but as you say that will not in general be helpful to the client in reconstructing the graph. It would just be a matter of luck if the properties requested allowed you to identify the resource bound to the href. As you say, the only property that allows this is DAV:urn. So it's not just a matter of changing the example to one where DAV:urn was requested. I know you will hate this suggestion, but we could have servers always return DAV:urn, whether it was requested or not, for all the resources if there is a 506 anywhere in the response. Or we could add a note suggesting to clients that if they want to reconstruct the graph, they should submit another PROPFIND Depth: infinity to the same resource, requesting DAV:urn. -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Wednesday, March 15, 2000 4:29 PM To: w3c-dist-auth@w3.org Subject: RE: Loop Detected I agree with Tim. Furthermore, I would suggest that the example use the DAV:urn property (aka DAV:resource-id), since that illustrates the value of the DAV:urn property (the DAV:display-name is not a reliable way of identifying a resource). Cheers, Geoff -----Original Message----- From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com] Sent: Wednesday, March 15, 2000 3:29 PM To: w3c-dist-auth@w3.org Subject: Loop Detected The example given in section 12.1 of draft-ietf-webdav-binding-protocol-02 of a PROPFIND depth infinity in the presence of a loop implies that the propstat for the loop detected resource only contains the property names and not their values (again). Although I can understand the point of this in the majority of cases, it does prevent the client from reconstructing the graph of resources since they cannot determine the destination of the binding. If the properties were returned the client could PROPFIND depth infinity on the resource identifier and reconstruct the graph. Tim From w3c-dist-auth-request@w3.org Thu Mar 16 11:25:22 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04859 for ; Thu, 16 Mar 2000 11:25:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA20012; Thu, 16 Mar 2000 11:19:56 -0500 (EST) Resent-Date: Thu, 16 Mar 2000 11:19:56 -0500 (EST) Resent-Message-Id: <200003161619.LAA20012@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D77C@chef.lex.rational.com> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 16 Mar 2000 11:18:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Loop Detected Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4216 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 you probably saw from my response to the "Loops II" thread, I believe that we should have a new status code called "Duplicate Detected", and that the Duplicate-Detected status MUST indicate the DAV:urn property (but no other property) of the duplicate resource. So this isn't quite what you propose below (since the client still has to explicitly request the DAV:urn property for non-"Duplicate-Detected" members, but I think it gives you the desired functionality. Cheers, Geoff -----Original Message----- From: Slein, Judith A [mailto:JSlein@crt.xerox.com] Sent: Thursday, March 16, 2000 9:36 AM To: 'Clemm, Geoff'; w3c-dist-auth@w3.org Subject: RE: Loop Detected We can make it that the property values get returned for the 506 resource, but as you say that will not in general be helpful to the client in reconstructing the graph. It would just be a matter of luck if the properties requested allowed you to identify the resource bound to the href. As you say, the only property that allows this is DAV:urn. So it's not just a matter of changing the example to one where DAV:urn was requested. I know you will hate this suggestion, but we could have servers always return DAV:urn, whether it was requested or not, for all the resources if there is a 506 anywhere in the response. Or we could add a note suggesting to clients that if they want to reconstruct the graph, they should submit another PROPFIND Depth: infinity to the same resource, requesting DAV:urn. -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Wednesday, March 15, 2000 4:29 PM To: w3c-dist-auth@w3.org Subject: RE: Loop Detected I agree with Tim. Furthermore, I would suggest that the example use the DAV:urn property (aka DAV:resource-id), since that illustrates the value of the DAV:urn property (the DAV:display-name is not a reliable way of identifying a resource). Cheers, Geoff -----Original Message----- From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com] Sent: Wednesday, March 15, 2000 3:29 PM To: w3c-dist-auth@w3.org Subject: Loop Detected The example given in section 12.1 of draft-ietf-webdav-binding-protocol-02 of a PROPFIND depth infinity in the presence of a loop implies that the propstat for the loop detected resource only contains the property names and not their values (again). Although I can understand the point of this in the majority of cases, it does prevent the client from reconstructing the graph of resources since they cannot determine the destination of the binding. If the properties were returned the client could PROPFIND depth infinity on the resource identifier and reconstruct the graph. Tim From w3c-dist-auth-request@w3.org Thu Mar 16 11:35:53 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09209 for ; Thu, 16 Mar 2000 11:35:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA20333; Thu, 16 Mar 2000 11:30:59 -0500 (EST) Resent-Date: Thu, 16 Mar 2000 11:30:59 -0500 (EST) Resent-Message-Id: <200003161630.LAA20333@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D77D@chef.lex.rational.com> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 16 Mar 2000 11:29:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Loop Detected Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4217 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: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com] I think the simplest solution is to say that the server answers the property values in a Loop Detected propstat. This is probably simpler for the server anyway (not having to strip out values because it is a loop detected status). If the server is going to generate a "Duplicate Detected" status, I don't think it would be any problem for it to stuff a DAV:urn in there instead of the properties list. If the client cares what those properties are, it can use the DAV:urn value to find them in the PROPFIND result body. I think that it is important that binding not introduce unnecessary duplication of property values in PROPFIND responses. A note in the spec can point out that if clients want to reconstruct the graph they can deep propfind the dav:urn. Yes, but that doesn't help them avoid having to parse all those redundant property entries in the PROPFIND response. I don't think it is a good idea to return a property the client didn't ask for. I agree that we shouldn't force a server to return DAV:urn for normal status responses, but I think it reasonable to require the DAV:urn appear for the "Duplicate Detected" status responses. Cheers, Geoff "Slein, Judith A" , com> w3c-dist-auth@w3.org Sent by: cc: w3c-dist-auth-requ Subject: RE: Loop Detected est@w3.org 16-03-00 09:35 AM We can make it that the property values get returned for the 506 resource, but as you say that will not in general be helpful to the client in reconstructing the graph. It would just be a matter of luck if the properties requested allowed you to identify the resource bound to the href. As you say, the only property that allows this is DAV:urn. So it's not just a matter of changing the example to one where DAV:urn was requested. I know you will hate this suggestion, but we could have servers always return DAV:urn, whether it was requested or not, for all the resources if there is a 506 anywhere in the response. Or we could add a note suggesting to clients that if they want to reconstruct the graph, they should submit another PROPFIND Depth: infinity to the same resource, requesting DAV:urn. -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Wednesday, March 15, 2000 4:29 PM To: w3c-dist-auth@w3.org Subject: RE: Loop Detected I agree with Tim. Furthermore, I would suggest that the example use the DAV:urn property (aka DAV:resource-id), since that illustrates the value of the DAV:urn property (the DAV:display-name is not a reliable way of identifying a resource). Cheers, Geoff -----Original Message----- From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com] Sent: Wednesday, March 15, 2000 3:29 PM To: w3c-dist-auth@w3.org Subject: Loop Detected The example given in section 12.1 of draft-ietf-webdav-binding-protocol-02 of a PROPFIND depth infinity in the presence of a loop implies that the propstat for the loop detected resource only contains the property names and not their values (again). Although I can understand the point of this in the majority of cases, it does prevent the client from reconstructing the graph of resources since they cannot determine the destination of the binding. If the properties were returned the client could PROPFIND depth infinity on the resource identifier and reconstruct the graph. Tim From w3c-dist-auth-request@w3.org Thu Mar 16 17:38:41 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23981 for ; Thu, 16 Mar 2000 17:38:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA04943; Thu, 16 Mar 2000 17:32:11 -0500 (EST) Resent-Date: Thu, 16 Mar 2000 17:32:11 -0500 (EST) Resent-Message-Id: <200003162232.RAA04943@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Slein, Judith A" cc: "'Clemm, Geoff'" , w3c-dist-auth@w3.org Message-ID: <852568A4.007BBA93.00@D51MTA03.pok.ibm.com> Date: Thu, 16 Mar 2000 17:31:28 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Loop Detected Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4218 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >> Or we could add a note suggesting to clients that if they want to reconstruct the graph, they should submit another PROPFIND Depth: infinity to the same resource, requesting DAV:urn. >> Or we could have structured status codes that might include parameters with the details of the status. Yaron is always mutting about us doing this some day. :-) From w3c-dist-auth-request@w3.org Wed Mar 22 14:01:54 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16525 for ; Wed, 22 Mar 2000 14:01:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA09979; Wed, 22 Mar 2000 13:59:26 -0500 (EST) Resent-Date: Wed, 22 Mar 2000 13:59:26 -0500 (EST) Resent-Message-Id: <200003221859.NAA09979@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D7B2@chef.lex.rational.com> From: "Clemm, Geoff" To: "'w3c-dist-auth@w3.org'" Date: Wed, 22 Mar 2000 13:57:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4219 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 propose that we delete all uses of the term "integrity" from the spec, and instead say: RFC 2518 allows resource deletion requests, such as DELETE and MOVE, to do a "best effort" deletion on collections, where only some of the members of the collection are deleted following the request. In order to guarantee the more predictable BIND/UNBIND semantics when a binding unaware client is used to do authoring on a binding aware server, a binding aware server is required to map deletion requests into the appropriate UNBIND request. More formally: If a DELETE request, MOVE request, or a request with an Overwrite:T header is applied to a resource identified by the URL /path/x, and /path identifies a collection that supports the BIND/UNBIND methods, then the request MUST have the same effect as an UNBIND of x from /path. In particular, if the request succeeds, the binding named x MUST be removed from the collection indentified by /path, and whether or not the request succeeds, no other bindings from any other collection may be removed. As a corollary to this rule, if a DELETE request, MOVE request, or a request with an Overwrite:T header is applied to a collection identified by the URL /path1, then a resource identified by the URL /path1/path2/path3 MUST NOT be deleted if /path1/path2 supports the BIND/UNBIND operation. Cheers, Geoff -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Yaron Goland Sent: Sunday, January 16, 2000 8:49 PM To: w3c-dist-auth@w3.org Subject: WebDAV Bindings - Issue Yaron.MrIntegrity The last sentence of the last paragraph of section 4 reads "Implementations MUST ensure the integrity of bindings." Similar language is used in the second paragraph of section 5.1. However the term "integrity" was never well defined inside of the specification. As such it is impossible to comply with this requirement in an interoperable way. I would strongly caution against attempting to specify the definition for integrity, English is much too inexact a language for such an attempt to be successful. As such, I move that both sentences be removed and be replaced with a series of statements that define, in exact language, the requirements that are to be represented by the term "integrity", each sentence properly qualified with a MUST. From w3c-dist-auth-request@w3.org Wed Mar 22 15:59:48 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28379 for ; Wed, 22 Mar 2000 15:59:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA14184; Wed, 22 Mar 2000 15:58:06 -0500 (EST) Resent-Date: Wed, 22 Mar 2000 15:58:06 -0500 (EST) Resent-Message-Id: <200003222058.PAA14184@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 22 Mar 2000 12:57:22 -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: Adv. Col. Teleconference 22 Mar 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4220 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 Advanced Collections Teleconference March 22, 2000 Present: Jason Crawford, Judy Slein, Jim Whitehead (notetaker), Geoff Clemm *** Note that decisions made during the teleconference are always subject to review on the mailing list. The mailing list is the final arbiter of consensus on any issue. Note also, that the revised Bindings Protocol specification, and Redirect References protocol produced as a result of this conference call will also be subject to review by the mailing list. *** Began by discussing Geoff's proposed language for resolving issue Yaron.MrIntegrity, at http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0444.html Tentatively liked this new langauge, but it was sent out just prior to the teleconference. We need to see if there will be any discussion of this topic on the mailing list. Next started considering issues #43-45 of the bindings spec. Issue #43: Revisited name for the bindings property. Judy suggested the name "parents", and this was adopted. Issue #44: Discussed resolutions to the loop detected issue identified by Tim Ellison on the mailing list. Two approaches were examined. Approach #1: Pass back URNs for all the resources in the multistatus, and then the client would be able to piece together which URLs were associated with which URNs, and thus pick out where the loop occurred. Approach #2: Just only pass back the URL of the resource being pointed to, and only pass this back for the resource for which the 506 Loop Detected is reported. This will identify the URL of the looped-back-to resource, and this can be reported by the client to the user. Also discussed whether there should be a "duplicate detected" status code, and whether that is the same as "loop detected". Also, discussed whether loop detected should be a 2xx status code, since the existence of a loop is not an error. The duplicate detected status code would allow propfind requests to be smaller in the case where there were multiple bindings to the same resource in the propfind output. But, receiving this response back might break downlevel clients that are not expecting this response. But, the necessary loop detected code might also break downlevel clients. Agreed to change loop detected to a 2xx. Tentatively agreed to have a duplicate detected status code, it will be a 2xx, and the properties for the resource that issues the duplicate detected status code will be in the propfind, and will also return the href of the resource being pointed to (tentatively called "dup-href") as a psuedo-property, but no further children will be included in the listing (have the same URL stem). Issue #45: Not listing all the children every time does address the denial of service. But, in the general case, the only reliable DAV prevention of denial of service guarantee is to limit the number of threads that can be used for DAV requests. Redirect References: Issue #60: (revisited this) Agreed to return both the location (in a pseudo-property), and the redirectref value (as a real property) for 302 responses in a multistatus. Issue #73: Agreed to accept Juergen's suggested ascii art for Section 10. Issue #74: Agreed that we will use the same term consistently for plain/ordinary HTTP/1.1 redirects. Issue #75: Agreed to delete the sentence. Issue #76: Disagree. DAV:location cannot be a live property, since it needs to be the absolute location, and this is why we need a separate target property. Issue #77: Agreed to this change. Issue #78: Agreed to this change. Agree that this is not new to this protocol, but this is explicitly noted in the document. Issue #79: Agreed, there is nothing you can do about someone making a redirect reference to another resource, since they are weak links. We will delete the sentence noted in this comment. Issue #80: Will modify the i18n section to account for this draft being standalone now. Issue #81: We will make this change. Issue #82: Will modify the IANA section to account for this draft being standalone now. We will also be listing new methods, headers, properties, etc. Issue #83: Agreed, we will remove references to the bindings specification. Issue #84: Will change the name of the section to be "Changes to the ..." instead of "Extensions to the..." Issue #85: Looked at RFC 2616 3xx status codes. Looks like we may also want to allow authoring of 303 and 307, in addition to 301 and 302. *** End of teleconference *** From w3c-dist-auth-request@w3.org Wed Mar 22 19:19:01 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08565 for ; Wed, 22 Mar 2000 19:19:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA19601; Wed, 22 Mar 2000 19:09:54 -0500 (EST) Resent-Date: Wed, 22 Mar 2000 19:09:54 -0500 (EST) Resent-Message-Id: <200003230009.TAA19601@www19.w3.org> Date: Wed, 22 Mar 2000 19:05:44 -0500 Message-Id: <200003230005.TAA22227@hunchuen.crystaliz.com> X-Authentication-Warning: hunchuen.crystaliz.com: sv set sender to sv@hunchuen.crystaliz.com using -f From: Sankar Virdhagriswaran To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Subject: announcement -- release of software Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4221 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Folks, I apologize for sending this note here. But, I felt that some of you folks may be interested. We are releasing a distributed configuration management system we have been developing called Concorde at www.digitaldig.com. It is an all Java system and uses change sets as a mechanism to implement distributed configuration management. It is also an all Java implementation (Java 1.2). It has a few other bells and whistles that you can read up at the above URL. So, why am I sending this note to a group of DELTA-V and WEB-DAV afficinados? Well, Concorde does not support WEB-DAV or DELTA-V. This sounds counter intuitive, right? But, read on... We are also interested in releasing it in open source so that some body out there can add WEB-DAV and/or DELTA-V support to the system. Currently, its distribution works using RMI The open source model we want to use is similar to Java. We want to open the copyright to the parts we have developed and you own the copyright to the parts you developed. There is a form on that site you have to answer before you download the Windows NT distribution. In that form there is a field that asks you if you would be interested in participating in such an open source implementation. Let us know and I will follow-up with you. If you have any thoughts on our approach to promote open source development, I would like to hear about it too. But, first play with the system and then decide if it is worth your while to do the extension. Additionally, the ZIP file contains the Java compiled version which has been tested only on NT. We are working on compiling and testing it on Linux. You can also volunteer to test it on other platforms that support Java 1.2. I appreciate any of your comments. Sankar P.S: The ZIP file in that site does not contain source. From w3c-dist-auth-request@w3.org Wed Mar 22 19:53:06 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22602 for ; Wed, 22 Mar 2000 19:53:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA20796; Wed, 22 Mar 2000 19:42:35 -0500 (EST) Resent-Date: Wed, 22 Mar 2000 19:42:35 -0500 (EST) Resent-Message-Id: <200003230042.TAA20796@www19.w3.org> From: Jim Whitehead To: WebDAV WG , acl@webdav.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Wed, 22 Mar 2000 16:41:49 -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: Reminder: Access Control teleconf. Mar. 24 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4222 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 teleconference on the topic of access control for WebDAV will be held this Friday. All are welcome to attend this teleconference, though if you're planning on attending, please send Eric Sedlar an email, so he can adjust the capacity of the bridge. Many thanks go to Eric and Oracle for hosting the teleconference. Access Control Teleconference Friday, March 24, 2000 11AM-12noon (Pacific) Phone number: 888-700-6725 Meeting ID: 932328225 Password: 2518 Note that Greg Stein has set up a mailing list for discussion of access control issues, with instructions on how to join given at: http://mailman.webdav.org/mailman/listinfo/acl The initial agenda for the teleconference is as follows (please send me an email if you have any additional topics): - timeline for finishing work - scoping the effort (what's core, what's an extension, what's out) - assigning document editors - evaluate existing documents as a base for continuing work - are the goals still the same? - methods vs. properties for marshalling mechanism - Jim From w3c-dist-auth-request@w3.org Mon Mar 27 15:31:14 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24477 for ; Mon, 27 Mar 2000 15:31:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA15945; Mon, 27 Mar 2000 15:27:16 -0500 (EST) Resent-Date: Mon, 27 Mar 2000 15:27:16 -0500 (EST) Resent-Message-Id: <200003272027.PAA15945@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F9C3@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Clemm, Geoff'" , "'w3c-dist-auth@w3.org'" Date: Mon, 27 Mar 2000 15:26:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4223 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 looks like most of what we want for guaranteeing integrity of bindings. What we want to avoid is a situation where a binding might be broken or removed as a side effect of an operation on some other binding. We don't want a URI to stop working as a result of a DELETE or MOVE operation submitted to a different Request-URI. The sort of case we initially considered when talking about integrity is not entirely covered by your proposed language: Suppose you have two separate servers (or two parts of the namespace of one server that are separately managed) and you create a binding from a location on one server to a target resource on the other. Then unless you had some out-of-band way of collaborating on the creation of this new binding, the server managing the target resource would not know that this binding had been created. Then when the last binding it knows about is deleted, it will be free to destroy the resource, and the binding on the other server may be broken. The server can be obeying the rules you state in your message (as far as it knows) and still do something that will cause the binding to be broken. So we need to address some constraints to the server that allowed the binding to be created in the first place -- it should never have allowed the binding to be created unless it had some way to communicate the existence of the binding to the server managing the target resource. --Judy -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Wednesday, March 22, 2000 1:58 PM To: 'w3c-dist-auth@w3.org' Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity I propose that we delete all uses of the term "integrity" from the spec, and instead say: RFC 2518 allows resource deletion requests, such as DELETE and MOVE, to do a "best effort" deletion on collections, where only some of the members of the collection are deleted following the request. In order to guarantee the more predictable BIND/UNBIND semantics when a binding unaware client is used to do authoring on a binding aware server, a binding aware server is required to map deletion requests into the appropriate UNBIND request. More formally: If a DELETE request, MOVE request, or a request with an Overwrite:T header is applied to a resource identified by the URL /path/x, and /path identifies a collection that supports the BIND/UNBIND methods, then the request MUST have the same effect as an UNBIND of x from /path. In particular, if the request succeeds, the binding named x MUST be removed from the collection indentified by /path, and whether or not the request succeeds, no other bindings from any other collection may be removed. As a corollary to this rule, if a DELETE request, MOVE request, or a request with an Overwrite:T header is applied to a collection identified by the URL /path1, then a resource identified by the URL /path1/path2/path3 MUST NOT be deleted if /path1/path2 supports the BIND/UNBIND operation. Cheers, Geoff -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Yaron Goland Sent: Sunday, January 16, 2000 8:49 PM To: w3c-dist-auth@w3.org Subject: WebDAV Bindings - Issue Yaron.MrIntegrity The last sentence of the last paragraph of section 4 reads "Implementations MUST ensure the integrity of bindings." Similar language is used in the second paragraph of section 5.1. However the term "integrity" was never well defined inside of the specification. As such it is impossible to comply with this requirement in an interoperable way. I would strongly caution against attempting to specify the definition for integrity, English is much too inexact a language for such an attempt to be successful. As such, I move that both sentences be removed and be replaced with a series of statements that define, in exact language, the requirements that are to be represented by the term "integrity", each sentence properly qualified with a MUST. From w3c-dist-auth-request@w3.org Tue Mar 28 17:28:49 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27522 for ; Tue, 28 Mar 2000 17:28:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA02115; Tue, 28 Mar 2000 17:26:31 -0500 (EST) Resent-Date: Tue, 28 Mar 2000 17:26:31 -0500 (EST) Resent-Message-Id: <200003282226.RAA02115@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 28 Mar 2000 14:25:33 -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: Access Control Teleconf. Mar. 31 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4224 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 Continuing on from last week's teleconference, a teleconference on the topic of access control for WebDAV will be held this Friday. All are welcome to attend this teleconference, though if you're planning on attending, and didn't attend last week, please send Eric Sedlar an email, so he can adjust the capacity of the bridge. Big thanks go to Eric and Oracle for hosting the teleconference. Access Control Teleconference Friday, March 31, 2000 11AM-12noon (Pacific) Phone number: 888-700-6725 Meeting ID: 932328225 Password: 2518 (these are the same as last week) Note that Greg Stein has set up a mailing list for discussion of access control issues, with instructions on how to join given at: http://mailman.webdav.org/mailman/listinfo/acl My proposed agenda for the teleconference is as follows (please send me an email if you have any additional topics): - scoping the effort (what's core, what's an extension, what's out) - continuing this discussion from last week - evaluate existing documents as a base for continuing work - are the goals still the same? - methods vs. properties for marshalling mechanism - Jim From w3c-dist-auth-request@w3.org Tue Mar 28 18:11:10 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28130 for ; Tue, 28 Mar 2000 18:11:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA03965; Tue, 28 Mar 2000 18:10:07 -0500 (EST) Resent-Date: Tue, 28 Mar 2000 18:10:07 -0500 (EST) Resent-Message-Id: <200003282310.SAA03965@www19.w3.org> From: Jim Whitehead To: acl@webdav.org, WebDAV WG MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Tue, 28 Mar 2000 15:09:10 -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: Adelaide and Access Control Teleconf. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4225 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 BTW, if you're attending the Adelaide IETF meeting, and want to participate in the access control teleconference this Friday, please send me an email so we can arrange a call time that is good for you. - Jim From w3c-dist-auth-request@w3.org Thu Mar 30 02:40:48 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13714 for ; Thu, 30 Mar 2000 02:40:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA22597; Thu, 30 Mar 2000 02:38:02 -0500 (EST) Resent-Date: Thu, 30 Mar 2000 02:38:02 -0500 (EST) Resent-Message-Id: <200003300738.CAA22597@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3c.org Message-ID: <852568B2.0029DDDD.00@d54mta03.raleigh.ibm.com> Date: Thu, 30 Mar 2000 02:32:15 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id CAA22577 Subject: ACLs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4226 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: 8bit Glad to see the renewed activity on WebDAV ACLs! I read this stuff in a hurry, so I may have not understood all the potential issues or may have missed some. But here's a start at least. I'm glad to see renewed activity in ACLs. We should also take a look at emerging ACL models that are already out there too. For example, the Java2 security model, IBM SecureWay, Windows2000, etc. No need to invent a new one if an existing model would do the job. Review of the 00 Spec: Need to examine the notion of ACL inheritance in the presence of bindings where an actual resource may have more than one parent. Consider deleting dynamic ACL inheritance and apply ACL edits on a collection with a depth header. Delete the concept of hierarchical properties. WebDAV should now know about the structure of a property value any more than it should know about the structure of the contents of a resource. This creates a coupling between the access protocol and resource types that is not in the spirit of HTTP. Remove ACLs on individual properties for now. This capability raises too many issues. For example, should properties belong to groups so ACLs can be applied to the group rather than just individual properties. Need to be specific about what it means for a principal to (indirectly through membership in various groups) to have both grant and deny rights on the same resource. Deny should take precedence over grant. If property ACLs are supported, add/deletechild could also apply to adding and deleting properties. If not, use add/deletemember instead of child to be consistent with collection nomenclature. -------------------------------------------------------------------------- Geoff's 01 Spec: -------------------------------------------------------------------------- March 24 Call: An ACL has a list of ACEs.  Each server has a maximum number of ACEs per ACL, which is implementation dependent.  The current proposal is to require implementers to support at least 1 ACE granting permission to a user, and 1 ACE granting permission to a group.  Implementations are required to implement a minimum of zero ACEs applying to a user or a group What user? The owner? What group? I don't agree with the resolution of this issue. I think it should be possible (is now) to have no ACL for a resource. This implies it is not under access control and all rights are available to all principals. Similarly it should be possible to have an ACL which is empty implying no rights are granted to anyone. (Note that the owner always has the right to change the ACLs, this can't be denied implicitly or explicitly). Each ACE specifies a specific principal - an individual authentication id, or an id of a group of authentication ids. Given the ACL model, I don't know what a group permission would mean in this context. ACL is a property of a resource, from a ?model? point of view.  How they are marshaled across the wire (e.g. via PROPPATCH or ACL methods) should be left to discussion at the end of the process. Don't agree. An ACL is not a property, its an ACL. ACLs as properties raises the issue of exposing ACL information to PROPFIND/PROPPATCH, or adding a bunch of special cases to prevent this. Servers should be free to implement ACLs any way they want, and not treat them as properties. How ACLs are marshalled across the wire *is* the business of the protocol, not the server. PROPPATCH should not be overloaded with updating access control. I think keeping ACLs and properties separate will avoid a lot of complexity, controversy, and headach without bloating the protocol with too many more methods. ACLs and properties are already separate concepts regardles of how they are manipulated and marshalled. Advanced access control provides more sophisticated capabilities, such as the ability to both grant and deny rights, the ability to define rights other than read and write, ACL inheritance, and access control on individual properties of a resource. A particular resource may support only a subset of the advanced access control capabilities. I think we should try to avoid two levels of access control. I suggest that grant and deny are concepts that apply to read and write access and are really already there in basic access. A "right" should just be a string, just like lock scope and type. A server should be able to advertise any rights on any resource, and this should be reported as part of the ACL discovery on a resource. This is no more complicated than the similar mechanisms for locking and should be include in basic access control. ACL inheritance should just be deleted in favor of using a depth header on the ACL method when the request URL references a collection. I think this gets us what we need all in one spec. I think we should defer ACLs on individual properties. Every resource MUST be associated with two principals: a simple principal called the "owner" of that resource and a compound principal called the "group" of that resource. An ACE that associates rights to the owner or group of a resource rather than to a particular principal can then be shared by a number of different resources. I think a resource should have an owner, and this should be the same as the DAV:author? But I don't think a resource needs a group. This sharing should be done by applying the ACE or a complete ACL to the other resource rather than implicitly through the owner or group. This can be done by getting the ACL information and applying it to another resource, or using depth on a collection. ACLs should be associated with resources only, not resources and principals. But I may not understand the details of the proposal. By default, a principal has no access rights to an object. The current owner must always have the right to change owner and modify ACLs. This can never be denied. should be: The semantics already specify that rights may not be available. deny just provides a conveniencs for listing what you can't do rather than listing with you can do. The combination of right and deny just make the ace smaller. There's no new semantics. With just read and write rights, this doesn't matter, but if the right can be any string including All, then it does. For example, would let a principal do everyting but delete but doesn't require a potentially long list. The owner-principal XML element represents the owner of a resource. This principal allows multiple resources to share the same ACL, but have the ACL apply to whatever principal is identified as the owner of the resource. So owner-principal is an alias in an ACE that references the current owner of the resource, whatever that principal might be? Where are the rights associated with a principal stored? All rights are currently associated with a resource through an ACE. The same principal may have very different rights on different resources. There are no rights that are just associated with the principal. A principal is not a resource that can have anything associated with it. Its just an opaque string. I don't quite get this and don't see why its necessary. For example, suppose that the owner was given only the read right, while the group was given both read and write rights. Even if the owner is a member of that group, the owner only has exactly those rights given to it, i.e. read only. In contrast, if the group were "granted" the write right, then this would apply to all principals, whether or not there is a more specific ACE that identifies that principal. I find this confusing. It would seem that if the principal belongs to a group, and the group has a right that doesn't conflict with the principal's other right, then the principal has the right. Otherwise, Why bother with belonging to the group. The rights of a group are implicitly granted or denied when a principal becomes a member of the group. This is a privileged operation too which is not described in the ACL spec. Is it outside the scope? When a resource is created it is given a set of default ACL properties from a designated resource, referred to as an ACL source. The inheritance can be "static", so that subsequent changes to the ACL source do not affect the new resources ACL properties; or it can be "dynamic", so that subsequent changes are reflected in the new resource's ACL properties. 5.2 Use the same logic as for inheritance of deep locks and remove this section. Then ACLs can be effected by MOVE too. Locks and ACLs are related in that they both provide access control mechanisms. They should be treated the same as much as possible. Delete section 5.3, ACLs on individual properties, too. This would be something like wanting ACLs on parts of the contents of a resource. I think ACLs on the resource controlling access to its state - properties and contents - should be enough. More might be better, but is it necessary? It is legal for a property to carry a setting for what sort of inheritance its children will have. Currently this value has no meaning as properties can not have children, but it is expected in the future that hierarchical properties will be adopted, so this setting will then have meaning. For now compliant resources MUST record this value but do not have to do anything with it. I think this is really going too far. WebDAV should not know about the structure of any property just like it doesn't know about the structure of any resource other than its own meta-data. should be: right is redundant. Here's a stab at the open issues from the last telecon: Specificity:  how do multiple ACEs interact? This is pretty well described in the 00 spec. More specific takes precedence over general. Deny takes precedence over grant. Is there a specific issue missing? Does the distinction between users and groups need to be made in an ACE? No. A group is just an aggregate of principals for convenience purposes. It adds no additional semantic capability. ?checkPermissions? method:  ?do I have rights to do the following operation if I tried it? HTTP is a "try it and see what happens" or challenge response paradigm. This has worked well so far for access control. If the operation works, a client wouldn't want to waste the time checking ahead of time. If it fails due to access control, the client will know from the returned status code and can do whatever it would have done after a "checkPermissions" method. I don't see the need. Do we need an owner?  Can?t I just use a user principal? I don't know what a user principal is. It has to refer to a particular owner. In UNIX, user is a generic alias for the current owner of the resource. Its not a particular principal. Same with group. WebDAV ACLs are different in that they have lists of ACEs rather than just current owner, current group, and other as in UNIX. Some discussion of read/write permission on ACLs themselves.  General agreement to defer access control on ACLs to ?advanced?, with the owner-based model for CORE. The author should always have permission to change ACLs and can grant or deny this permission to other principals. The ability to change the owner must be restricted to the current owner only. A group should be a resource so it has an owner and can have access control on it too. Maybe a principal should be a resource and a group a kind of collection of principals. Do we need a way to discover how many ACEs a server can support in an ACL? Why would we ever consider specifying a limit? We don't expect servers to have some limit to the number of resources they can manage although we do expect that we could get an error anytime if the server runs out of space. Why not treat ACLs the same way? From w3c-dist-auth-request@w3.org Thu Mar 30 14:18:00 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20798 for ; Thu, 30 Mar 2000 14:18:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15434; Thu, 30 Mar 2000 14:14:56 -0500 (EST) Resent-Date: Thu, 30 Mar 2000 14:14:56 -0500 (EST) Resent-Message-Id: <200003301914.OAA15434@www19.w3.org> From: Jim Whitehead To: WebDAV WG Cc: Rohit Khare Date: Thu, 30 Mar 2000 11:13:55 -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: DAV tutorial at WWW9 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4227 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 There will be a half-day WebDAV/DASL/DeltaV tutorial given during the WWW9 conference in Amsterdam, the Netherlands, on Monday, May 15, starting at 9AM. Rohit Khare will be presenting -- he's a knowledgable, engaging speaker, and I expect he'll give an excellent tutorial. Conference details: http://www9.org/ Tutorial description: http://www9.org/w9-tutorials.html#TA8 - Jim From w3c-dist-auth-request@w3.org Thu Mar 30 18:30:00 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23316 for ; Thu, 30 Mar 2000 18:29:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA22673; Thu, 30 Mar 2000 18:26:05 -0500 (EST) Resent-Date: Thu, 30 Mar 2000 18:26:05 -0500 (EST) Resent-Message-Id: <200003302326.SAA22673@www19.w3.org> From: Jim Whitehead To: acl@webdav.org, WebDAV WG MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Thu, 30 Mar 2000 15:21:05 -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: Reminder: Access Control Teleconf. Mar. 31 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4228 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 Just a reminder that there will be a teleconference on the subject of access control for WebDAV, Friday, March 31, 2000. I did not receive any email from people saying they would be unable to make it due to attending the Adelaide IETF meeting. Access Control Teleconference Friday, March 31, 2000 11AM-12noon (Pacific) Phone number: 888-700-6725 Meeting ID: 932328225 Password: 2518 (these are the same as last week) Proposed Agenda: - scoping the effort (what's core, what's an extension, what's out) - continuing this discussion from last week - evaluate existing documents as a base for continuing work - are the goals still the same? - methods vs. properties for marshalling mechanism - Jim From w3c-dist-auth-request@w3.org Fri Mar 31 15:48:04 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18098 for ; Fri, 31 Mar 2000 15:48:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA18094; Fri, 31 Mar 2000 15:42:38 -0500 (EST) Resent-Date: Fri, 31 Mar 2000 15:42:38 -0500 (EST) Resent-Message-Id: <200003312042.PAA18094@www19.w3.org> To: jamsden@us.ibm.com cc: w3c-dist-auth@w3c.org, jjh@ira.uka.de In-reply-to: Your message of "Thu, 30 Mar 2000 02:32:15 CDT." <852568B2.0029DDDD.00@d54mta03.raleigh.ibm.com> Date: Fri, 31 Mar 2000 22:42:35 +0200 From: Juergen Reuter Message-ID: <"iraun1.ira.0044901:000331.204213"@ira.uka.de> Subject: Re: ACLs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4229 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list jamsden@us.ibm.com wrote: > ... > We should also take a look at emerging ACL models that are already > out there too. For example, the Java2 security model, IBM SecureWay, > Windows2000, etc. > ... ... and yet another one: IMAP4 ACL extension (RFC 2086). (Btw., it seems that the capabilities of WebDAV and IMAP are getting closer and closer...) Greetings, Juergen