From w3c-dist-auth-request@w3.org Wed Jan 2 12:40:49 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07737 for ; Wed, 2 Jan 2002 12:40:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA10125; Wed, 2 Jan 2002 12:38:40 -0500 (EST) Resent-Date: Wed, 2 Jan 2002 12:38:40 -0500 (EST) Resent-Message-Id: <200201021738.MAA10125@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA10102 for ; Wed, 2 Jan 2002 12:38:36 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA06223 for ; Wed, 2 Jan 2002 12:38:35 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA12950 for ; Wed, 2 Jan 2002 09:38:37 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 2 Jan 2002 09:37:42 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: implementation of WebDAV with Web Folders Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5734 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added to the accept2 list. - Jim -----Original Message----- From: Maulik Naik [mailto:mauliknaik@hotmail.com] Sent: Tuesday, January 01, 2002 11:10 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] implementation of WebDAV with Web Folders Hello All, I am developing Document Management System. For that, I want to give users client acces to web folders on Microsoft Platform. We are using ColdFusion for scriptiong and Windows development environment. Can anybody tell me, from where I can get good referances and guidelines. I surfed the WebDAV site, but i find it very confusing and hard to abstract data from it. I want to give acces to web folders on base of access controls of authorised users. Thanking You Maulik EKeMa From w3c-dist-auth-request@w3.org Fri Jan 4 16:17:50 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14065 for ; Fri, 4 Jan 2002 16:17:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA29558; Fri, 4 Jan 2002 16:12:04 -0500 (EST) Resent-Date: Fri, 4 Jan 2002 16:12:04 -0500 (EST) Resent-Message-Id: <200201042112.QAA29558@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA29538 for ; Fri, 4 Jan 2002 16:11:58 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA29603 for ; Fri, 4 Jan 2002 16:11:58 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id NAA27767 for ; Fri, 4 Jan 2002 13:12:02 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 4 Jan 2002 13:11:03 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5735 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Long message follows. Executive summary: Exchange 2000 introduces a set of "Batch" methods. I'm interested in the sense of the working group as to whether we should work to provide a complete specification and advance it to Proposed Standard. ----------- As many of you know, Microsoft's Exchange 2000 email server provides WebDAV access into its repository. Outlook Web Access uses WebDAV as its on-the-wire protocol for remotely accessing an Exchange store. The following white paper provides technical details on Outlook Web Access: http://www.microsoft.com/exchange/techinfo/outlook/2000/E2K_OWA.doc Outlook Web Access is among the most sophisticated uses of WebDAV to date, a significant engineering accomplishment. It is my understanding, based on discussions with some of the key developers of Outlook Web Access, that several WebDAV-related performance issues were encountered during development. In general, the problem was that it took too long to perform operations such as "delete 50 messages from my inbox" or "change the status of these 100 messages to 'read'". Since the typical hierarchical organization would make each folder a WebDAV collection, and each email a Web resource, these operations translated into "issue 50 separate DELETE commands" and "issue 100 separate PROPPATCH commands". Depth operations could not be used, since the operations were being performed on a subset of a collection. To address these performance issues, several "Batch" methods were developed as relatively simple extensions to existing WebDAV methods. Switching Outlook Web Access to use these methods resulted in approximately an order of magnitude performance increase (obviously, the performance benefit of going from N round-trips to 1 round trip depends on N). From the user perspective, the observed elapsed time for executing an operation went from multiple seconds down to close to a second (depending on latency, of course). It was a signficant performance improvement. The batch methods are: * BCOPY - batch COPY * BMOVE - batch MOVE * BDELETE - batch DELETE * BPROPFIND - batch PROPFIND * BPROPPATCH - batch PROPPATCH Documentation on these methods can be found on the MSDN site, at: http://msdn.microsoft.com/library/en-us/wss/wss/_webdav_methods.asp You'll also see some methods listed which pertain to receiving event notifications from the Exchange server. These are based on Josh Cohen's GENA proposal, which was submitted to the IETF as an Internet-Draft, but was never advanced to a Proposed Standard (in large part due to the absence of a working group in the IETF charged with developing an event notification standard). http://www.cs.colorado.edu/~grunwald/MobileComputing/Papers/draft-cohen-gena -p-base-00.txt As Co-Chair, I certainly do not approve of the fielding of new, unstandardized methods, since this leads to poor interoperability. I also do not approve of how these are labeled as "WebDAV Methods" on the MSDN site, since it lends these methods an aura of standardization that they do not, in fact, possess. But, as a pragmatist, I also recognize that in the time it took me to write these words, several new Exchange 2000 servers came online. The genie is out of the bottle. The fact remains that the batch methods work, and they scale. They provide a significant performance increase for an significant application of WebDAV. The specificationof these methods, as provided on the MSDN site, is pretty good (though they omit issues such as how to handle partial success/failure). It would not surprise me if, in time, other applications of WebDAV encountered the same performance problem, and desired a similar solution. As a result, I am interested in whether the working group has an interest in working to fully flesh-out the specification of the batch methods, and advance this specification to Proposed Standard. - Jim From w3c-dist-auth-request@w3.org Sun Jan 6 17:57:32 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27188 for ; Sun, 6 Jan 2002 17:57:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA22579; Sun, 6 Jan 2002 17:50:32 -0500 (EST) Resent-Date: Sun, 6 Jan 2002 17:50:32 -0500 (EST) Resent-Message-Id: <200201062250.RAA22579@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA22559 for ; Sun, 6 Jan 2002 17:50:29 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA30873 for ; Sun, 6 Jan 2002 17:50:29 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA197544; Sun, 6 Jan 2002 17:46:55 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g06Mno436450; Sun, 6 Jan 2002 17:49:50 -0500 To: Daniel Brotsky , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sun, 6 Jan 2002 17:31:48 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 01/06/2002 05:49:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5736 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'd like to mark the UNLOCK_BY_NON_LOCK_OWNERS issues item as resolved. As far as I can tell, we have consensus, although not unanimous. You can pick up the discussions at the following URLs and search forward and backwards from these. http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0157.html (the start of discussion) http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0214.html (the compromise proposal) http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0215.html (the only dissenting opinion) Has anyone changed their position? Any further comments? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Jan 7 05:20:25 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12611 for ; Mon, 7 Jan 2002 05:20:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA24545; Mon, 7 Jan 2002 05:19:12 -0500 (EST) Resent-Date: Mon, 7 Jan 2002 05:19:12 -0500 (EST) Resent-Message-Id: <200201071019.FAA24545@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA24525 for ; Mon, 7 Jan 2002 05:19:03 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA27039 for ; Mon, 7 Jan 2002 05:19:03 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g07AJj603783 for ; Mon, 7 Jan 2002 02:19:45 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g07AIj519548 for ; Mon, 7 Jan 2002 02:18:45 -0800 (PST) Received: from [192.168.1.3] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GPKCM900.PSW; Mon, 7 Jan 2002 02:18:09 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Mon, 7 Jan 2002 02:16:31 -0800 To: "Jason Crawford" From: Daniel Brotsky Cc: w3c-dist-auth@w3c.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5737 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 5:31 PM -0500 1/6/02, Jason Crawford wrote: >I'd like to mark the UNLOCK_BY_NON_LOCK_OWNERS issues item as resolved. As >far as I can tell, we have consensus, although not unanimous. Actually I think we may be closer to unanimous. You'll see in my "lone dissent" that I actually agree with the wording of the proposal, but that I wanted a special syntax so a user could avoid the problem of accidentally unlocking a resource while thinking he had it locked (but in fact someone else did, and he simply had permission to perform the unlock). Upon rereading Lisa's reply to my dissent, I am convinced that adding an entirely new syntax is probably more trouble than it's worth. Instead we should resolve the issue she raises about allowing discovery of who (in the sense of "the authenticated user id") owns a given lock. (And probably, while we're in there, we should have a way of discovering where any given lock is actually rooted, since I think that's come up before and is needed to do the unlock.) Jason, can you confirm that Lisa's issue is on the list and still active? If so I'd like to pend this one until that one is resolved, with a note that this one can then be marked resolved. Also please note that the there was an important, related issue re-raised at the first interop about using a Lock-Token: header instead of/in addition to an If: header in a number of cases, one of which was UNLOCK. (Without the lock-token header, you can't know which [non-exclusive] lock a client wants to release.) What's the status of that issue? dan > You can pick >up the discussions at the following URLs and search forward and backwards >from these. > >http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0157.html >(the start of discussion) >http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0214.html >(the compromise proposal) >http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0215.html >(the only dissenting opinion) -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Mon Jan 7 18:23:35 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00776 for ; Mon, 7 Jan 2002 18:23:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA08936; Mon, 7 Jan 2002 18:17:43 -0500 (EST) Resent-Date: Mon, 7 Jan 2002 18:17:43 -0500 (EST) Resent-Message-Id: <200201072317.SAA08936@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA08913 for ; Mon, 7 Jan 2002 18:17:32 -0500 (EST) Received: from btclick.com (mta03.btfusion.com [62.172.195.12]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA09331 for ; Mon, 7 Jan 2002 18:16:11 -0500 Received: from simonh ([217.37.3.161]) by btclick.com (Netscape Messaging Server 4.15) with SMTP id GPLCM400.PCA for ; Mon, 7 Jan 2002 23:15:40 +0000 Reply-To: From: "Simon Hill" To: Date: Mon, 7 Jan 2002 23:13:31 -0000 Message-ID: <000101c197d0$ed5ea880$a10325d9@simonh> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: Problems with Intercepting WebDAV with IIS to simulate filesystem with a DB Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5738 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi I'm trying to use WebDAV to implement DB CMS that presents a filesystem view to clients who connected to it, on IIS. I cannot find very much help on this so here's hoping for a lead... I use a header-rewriting ISAPI filter to forward HTTP requests, and I am using Dreamweaver 4's new WebDAV site management client to create the WebDAV traffic. At the moment I just want to analyse the HTTP headers so I can feel comfortable before I implement the database side, but I can't get this far because WebDAV seems to be trying to get the .asp script itself rather than running it and logging out the GETs and POSTs etc. My script is a simple one, it simply logs-out the server variables, at the moment. However on the client side I get 'can't access/file locked' error, and on the server the .asp file itself becomes locked. This makes me think that my header-rewriting is actually resulting in PUTs and GETs to that script itself rather than the execution of the script. Anyone got any clues? regards Simon From w3c-dist-auth-request@w3.org Mon Jan 7 21:35:04 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04244 for ; Mon, 7 Jan 2002 21:35:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA23842; Mon, 7 Jan 2002 21:30:39 -0500 (EST) Resent-Date: Mon, 7 Jan 2002 21:30:39 -0500 (EST) Resent-Message-Id: <200201080230.VAA23842@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA23821 for ; Mon, 7 Jan 2002 21:30:30 -0500 (EST) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA30401 for ; Mon, 7 Jan 2002 21:30:30 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA07522; Mon, 7 Jan 2002 18:33:16 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Mon, 7 Jan 2002 18:33:16 -0800 From: Greg Stein To: Jim Whitehead Cc: WebDAV Message-ID: <20020107183316.J6499@lyra.org> Mail-Followup-To: Jim Whitehead , WebDAV References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ejw@cse.ucsc.edu on Fri, Jan 04, 2002 at 01:11:03PM -0800 X-URL: http://www.lyra.org/greg/ Subject: Re: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5739 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Fri, Jan 04, 2002 at 01:11:03PM -0800, Jim Whitehead wrote: >... > To address these performance issues, several "Batch" methods were developed > as relatively simple extensions to existing WebDAV methods. Switching > Outlook Web Access to use these methods resulted in approximately an order > of magnitude performance increase (obviously, the performance benefit of > going from N round-trips to 1 round trip depends on N). From the user > perspective, the observed elapsed time for executing an operation went from > multiple seconds down to close to a second (depending on latency, of > course). It was a signficant performance improvement. The batch methods are: I wonder whether the performance suffered because the requests were performed in a request/response fashion, rather than as a series of pipelined requests. If you can pipeline requests, not waiting for an answer, then a series of DELETE operations is simply a "larger request" and then you handle a "larger response". Yes, each request/response has more overhead than a batched operation. Personally, I'm going to guess they didn't pipeline requests, so a batch mechanism was a must to get around deficiencies in their protocol stack. That said, it is important to recognize the overhead in a sequence of, say, DELETE requests and their responses, relative to a potential batch operation. Specifically, you're going to have a lot of duplicate headers on the requests and responses (there are no bodies in this case). How much does this pose over a batch delete with a list of URLs? Maybe 3x or 4x in the number of bytes? Maybe 10x? When you're talking over a modem (which is typically the case for MSFT's Hotmail servers), then that 10x can be rather significant. Ah, it's all a numbers game. Personally, I'm not interested in batch operations. I would guess that most of their benefit is obviating by pipelining requests. Cheers, -g ps. yes, this is mostly supposition; I'm not about to sit down and start measuring byte counts and network traffic; I don't know whether they were or were not pipelining; but my intuition tells me "no" and that pipelining is the answer... -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Jan 7 23:43:19 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06956 for ; Mon, 7 Jan 2002 23:43:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA28885; Mon, 7 Jan 2002 23:38:43 -0500 (EST) Resent-Date: Mon, 7 Jan 2002 23:38:43 -0500 (EST) Resent-Message-Id: <200201080438.XAA28885@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA28865 for ; Mon, 7 Jan 2002 23:38:39 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37068.rational.com [192.229.37.68]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA10221 for ; Mon, 7 Jan 2002 23:38:39 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Mon, 07 Jan 2002 22:57:47 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 22:57:47 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105577350@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Mon, 7 Jan 2002 22:57:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5740 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Like Greg, I'd like to see some evidence that this is not a problem that is more generally solved by pipelining requests. Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Monday, January 07, 2002 9:33 PM To: Jim Whitehead Cc: WebDAV Subject: Re: Interest in standardizing Batch methods? On Fri, Jan 04, 2002 at 01:11:03PM -0800, Jim Whitehead wrote: >... > To address these performance issues, several "Batch" methods were developed > as relatively simple extensions to existing WebDAV methods. Switching > Outlook Web Access to use these methods resulted in approximately an order > of magnitude performance increase (obviously, the performance benefit of > going from N round-trips to 1 round trip depends on N). From the user > perspective, the observed elapsed time for executing an operation went from > multiple seconds down to close to a second (depending on latency, of > course). It was a signficant performance improvement. The batch methods are: I wonder whether the performance suffered because the requests were performed in a request/response fashion, rather than as a series of pipelined requests. If you can pipeline requests, not waiting for an answer, then a series of DELETE operations is simply a "larger request" and then you handle a "larger response". Yes, each request/response has more overhead than a batched operation. Personally, I'm going to guess they didn't pipeline requests, so a batch mechanism was a must to get around deficiencies in their protocol stack. That said, it is important to recognize the overhead in a sequence of, say, DELETE requests and their responses, relative to a potential batch operation. Specifically, you're going to have a lot of duplicate headers on the requests and responses (there are no bodies in this case). How much does this pose over a batch delete with a list of URLs? Maybe 3x or 4x in the number of bytes? Maybe 10x? When you're talking over a modem (which is typically the case for MSFT's Hotmail servers), then that 10x can be rather significant. Ah, it's all a numbers game. Personally, I'm not interested in batch operations. I would guess that most of their benefit is obviating by pipelining requests. Cheers, -g ps. yes, this is mostly supposition; I'm not about to sit down and start measuring byte counts and network traffic; I don't know whether they were or were not pipelining; but my intuition tells me "no" and that pipelining is the answer... -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Jan 8 05:56:03 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18901 for ; Tue, 8 Jan 2002 05:56:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA00464; Tue, 8 Jan 2002 05:54:10 -0500 (EST) Resent-Date: Tue, 8 Jan 2002 05:54:10 -0500 (EST) Resent-Message-Id: <200201081054.FAA00464@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA00437 for ; Tue, 8 Jan 2002 05:54:03 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA19260 for ; Tue, 8 Jan 2002 05:54:03 -0500 Received: (qmail 15599 invoked by uid 0); 8 Jan 2002 10:53:31 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp016-rz3) with SMTP; 8 Jan 2002 10:53:31 -0000 From: "Julian Reschke" To: "Greg Stein" Cc: "WebDAV" Date: Tue, 8 Jan 2002 11:53:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <20020107183316.J6499@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5741 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greg, if I understand you correctly you say that issuing all requests at the same time (without waiting for the responses) will help to reduce the communications overhead. Yet, the *server* will still see separate requests, and at this point it would be hard to actually detect that all these requests have something in common and may be internally optimized (for instance by doing just one instead of many calls to the database). I think that if there are common operations that involve multiple resources at once, it makes sense to define the protocol such that the server can optimize the execution... Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Tuesday, January 08, 2002 3:33 AM > To: Jim Whitehead > Cc: WebDAV > Subject: Re: Interest in standardizing Batch methods? > > > On Fri, Jan 04, 2002 at 01:11:03PM -0800, Jim Whitehead wrote: > >... > > To address these performance issues, several "Batch" methods > were developed > > as relatively simple extensions to existing WebDAV methods. Switching > > Outlook Web Access to use these methods resulted in > approximately an order > > of magnitude performance increase (obviously, the performance benefit of > > going from N round-trips to 1 round trip depends on N). From the user > > perspective, the observed elapsed time for executing an > operation went from > > multiple seconds down to close to a second (depending on latency, of > > course). It was a signficant performance improvement. The batch > methods are: > > I wonder whether the performance suffered because the requests were > performed in a request/response fashion, rather than as a series of > pipelined requests. If you can pipeline requests, not waiting for > an answer, > then a series of DELETE operations is simply a "larger request" > and then you > handle a "larger response". Yes, each request/response has more overhead > than a batched operation. > > Personally, I'm going to guess they didn't pipeline requests, so a batch > mechanism was a must to get around deficiencies in their protocol stack. > > > That said, it is important to recognize the overhead in a > sequence of, say, > DELETE requests and their responses, relative to a potential batch > operation. Specifically, you're going to have a lot of duplicate > headers on > the requests and responses (there are no bodies in this case). > How much does > this pose over a batch delete with a list of URLs? Maybe 3x or 4x in the > number of bytes? Maybe 10x? When you're talking over a modem (which is > typically the case for MSFT's Hotmail servers), then that 10x can > be rather > significant. > > Ah, it's all a numbers game. Personally, I'm not interested in batch > operations. I would guess that most of their benefit is obviating by > pipelining requests. > > Cheers, > -g > > ps. yes, this is mostly supposition; I'm not about to sit down and start > measuring byte counts and network traffic; I don't know whether > they were or > were not pipelining; but my intuition tells me "no" and that pipelining is > the answer... > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Tue Jan 8 09:58:19 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24294 for ; Tue, 8 Jan 2002 09:58:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA29778; Tue, 8 Jan 2002 09:56:55 -0500 (EST) Resent-Date: Tue, 8 Jan 2002 09:56:55 -0500 (EST) Resent-Message-Id: <200201081456.JAA29778@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA29736 for ; Tue, 8 Jan 2002 09:56:47 -0500 (EST) Received: from smtp-server6.tampabay.rr.com (smtp-server6.tampabay.rr.com [65.32.1.43]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA26076 for ; Tue, 8 Jan 2002 09:56:47 -0500 Received: from redfish (6532112hfc151.tampabay.rr.com [65.32.112.151]) by smtp-server6.tampabay.rr.com (8.11.2/8.11.2) with SMTP id g08Euk222157 for ; Tue, 8 Jan 2002 09:56:46 -0500 (EST) From: "Steve Lomicka" To: Date: Tue, 8 Jan 2002 09:56:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C1982A.C81C49B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Re: Problems with Intercepting WebDAV with IIS to simulate filesystem with a DB Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5742 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C1982A.C81C49B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit At a basic level, I have done something similar to what you are trying to accomplish. If I understand you correctly, you are trying to interrogate HTTP requests as they come into an IIS server using a IIS ISAPI filter. I wrote a simple ISAPI filter and implemented SF_NOTIFY_READ_RAW_DATA and SF_NOTIFY_SEND_RAW_DATA. I took the raw data, cast it as a string and used ::OutputDebugView to watch the requests. Since the filter uses SF_NOTIFY_READ_RAW_DATA and SF_NOTIFY_SEND_RAW_DATA it must be registered as a global ISAPI filter. Additionally you must give the directory where the DLL resides READ & EXECUTE writes through explorer. Ensure you give these rights to the IWAM_XXX and I_URS_XXX user or it will not work. If you want to debug, you also have to make the filter low protection, which brings it in process. Hope this helps. Steve Lomicka CTO Maximal Systems, Inc. 727-539-7500 ex760 www.maximal.com ------=_NextPart_000_0004_01C1982A.C81C49B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At a basic=20 level, I have done something similar to what you are trying to = accomplish. =20 If I understand you correctly, you are trying to interrogate HTTP = requests as=20 they come into an IIS server using a IIS ISAPI filter.  I wrote a = simple=20 ISAPI filter and implemented SF_NOTIFY_READ_RAW_DATA and=20 SF_NOTIFY_SEND_RAW_DATA.  I took the raw data, cast it as a string = and used=20 ::OutputDebugView to watch the requests.  Since the filter uses=20 SF_NOTIFY_READ_RAW_DATA and SF_NOTIFY_SEND_RAW_DATA it must be = registered as a=20 global ISAPI filter.  Additionally you must give the directory = where the=20 DLL resides READ & EXECUTE writes through explorer.  Ensure you = give=20 these rights to the IWAM_XXX and I_URS_XXX user or it will not = work.  If=20 you want to debug, you also have to make the filter low protection, = which brings=20 it in process. Hope this helps.
 
Steve=20 Lomicka
CTO
Maximal Systems, Inc.
727-539-7500 ex760
www.maximal.com
 
------=_NextPart_000_0004_01C1982A.C81C49B0-- From w3c-dist-auth-request@w3.org Tue Jan 8 18:14:31 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13441 for ; Tue, 8 Jan 2002 18:14:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA26835; Tue, 8 Jan 2002 18:12:04 -0500 (EST) Resent-Date: Tue, 8 Jan 2002 18:12:04 -0500 (EST) Resent-Message-Id: <200201082312.SAA26835@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA26803 for ; Tue, 8 Jan 2002 18:11:59 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA16697 for ; Tue, 8 Jan 2002 18:11:59 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA373602; Tue, 8 Jan 2002 18:08:24 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g08NBLH90170; Tue, 8 Jan 2002 18:11:21 -0500 To: Daniel Brotsky Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 8 Jan 2002 17:53:49 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 01/08/2002 06:11:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5743 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: All, Dan and Lisa have suggested that we need to more clearly define either the use of the lockowner field or that we need a way to identify the owner of the lock. http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html says... > > (Especially because the spec provides > > no way to reliably determine who owns a lock.) > This is a good point -- and this is already a failing of WebDAV, with or > without UNLOCK_BY_NON_LOCK_OWNER. Clients that crash or miss the response > from the server need to make sure that the lock is theirs before grabbing > the lock token using PROPFIND. Can lockowner be used for this purpose? > This should be a separate RFC2518 issue. How about > "HOW_TO_IDENTIFY_LOCK_OWNER". Just as a point of information, I'd like to point out we have an issue on the issues list that is somewhat related: DEFINE_PRINCIPAL. In that issue Mark D Anderson says: The term "principal" is never defined in the WebDAV specification, or the HTTP or Digest specifications. It should be defined. Lisa and Dan, Could you define the requirement before we start the discussion? For example, is it for the server or the client that we need to make the clarification below? (I'll reference your clarfication from the issues list.) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Jan 9 00:40:07 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20965 for ; Wed, 9 Jan 2002 00:40:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA19232; Wed, 9 Jan 2002 00:31:58 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 00:31:58 -0500 (EST) Resent-Message-Id: <200201090531.AAA19232@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA19207 for ; Wed, 9 Jan 2002 00:31:49 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA27664 for ; Wed, 9 Jan 2002 00:31:48 -0500 Received: from moose ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id g095VdN05483; Tue, 8 Jan 2002 21:31:39 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Greg Stein" , "Jim Whitehead" Cc: "WebDAV" Date: Tue, 8 Jan 2002 21:29:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20020107183316.J6499@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5744 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Personally, I'm going to guess they didn't pipeline requests, so a batch > mechanism was a must to get around deficiencies in their protocol stack. There's potentially a little more to it than that. (1) Imagine a client selects a bunch of resources and drags to move them all to a different folder. A batch MOVE operation can do those in one transaction, so that the whole request fails if not all can be moved. This becomes rather more important if the client is actually using an API (MSDAIPP??) that offers large-scope operations, yet how can it guarantee that operation will work or won't work if it can only send it piecemeal to the server? (2) See Yaron's email (http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html) about why pipelining doesn't always work (can't always be used even when available). I don't know to what extent pipelining is realistically unavailable/unworkable. That said, it's still not clear batch methods are so necessary they'd preempt other work we've got to do. Lisa From w3c-dist-auth-request@w3.org Wed Jan 9 00:48:24 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21115 for ; Wed, 9 Jan 2002 00:48:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA19865; Wed, 9 Jan 2002 00:40:59 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 00:40:59 -0500 (EST) Resent-Message-Id: <200201090540.AAA19865@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA19838 for ; Wed, 9 Jan 2002 00:40:54 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA29029 for ; Wed, 9 Jan 2002 00:40:54 -0500 Received: from moose ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id g095enN06266; Tue, 8 Jan 2002 21:40:49 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Julian Reschke" , "Greg Stein" Cc: "WebDAV" Date: Tue, 8 Jan 2002 21:39:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5745 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Yet, the *server* will still see separate requests, and at this point it > would be hard to actually detect that all these requests have something in > common and may be internally optimized (for instance by doing just one > instead of many calls to the database). The HTTP 1.1 spec (RFC2616) isn't very clear on how servers are supposed to handle pipelined requests, other than it must return the responses in the same order as the requests. However, it would seem very dangerous to try to detect whether a bunch of pipelined requests can be optimized. Might that not have a different end-result than if they were handled one-by-one? Could the first PROPPATCH in a pipeline trigger an event which causes a later PROPPATCH in the same pipeline to behave differently, were it to be handled independently? This is not just my worry -- it's also in Krishnamurthy and Rexford (Web Protocols and Practice). WP&P also points out that - pipelined requests suffer from head-of-line blocking, while multiple requests over separate cxns does not - a closed connection is more severe when pipelining is used because the client must remember a lot more state to recover from the closed connection Lisa From w3c-dist-auth-request@w3.org Wed Jan 9 01:20:29 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21517 for ; Wed, 9 Jan 2002 01:20:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA22408; Wed, 9 Jan 2002 01:18:56 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 01:18:56 -0500 (EST) Resent-Message-Id: <200201090618.BAA22408@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA22388 for ; Wed, 9 Jan 2002 01:18:51 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA01980 for ; Wed, 9 Jan 2002 01:18:51 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g096H6Y19431 for ; Tue, 8 Jan 2002 22:17:06 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g096IZ518234 for ; Tue, 8 Jan 2002 22:18:35 -0800 (PST) Received: from [153.32.158.166] ([130.248.188.68]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GPNQUF00.9Z5; Tue, 8 Jan 2002 22:18:15 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 8 Jan 2002 22:18:23 -0800 To: "Jason Crawford" From: Daniel Brotsky Cc: w3c-dist-auth@w3c.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5746 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I think there are a variety of client needs here. These are probably a little too fuzzy to be called requirements :^), but it's the best I can do right now. 1. This came up at the first interop, and most servers seemed to be compliant by the second interop: The part of a lock is to be completely controlled by the client. The server MUST not alter it (i.e., lock discovery, if it returns the information, must return exactly equivalent XML to that in the LOCK request). There's a lot of discussion of why this is needed in the archives; the gist is that it's the only client-controlled XML that's always associated with a LOCK, so clients of a given ilk can use it to exchange conventional information with each other about the lock. 2. There's some well-known specification of "principal" in the sense of "authenticated user ID whose authorization is being used for the current request." Probably this is a string of some kind, and probably there are localization issues so we will want this string to be in a known encoding (e.g., UTF-8) or else all mechanisms that return this string must be able to return the encoding. 3. Clients need to know/be able to discover which "principal" they are. I don't really know enough about the range of authentication schemes to understand whether clients can always know for sure what "principal" the server is associating with them based on the client-generated authentication header, or whether the client might simply have been given some set of opaque credentials and need the server to tell it which "principal" those credentials make it. 4. Clients need to know/be able to discover which "principal" owns a given lock, that is, which principal made the original lock request. 5. Clients need to know/be able to discover where the "root resource" of a lock is; that is, the resource on which the lock owner can do an UNLOCK of the right depth and get the lock released. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Jan 9 03:35:55 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01175 for ; Wed, 9 Jan 2002 03:35:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA04489; Wed, 9 Jan 2002 03:34:38 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 03:34:38 -0500 (EST) Resent-Message-Id: <200201090834.DAA04489@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA04469 for ; Wed, 9 Jan 2002 03:34:28 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA15542 for ; Wed, 9 Jan 2002 03:34:28 -0500 Received: (qmail 2330 invoked by uid 0); 9 Jan 2002 08:33:57 -0000 Received: from pd9535930.dip.t-dialin.net (HELO lisa) (217.83.89.48) by mail.gmx.net (mp013-rz3) with SMTP; 9 Jan 2002 08:33:57 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Greg Stein" , "Jim Whitehead" Cc: "WebDAV" Date: Wed, 9 Jan 2002 09:33:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5747 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Looking at RFC2616: "8.1.2.2 Pipelining A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request." So it seems that pipelining wouldn't be allowed for anything except PROPFIND (MOVE/DELETE/PROPPATCH aren't idempotent), right? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, January 09, 2002 6:30 AM > To: Greg Stein; Jim Whitehead > Cc: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > > > Personally, I'm going to guess they didn't pipeline requests, so a batch > > mechanism was a must to get around deficiencies in their protocol stack. > > There's potentially a little more to it than that. > (1) Imagine a client selects a bunch of resources and drags to > move them all > to a different folder. A batch MOVE operation can do those in one > transaction, so that the whole request fails if not all can be > moved. This > becomes rather more important if the client is actually using an API > (MSDAIPP??) that offers large-scope operations, yet how can it guarantee > that operation will work or won't work if it can only send it piecemeal to > the server? > > (2) See Yaron's email > (http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html) > about why pipelining doesn't always work (can't always be used even when > available). I don't know to what extent pipelining is realistically > unavailable/unworkable. > > That said, it's still not clear batch methods are so necessary they'd > preempt other work we've got to do. > > Lisa > From w3c-dist-auth-request@w3.org Wed Jan 9 10:41:18 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05694 for ; Wed, 9 Jan 2002 10:41:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA01687; Wed, 9 Jan 2002 10:39:30 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 10:39:30 -0500 (EST) Resent-Message-Id: <200201091539.KAA01687@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA01649 for ; Wed, 9 Jan 2002 10:39:24 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37068.rational.com [192.229.37.68]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA07631 for ; Wed, 9 Jan 2002 10:39:22 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Wed, 09 Jan 2002 10:21:52 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 10:17:22 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105577699@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Wed, 9 Jan 2002 10:17:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5748 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: A single MOVE, DELETE, or PROPPATCH request is idempotent (repeating the same request multiple times produces the same result as just doing it once). A sequence of DELETE's is always idempotent. A sequence of PROPPATCH's is always idempotent if the same property isn't updated by different PROPPATCH requests in that sequence. A sequence of MOVE's is always idempotent if none of the Destination URLs overlap with any of the request URL's. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, January 09, 2002 3:34 AM To: Lisa Dusseault; Greg Stein; Jim Whitehead Cc: WebDAV Subject: RE: Interest in standardizing Batch methods? Looking at RFC2616: "8.1.2.2 Pipelining Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). So it seems that pipelining wouldn't be allowed for anything except PROPFIND (MOVE/DELETE/PROPPATCH aren't idempotent), right? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, January 09, 2002 6:30 AM > To: Greg Stein; Jim Whitehead > Cc: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > > > Personally, I'm going to guess they didn't pipeline requests, so a batch > > mechanism was a must to get around deficiencies in their protocol stack. > > There's potentially a little more to it than that. > (1) Imagine a client selects a bunch of resources and drags to > move them all > to a different folder. A batch MOVE operation can do those in one > transaction, so that the whole request fails if not all can be > moved. This > becomes rather more important if the client is actually using an API > (MSDAIPP??) that offers large-scope operations, yet how can it guarantee > that operation will work or won't work if it can only send it piecemeal to > the server? > > (2) See Yaron's email > (http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html) > about why pipelining doesn't always work (can't always be used even when > available). I don't know to what extent pipelining is realistically > unavailable/unworkable. > > That said, it's still not clear batch methods are so necessary they'd > preempt other work we've got to do. > > Lisa > From w3c-dist-auth-request@w3.org Wed Jan 9 10:49:23 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05816 for ; Wed, 9 Jan 2002 10:49:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA02574; Wed, 9 Jan 2002 10:47:45 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 10:47:45 -0500 (EST) Resent-Message-Id: <200201091547.KAA02574@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA02554 for ; Wed, 9 Jan 2002 10:47:41 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA09462 for ; Wed, 9 Jan 2002 10:47:40 -0500 Received: from apu [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 09 Jan 2002 16:46:55 +0100 From: "Stefan Eissing" To: "Clemm, Geoff" , "WebDAV" Date: Wed, 9 Jan 2002 16:46:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B105577699@SUS-MA1IT01> X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5749 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, January 09, 2002 4:17 PM > To: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > A single MOVE, DELETE, or PROPPATCH request is idempotent > (repeating the same request multiple times produces the > same result as just doing it once). Not quite: A second MOVE/DELETE/PROPPATCH will return a different result to the client. So a second DELETE will answer 404 instead of 204. The server "state" will stay the same. I think that's what you had in mind. > A sequence of DELETE's is always idempotent. A sequence of PROPPATCH's > is always idempotent if the same property isn't updated by different > PROPPATCH requests in that sequence. A sequence of MOVE's is always > idempotent if none of the Destination URLs overlap with any of the > request URL's. > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, January 09, 2002 3:34 AM > To: Lisa Dusseault; Greg Stein; Jim Whitehead > Cc: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > Looking at RFC2616: > > "8.1.2.2 Pipelining > Clients SHOULD NOT pipeline requests using non-idempotent methods or > non-idempotent sequences of methods > (see section 9.1.2). > > So it seems that pipelining wouldn't be allowed for anything > except PROPFIND > (MOVE/DELETE/PROPPATCH aren't idempotent), right? > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, January 09, 2002 6:30 AM > > To: Greg Stein; Jim Whitehead > > Cc: WebDAV > > Subject: RE: Interest in standardizing Batch methods? > > > > > > > > > Personally, I'm going to guess they didn't pipeline requests, > so a batch > > > mechanism was a must to get around deficiencies in their > protocol stack. > > > > There's potentially a little more to it than that. > > (1) Imagine a client selects a bunch of resources and drags to > > move them all > > to a different folder. A batch MOVE operation can do those in one > > transaction, so that the whole request fails if not all can be > > moved. This > > becomes rather more important if the client is actually using an API > > (MSDAIPP??) that offers large-scope operations, yet how can it guarantee > > that operation will work or won't work if it can only send it > piecemeal to > > the server? > > > > (2) See Yaron's email > > (http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html) > > about why pipelining doesn't always work (can't always be used even when > > available). I don't know to what extent pipelining is realistically > > unavailable/unworkable. > > > > That said, it's still not clear batch methods are so necessary they'd > > preempt other work we've got to do. > > > > Lisa > > > > > From w3c-dist-auth-request@w3.org Wed Jan 9 11:13:23 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06399 for ; Wed, 9 Jan 2002 11:13:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA04276; Wed, 9 Jan 2002 11:12:25 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 11:12:25 -0500 (EST) Resent-Message-Id: <200201091612.LAA04276@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA04254 for ; Wed, 9 Jan 2002 11:12:17 -0500 (EST) Received: from server8.software-ag.de (server8.software-ag.de [193.26.193.23]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA14397 for ; Wed, 9 Jan 2002 11:12:17 -0500 Received: from daehub01.software-ag.de by server8.software-ag.de; (8.9.3/8.9.3) id RAA25585; Wed, 9 Jan 2002 17:12:03 +0100 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Jan 2002 17:12:15 +0100 Message-ID: From: "Pill, Juergen" To: WebDAV Date: Wed, 9 Jan 2002 17:12:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5750 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hello, We would like to have a BATCH method too, beside possible performance improvements, we would benefit from transaction handling. The BATCH method could specify that all requests should be executed within a transaction. I want to suggest instead of introducing a series of Bxxx methods, to introduce only a single method named BATCH, which caries a series of WebDAV methods within his XML body. This would allow to execute a scenario within a transaction (e.g. lock, put, proppatch, unlock). Multiple delete methods would be covered by this approach too. The BATCH XML body would be able to specify headers on a general level (identical to all contained methods) and specific headers for a single method only. This BATCH method would open the door into a BATCH language, e.g. execute request #2 only if request #1 results in a 200/OK response code. Best regards, Juergen Pill P.S. from the client programming perspective I would prefer the batch possibility to the pipelining feature due to programming effort. -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, January 09, 2002 16.17 PM To: WebDAV Subject: RE: Interest in standardizing Batch methods? A single MOVE, DELETE, or PROPPATCH request is idempotent (repeating the same request multiple times produces the same result as just doing it once). A sequence of DELETE's is always idempotent. A sequence of PROPPATCH's is always idempotent if the same property isn't updated by different PROPPATCH requests in that sequence. A sequence of MOVE's is always idempotent if none of the Destination URLs overlap with any of the request URL's. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, January 09, 2002 3:34 AM To: Lisa Dusseault; Greg Stein; Jim Whitehead Cc: WebDAV Subject: RE: Interest in standardizing Batch methods? Looking at RFC2616: "8.1.2.2 Pipelining Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). So it seems that pipelining wouldn't be allowed for anything except PROPFIND (MOVE/DELETE/PROPPATCH aren't idempotent), right? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, January 09, 2002 6:30 AM > To: Greg Stein; Jim Whitehead > Cc: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > > > Personally, I'm going to guess they didn't pipeline requests, so a batch > > mechanism was a must to get around deficiencies in their protocol stack. > > There's potentially a little more to it than that. > (1) Imagine a client selects a bunch of resources and drags to > move them all > to a different folder. A batch MOVE operation can do those in one > transaction, so that the whole request fails if not all can be > moved. This > becomes rather more important if the client is actually using an API > (MSDAIPP??) that offers large-scope operations, yet how can it guarantee > that operation will work or won't work if it can only send it piecemeal to > the server? > > (2) See Yaron's email > (http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html) > about why pipelining doesn't always work (can't always be used even when > available). I don't know to what extent pipelining is realistically > unavailable/unworkable. > > That said, it's still not clear batch methods are so necessary they'd > preempt other work we've got to do. > > Lisa > From w3c-dist-auth-request@w3.org Wed Jan 9 12:00:51 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07291 for ; Wed, 9 Jan 2002 12:00:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA08111; Wed, 9 Jan 2002 11:59:54 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 11:59:54 -0500 (EST) Resent-Message-Id: <200201091659.LAA08111@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA08085 for ; Wed, 9 Jan 2002 11:59:45 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA23647 for ; Wed, 9 Jan 2002 11:59:45 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id MAA24720; Wed, 9 Jan 2002 12:59:14 -0500 Reply-To: From: "Matt Timmermans" To: "'Pill, Juergen'" , "'WebDAV'" Date: Wed, 9 Jan 2002 11:58:46 -0500 Message-ID: <001a01c1992e$e7b1f770$d482a8c0@mt2k> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5751 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen > [...] > I want to suggest instead of introducing a series of Bxxx methods, to > introduce only a single method named BATCH, which caries a > series of WebDAV > methods within his XML body. This would allow to execute a > scenario within a > transaction (e.g. lock, put, proppatch, unlock). Multiple > delete methods > would be covered by this approach too. > [...] > This BATCH method would open the door into a BATCH language, > e.g. execute > request #2 only if request #1 results in a 200/OK response code. This is very powerful if you do it properly. The lack of any transaction control in WebDAV currently makes it impossible to perform many operations safely. If a document has a property that lists its contributing authors, for example, you can't add a name to that list unless you know that noone else will be doing the same thing concurrently. Obviously, you can't allow clients to separately start and stop transactions, so you have to get them to send the whole transaction in a batch. The batch must express the semantics of the transaction, so it's tempting to include a Turing complete batch language. That is evil, though, because then a batch may consume unbounded resources. I've looked into this somewhat, however, and determined the minimum functionality required by the batch language to allow any arbitrary operation to be performed by the client safely. The minimal requirements are: 1) any request that can be performed outside of a batch can be sent inside a batch; and 2) the batch can be aborted if any queried persistent state does not match some given, expected value. 3) the client is informed when a batch is aborted because of condition (2). To perform a safe update to the contributors list, for example, a client can do this: 1) PROPFIND to get the list of contributors (oldlist) 2) BATCH: PROPFIND to get the list of contributors (oldlist') ABORT if oldlist' != oldlist PROPPATCH contributors = oldlist+newname 3) If batch aborted due to the condition, go back to step 1. From w3c-dist-auth-request@w3.org Wed Jan 9 12:20:02 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07514 for ; Wed, 9 Jan 2002 12:20:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA10600; Wed, 9 Jan 2002 12:19:06 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 12:19:06 -0500 (EST) Resent-Message-Id: <200201091719.MAA10600@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA10574 for ; Wed, 9 Jan 2002 12:19:01 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37068.rational.com [192.229.37.68]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA27695 for ; Wed, 9 Jan 2002 12:19:02 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Wed, 09 Jan 2002 12:17:10 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 12:17:02 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AE6A@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Stefan Eissing'" , "Clemm, Geoff" , WebDAV Date: Wed, 9 Jan 2002 12:16:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5752 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Idempotent" doesn't mean "returns the same response", it means "produces equivalent state on the server". RFC 2516 makes this clear by explicitly identifying PUT and DELETE as idempotent operations. Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Sent: Wednesday, January 09, 2002 10:47 AM To: Clemm, Geoff; WebDAV Subject: RE: Interest in standardizing Batch methods? > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, January 09, 2002 4:17 PM > To: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > A single MOVE, DELETE, or PROPPATCH request is idempotent > (repeating the same request multiple times produces the > same result as just doing it once). Not quite: A second MOVE/DELETE/PROPPATCH will return a different result to the client. So a second DELETE will answer 404 instead of 204. The server "state" will stay the same. I think that's what you had in mind. > A sequence of DELETE's is always idempotent. A sequence of PROPPATCH's > is always idempotent if the same property isn't updated by different > PROPPATCH requests in that sequence. A sequence of MOVE's is always > idempotent if none of the Destination URLs overlap with any of the > request URL's. > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, January 09, 2002 3:34 AM > To: Lisa Dusseault; Greg Stein; Jim Whitehead > Cc: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > Looking at RFC2616: > > "8.1.2.2 Pipelining > Clients SHOULD NOT pipeline requests using non-idempotent methods or > non-idempotent sequences of methods > (see section 9.1.2). > > So it seems that pipelining wouldn't be allowed for anything > except PROPFIND > (MOVE/DELETE/PROPPATCH aren't idempotent), right? > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, January 09, 2002 6:30 AM > > To: Greg Stein; Jim Whitehead > > Cc: WebDAV > > Subject: RE: Interest in standardizing Batch methods? > > > > > > > > > Personally, I'm going to guess they didn't pipeline requests, > so a batch > > > mechanism was a must to get around deficiencies in their > protocol stack. > > > > There's potentially a little more to it than that. > > (1) Imagine a client selects a bunch of resources and drags to > > move them all > > to a different folder. A batch MOVE operation can do those in one > > transaction, so that the whole request fails if not all can be > > moved. This > > becomes rather more important if the client is actually using an API > > (MSDAIPP??) that offers large-scope operations, yet how can it guarantee > > that operation will work or won't work if it can only send it > piecemeal to > > the server? > > > > (2) See Yaron's email > > (http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html) > > about why pipelining doesn't always work (can't always be used even when > > available). I don't know to what extent pipelining is realistically > > unavailable/unworkable. > > > > That said, it's still not clear batch methods are so necessary they'd > > preempt other work we've got to do. > > > > Lisa > > > > > From w3c-dist-auth-request@w3.org Wed Jan 9 12:35:59 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07909 for ; Wed, 9 Jan 2002 12:35:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA12568; Wed, 9 Jan 2002 12:35:04 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 12:35:04 -0500 (EST) Resent-Message-Id: <200201091735.MAA12568@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA12483 for ; Wed, 9 Jan 2002 12:34:56 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA30431 for ; Wed, 9 Jan 2002 12:34:55 -0500 Received: (qmail 14643 invoked by uid 0); 9 Jan 2002 17:34:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 9 Jan 2002 17:34:24 -0000 From: "Julian Reschke" To: , "'Pill, Juergen'" , "'WebDAV'" Date: Wed, 9 Jan 2002 18:34:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001a01c1992e$e7b1f770$d482a8c0@mt2k> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5753 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Matt, I think this is definitively going to be too ambitious. We really should start collecting the requirements first (as Jim did). If the problem you're trying to solve is an update of a structured (multivalued) property, you could do this by LOCKing the resource now. A lightweight protocol that doesn't need LOCKs could be defines like: - define a "PTag" (comparable to the ETag) that changes when properties change, - extend the request body to PROPPATCH to optionally include the PTag you have and only do the PROPPATCH if the PTag is still valid) - alternatively, extend DAV:set to marshall a reference value to which the current value is compared before updating the property. For instance: oldvalue newvalue Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Matt Timmermans > Sent: Wednesday, January 09, 2002 5:59 PM > To: 'Pill, Juergen'; 'WebDAV' > Subject: RE: Interest in standardizing Batch methods? > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen > > [...] > > I want to suggest instead of introducing a series of Bxxx methods, to > > introduce only a single method named BATCH, which caries a > > series of WebDAV > > methods within his XML body. This would allow to execute a > > scenario within a > > transaction (e.g. lock, put, proppatch, unlock). Multiple > > delete methods > > would be covered by this approach too. > > [...] > > This BATCH method would open the door into a BATCH language, > > e.g. execute > > request #2 only if request #1 results in a 200/OK response code. > > This is very powerful if you do it properly. The lack of any transaction > control in WebDAV currently makes it impossible to perform many operations > safely. If a document has a property that lists its contributing authors, > for example, you can't add a name to that list unless you know that noone > else will be doing the same thing concurrently. > > Obviously, you can't allow clients to separately start and stop > transactions, so you have to get them to send the whole transaction in a > batch. The batch must express the semantics of the transaction, so it's > tempting to include a Turing complete batch language. That is > evil, though, > because then a batch may consume unbounded resources. > > I've looked into this somewhat, however, and determined the minimum > functionality required by the batch language to allow any arbitrary > operation to be performed by the client safely. The minimal requirements > are: > > 1) any request that can be performed outside of a batch can be > sent inside a > batch; and > > 2) the batch can be aborted if any queried persistent state does not match > some given, expected value. > > 3) the client is informed when a batch is aborted because of > condition (2). > > To perform a safe update to the contributors list, for example, a > client can > do this: > > 1) PROPFIND to get the list of contributors (oldlist) > > 2) BATCH: > PROPFIND to get the list of contributors (oldlist') > ABORT if oldlist' != oldlist > PROPPATCH contributors = oldlist+newname > > 3) If batch aborted due to the condition, go back to step 1. > > From w3c-dist-auth-request@w3.org Wed Jan 9 12:59:44 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08394 for ; Wed, 9 Jan 2002 12:59:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA17422; Wed, 9 Jan 2002 12:58:14 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 12:58:14 -0500 (EST) Resent-Message-Id: <200201091758.MAA17422@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA17283 for ; Wed, 9 Jan 2002 12:57:55 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA02248 for ; Wed, 9 Jan 2002 12:57:55 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g09HuAY16609 for ; Wed, 9 Jan 2002 09:56:11 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g09Hvc509516 for ; Wed, 9 Jan 2002 09:57:38 -0800 (PST) Received: from [153.32.158.166] ([153.32.158.166]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GPON7I00.N8F; Wed, 9 Jan 2002 09:57:18 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 9 Jan 2002 08:15:30 -0800 To: "Lisa Dusseault" From: Daniel Brotsky Cc: "Greg Stein" , "Jim Whitehead" , "WebDAV" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5754 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 9:29 PM -0800 1/8/02, Lisa Dusseault wrote: >... A batch MOVE operation can do those in one >transaction, so that the whole request fails if not all can be moved. This >becomes rather more important if the client is actually using an API >(MSDAIPP??) that offers large-scope operations, yet how can it guarantee >that operation will work or won't work if it can only send it piecemeal to >the server? I'm really glad you brought this up, Lisa. It's basically the "transactional server needs transaction boundaries" issue, and it points out a common and important difficulty inherent in broad standards: if you specify a transactional protocol then it doesn't allow for simple implementations (which can be quite useful), but if you don't specify a transactional protocol then people who implement transactional client/server pairs need extensions that provide missing features. In general, I think you need a layered protocol model (such as what's happening with DAV and delta-V) to satisfy both camps. Unfortunately, the base DAV protocol wasn't really well-designed to have transactions layered on top of it, because even single operations (such as DELETE) aren't required to have transactional semantics. I would certainly be interested in working on a transactional DAV-based protocol (delta-t ? :^), although I agree with Lisa it ranks behind a number of other issues in base DAV (and ACL and delta-V) itself. I wouldn't, however, be interested in adding batch-oriented calls to base DAV: while I completely understand Microsoft's use of extensions like this, and while Adobe does the same kind of thing (e.g., specialized headers to handle the difference between "unlock and advance taskflow" versus "unlock but don't affect taskflow"), adding batch operations to WebDAV feels much more like an appropriate application-specific patch than the basis for a good general-purpose transactional extension. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Jan 9 13:00:02 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08414 for ; Wed, 9 Jan 2002 13:00:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA17630; Wed, 9 Jan 2002 12:58:53 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 12:58:53 -0500 (EST) Resent-Message-Id: <200201091758.MAA17630@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA17558 for ; Wed, 9 Jan 2002 12:58:42 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA02362 for ; Wed, 9 Jan 2002 12:58:42 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA06027 for ; Wed, 9 Jan 2002 09:58:45 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 9 Jan 2002 09:57:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5755 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > That said, it's still not clear batch methods are so necessary they'd > preempt other work we've got to do. I agree that other work, especially the revision of RFC 2518, has higher priority than this. But, since we'll be revising our charter soon, I was mostly interested to see if it should be added as a charter to-do item. - Jim From w3c-dist-auth-request@w3.org Wed Jan 9 13:44:41 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10580 for ; Wed, 9 Jan 2002 13:44:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA22845; Wed, 9 Jan 2002 13:43:32 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 13:43:32 -0500 (EST) Resent-Message-Id: <200201091843.NAA22845@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA22825 for ; Wed, 9 Jan 2002 13:43:22 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA09895 for ; Wed, 9 Jan 2002 13:43:22 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id OAA30463; Wed, 9 Jan 2002 14:43:10 -0500 Reply-To: From: "Matt Timmermans" To: "'Julian Reschke'" , "'Pill, Juergen'" , "'WebDAV'" Date: Wed, 9 Jan 2002 13:42:41 -0500 Message-ID: <001c01c1993d$6c869a60$d482a8c0@mt2k> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5756 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > > Matt, > > I think this is definitively going to be too ambitious. Possibly, but I believe it's the simplest and least dangerous solution that allows you to perform arbitrary compound operations with ACID semantics. > We really should start collecting the requirements first (as Jim did). Personally, I think it should be a requirement that you can perform arbitrary operations with ACID semantics. If you can't, then WebDAV is unsafe for many applications. The problem is that it can still be, and will be, used for those applications. But, of course, if noone else feels that way, then it's not a requirement, and we needn't worry about it. > If the problem you're trying to solve is an update of a structured > (multivalued) property, you could do this by LOCKing the resource now. That was the example, but there are an infinite variety of others that aren't restricted to a single resource, or just to properties. Most of these cannot be done with locking. > A lightweight protocol that doesn't need LOCKs could be defines like: > > - define a "PTag" (comparable to the ETag) that changes when > properties > change, > - extend the request body to PROPPATCH to optionally include > the PTag you > have and only do the PROPPATCH if the PTag is still valid) > - alternatively, extend DAV:set to marshall a reference value > to which the > current value is compared before updating the property. > Both of these only work for operations on a single resource, and the PTag can be very expensive to calculate. It probably is overkill to support a full execute-and-compare-results, but you can get the same functionality (for WebDAV) with a simple ASSERT method that only needs to be able to perform a few simple checks -- to confirm that a given property on a given resource has a given value, to confirm that a given resource exists or not, to confirm that an entity body hasn't changed (using etag if available), and to confirm the OPTIONS response of a given resource. If we're going to do transactional BATCH, then this is a very small price to pay to get real transactional semantics. From w3c-dist-auth-request@w3.org Wed Jan 9 13:54:35 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11244 for ; Wed, 9 Jan 2002 13:54:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA24549; Wed, 9 Jan 2002 13:53:42 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 13:53:42 -0500 (EST) Resent-Message-Id: <200201091853.NAA24549@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA24529 for ; Wed, 9 Jan 2002 13:53:33 -0500 (EST) Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA12250 for ; Wed, 9 Jan 2002 13:53:33 -0500 Received: from unx51.staff.flyingcroc.net (unx51.staff.flyingcroc.net [207.246.150.51]) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) with ESMTP id KAA41228 for ; Wed, 9 Jan 2002 10:53:17 -0800 (PST) Received: (from erk@localhost) by unx51.staff.flyingcroc.net (8.11.6/8.11.6) id g09IqYY05902; Wed, 9 Jan 2002 10:52:34 -0800 (PST) (envelope-from erk) To: w3c-dist-auth@w3.org In-Reply-To: References: Organization: Accretive Technology Group From: Erik Seaberg Date: 09 Jan 2002 10:52:33 -0800 Message-ID: <86ofk39x1q.fsf@unx51.staff.flyingcroc.net> Lines: 35 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Re: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5757 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Juergen Pill writes: > This BATCH method would open the door into a BATCH language, e.g. execute > request #2 only if request #1 results in a 200/OK response code. RFC 2616 already has a (non-XML) encoding for a series of requests or responses, and each request could have an ID that dependent requests can check the state of: BATCH * HTTP/1.1 Host: www.example.com Content-Type: application/http Transfer-Encoding: chunked 141 MKCOL /foo HTTP/1.1 Host: www.example.com Request-Id: Authorization: Digest response="..." PUT /foo/bar HTTP/1.1 Host: www.example.com Content-Type: text/plain Authorization: Digest response="..." If: (["2xx"]) hello world 0 Microsoft's approach of applying a common request to each of several resources also handles the basic performance problem and is probably simpler to implement, though moving it from custom bodies up to HTTP (for example, use "*" as the Request-URI and put a list of resources in a "Request-URIs:" header) would make it more reusable. From w3c-dist-auth-request@w3.org Wed Jan 9 20:27:01 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23461 for ; Wed, 9 Jan 2002 20:27:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA29364; Wed, 9 Jan 2002 20:24:42 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 20:24:42 -0500 (EST) Resent-Message-Id: <200201100124.UAA29364@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA29340 for ; Wed, 9 Jan 2002 20:24:35 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA10643 for ; Wed, 9 Jan 2002 20:24:35 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g0A1PLC10823 for ; Wed, 9 Jan 2002 17:25:21 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g0A1OK525218 for ; Wed, 9 Jan 2002 17:24:20 -0800 (PST) Received: from [153.32.158.166] ([153.32.158.166]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GPP7VZ00.I2A; Wed, 9 Jan 2002 17:23:59 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Wed, 9 Jan 2002 15:45:48 -0800 To: "Jim Whitehead" From: Daniel Brotsky Cc: "WebDAV" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5758 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 9:57 AM -0800 1/9/02, Jim Whitehead wrote: > > That said, it's still not clear batch methods are so necessary they'd >> preempt other work we've got to do. > >I agree that other work, especially the revision of RFC 2518, has higher >priority than this. But, since we'll be revising our charter soon, I was >mostly interested to see if it should be added as a charter to-do item. > >- Jim I would say "yes" if you phrase it in terms of general transactionality, not batch operations in particular. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Jan 9 20:59:17 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24277 for ; Wed, 9 Jan 2002 20:59:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA03193; Wed, 9 Jan 2002 20:58:16 -0500 (EST) Resent-Date: Wed, 9 Jan 2002 20:58:16 -0500 (EST) Resent-Message-Id: <200201100158.UAA03193@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA03173 for ; Wed, 9 Jan 2002 20:58:13 -0500 (EST) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA14292 for ; Wed, 9 Jan 2002 20:58:12 -0500 Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0A1wAd03840 for ; Wed, 9 Jan 2002 17:58:11 -0800 (PST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g0A1wAL24210 for ; Wed, 9 Jan 2002 18:58:10 -0700 (MST) From: "Eric Sedlar" To: "WebDAV" Date: Wed, 9 Jan 2002 17:59:39 -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.2919.6600 Importance: Normal In-Reply-To: Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5759 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree that BATCH methods should be added to the charter. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, January 09, 2002 9:58 AM > To: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > > > That said, it's still not clear batch methods are so necessary they'd > > preempt other work we've got to do. > > I agree that other work, especially the revision of RFC 2518, has higher > priority than this. But, since we'll be revising our charter soon, I was > mostly interested to see if it should be added as a charter to-do item. > > - Jim > > From w3c-dist-auth-request@w3.org Thu Jan 10 15:02:33 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22699 for ; Thu, 10 Jan 2002 15:02:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12444; Thu, 10 Jan 2002 15:00:18 -0500 (EST) Resent-Date: Thu, 10 Jan 2002 15:00:18 -0500 (EST) Resent-Message-Id: <200201102000.PAA12444@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA12392 for ; Thu, 10 Jan 2002 15:00:08 -0500 (EST) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA17228 for ; Thu, 10 Jan 2002 15:00:08 -0500 Received: from [216.36.111.249] (HELO moose) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.1) with SMTP id 15702040 for w3c-dist-auth@w3c.org; Thu, 10 Jan 2002 11:58:41 -0800 From: "Lisa Dusseault" To: "Webdav WG" Date: Thu, 10 Jan 2002 11:57:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0056_01C199CE.01B730A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5760 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C199CE.01B730A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A new draft is now out on quota. I've addressed a number of comments, mostly from Jim. Note that as a result of this review the property names have changed. Please review, it's not long. Lisa -----Original Message----- From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, January 09, 2002 1:03 PM To: IETF-Announce: Subject: I-D ACTION:draft-dusseault-dav-quota-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Quota and Size Properties for DAV Collections Author(s) : L. Dusseault, C. Warner Filename : draft-dusseault-dav-quota-01.txt Pages : 7 Date : 08-Jan-02 WebDAV servers are frequently deployed with collection quota (size) limitations. This Internet-Draft discusses the two properties and minor behaviors needed for clients to interoperate with quota implementations on WebDAV repositories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-dav-quota-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dusseault-dav-quota-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dusseault-dav-quota-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0056_01C199CE.01B730A0 Content-Type: Message/External-body; name="ATT00063.dat" Content-Disposition: attachment; filename="ATT00063.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020108150727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dusseault-dav-quota-01.txt ------=_NextPart_000_0056_01C199CE.01B730A0 Content-Type: Message/External-body; name="draft-dusseault-dav-quota-01.txt" Content-Disposition: attachment; filename="draft-dusseault-dav-quota-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020108150727.I-D@ietf.org> ------=_NextPart_000_0056_01C199CE.01B730A0-- From w3c-dist-auth-request@w3.org Thu Jan 10 15:29:47 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23315 for ; Thu, 10 Jan 2002 15:29:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA14250; Thu, 10 Jan 2002 15:27:56 -0500 (EST) Resent-Date: Thu, 10 Jan 2002 15:27:56 -0500 (EST) Resent-Message-Id: <200201102027.PAA14250@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA14226 for ; Thu, 10 Jan 2002 15:27:47 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA20938 for ; Thu, 10 Jan 2002 15:27:47 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA25110 for ; Thu, 10 Jan 2002 12:27:50 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 10 Jan 2002 12:26:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: How do I make my app DAV-aware? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5761 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added to the accept2 list. - Jim -----Original Message----- From: Michael Datuin [mailto:da2in@yahoo.com] Sent: Wednesday, January 09, 2002 6:53 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] How do I make my app DAV-aware? Hi! I'm a newbie to WebDAV and have just recently started looking at some WebDAV resources. I have an application that prompts the user for the filename and location to where he/she wants to save the data file that my app creates. This prompt is just the common save dialog and works well if the data file is being saved to the local drive of the user's PC. But, when the location is on webfolder, I get the following message "You cannot save in the folder you specified. Please choose another location." I've tried creating a dummy text file with both MS WordPad and Notepad (on a PC using Win2K), and tried to save (via the common save dialog) to the webfolder. Both cases give the above message. But, when I tried to do the same test using Microsoft Word 2000, the save operation works. Also, I tried another test with Webdrive (www.webdrive.com) and mapped a drive letter to the webfolder, used that drive letter and filename in my app, and that worked. So, my question is, how do I make my app work like Microsoft Word in it's use of the common save dialog? Or do I have to write a network redirector (which I have no idea how to do yet) to mimic what the Webdrive software is doing? I just want to allow my app to support the user's action of browsing to the webfolder (in the common save dialog of my app) and clicking on the Save button. Any info would greatly be appreciated! Thanks! -Michael __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From w3c-dist-auth-request@w3.org Thu Jan 10 16:10:33 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23974 for ; Thu, 10 Jan 2002 16:10:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA16974; Thu, 10 Jan 2002 16:09:22 -0500 (EST) Resent-Date: Thu, 10 Jan 2002 16:09:22 -0500 (EST) Resent-Message-Id: <200201102109.QAA16974@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA16945 for ; Thu, 10 Jan 2002 16:09:17 -0500 (EST) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA27510 for ; Thu, 10 Jan 2002 16:09:17 -0500 Received: from [216.36.111.249] (HELO moose) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.1) with SMTP id 16471730 for w3c-dist-auth@w3.org; Thu, 10 Jan 2002 13:07:11 -0800 From: "Lisa Dusseault" To: "WebDAV" Date: Thu, 10 Jan 2002 13:06:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: How do I make my app DAV-aware? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5762 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > So, my question is, how do I make my app work like > Microsoft Word in > it's use of the common save dialog? Or do I have to > write a network > redirector (which I have no idea how to do yet) to > mimic what the > Webdrive software is doing? Yes, you would have to write a network redirector, which might involve modifying the application, or install WEbDrive. I don't believe Microsoft makes its Web Folders API available for common use, but you might look into that as well. The reason Word works but Notepad doesn't, is because Word has special code to use Web Folders (part of Network Places in some Windows OS) and Notepad doesn't have that special code. In other words, Web Folders can't be used by just any application automatically -- special code has to be added. Lisa From w3c-dist-auth-request@w3.org Thu Jan 10 17:20:17 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25024 for ; Thu, 10 Jan 2002 17:20:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA22212; Thu, 10 Jan 2002 17:19:02 -0500 (EST) Resent-Date: Thu, 10 Jan 2002 17:19:02 -0500 (EST) Resent-Message-Id: <200201102219.RAA22212@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA22192 for ; Thu, 10 Jan 2002 17:18:56 -0500 (EST) Received: from cpimssmtpu10.email.msn.com (cpimssmtpu10.email.msn.com [207.46.181.85]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA07082 for ; Thu, 10 Jan 2002 17:18:56 -0500 Received: from centro ([63.231.38.161]) by cpimssmtpu10.email.msn.com with Microsoft SMTPSVC(5.0.2195.4617); Thu, 10 Jan 2002 14:17:23 -0800 Reply-To: From: "Dennis E. Hamilton" To: Cc: "WebDAV Discussion List" Date: Thu, 10 Jan 2002 14:18:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 10 Jan 2002 22:17:23.0599 (UTC) FILETIME=[9405C1F0:01C19A24] Subject: RE: How do I make my app DAV-aware? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5763 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I did a search on Web Folders on Microsoft's MSDN Online and found http://msdn.microsoft.com/library/default.asp?url=/library/en-us/off2000/htm l/ppconAboutWebFolders.asp About Web Folders (remember to concatenate this URL to use it) and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/off2000/htm l/fpobjWebFolder.asp documents the Web Folder object, which you should be able to use. I stopped on this one, but there should be more, especially in Office Developer if not elsewhere. You might want to look at making your application ODMA compliant as well. (Word 2000 is. Sometimes.) This won't get you to Web Folders directly, but we are looking at building an ODMA DMS Driver that provides Web Folders / WebDAV access. I don't have a promise on when we will have done that, though I would like prototype code running by AIIM 2002 in the first full week of March. Let me know whether the C Language ODMA API is something that is usable in your application. (There is a dormant project to make an ActiveX / Automation interface, but I need to put a bomb in that volcano.) If the API is usable, I can sketch a way to migrate if you are interested. Otherwise, you might dig into using Web Folders directly. It may take some work. -- Dennis Dennis E. Hamilton AIIM DMware Technical Coordinator ------------------ mailto:dennis.hamilton@acm.org tel. +1-206-932-6970 http://www.dmware.org cel. +1-206-779-9430 ODMA Support http://www.infonuovo.com/odma -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead Sent: Thursday, January 10, 2002 12:27 To: WebDAV Subject: FW: How do I make my app DAV-aware? Accidentally caught by the spam filter. I have added to the accept2 list. - Jim -----Original Message----- From: Michael Datuin [mailto:da2in@yahoo.com] Sent: Wednesday, January 09, 2002 6:53 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] How do I make my app DAV-aware? Hi! I'm a newbie to WebDAV and have just recently started looking at some WebDAV resources. I have an application that prompts the user for the filename and location to where he/she wants to save the data file that my app creates. This prompt is just the common save dialog and works well if the data file is being saved to the local drive of the user's PC. But, when the location is on webfolder, I get the following message "You cannot save in the folder you specified. Please choose another location." I've tried creating a dummy text file with both MS WordPad and Notepad (on a PC using Win2K), and tried to save (via the common save dialog) to the webfolder. Both cases give the above message. But, when I tried to do the same test using Microsoft Word 2000, the save operation works. Also, I tried another test with Webdrive (www.webdrive.com) and mapped a drive letter to the webfolder, used that drive letter and filename in my app, and that worked. So, my question is, how do I make my app work like Microsoft Word in it's use of the common save dialog? Or do I have to write a network redirector (which I have no idea how to do yet) to mimic what the Webdrive software is doing? I just want to allow my app to support the user's action of browsing to the webfolder (in the common save dialog of my app) and clicking on the Save button. Any info would greatly be appreciated! Thanks! -Michael __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From w3c-dist-auth-request@w3.org Thu Jan 10 17:41:37 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25386 for ; Thu, 10 Jan 2002 17:41:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA24325; Thu, 10 Jan 2002 17:38:08 -0500 (EST) Resent-Date: Thu, 10 Jan 2002 17:38:08 -0500 (EST) Resent-Message-Id: <200201102238.RAA24325@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA24288 for ; Thu, 10 Jan 2002 17:38:01 -0500 (EST) Received: from btclick.com (mta04.btfusion.com [62.172.195.246]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA10220 for ; Thu, 10 Jan 2002 17:38:00 -0500 Received: from simonh ([217.37.3.161]) by btclick.com (Netscape Messaging Server 4.15) with SMTP id GPQUUG00.ZNV for ; Thu, 10 Jan 2002 22:37:28 +0000 Reply-To: From: "Simon Hill" To: "'WebDAV'" Date: Thu, 10 Jan 2002 22:35:20 -0000 Message-ID: <000201c19a27$17411db0$a10325d9@simonh> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Subject: Database-based webDAV server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5764 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all Some of you have helped me out in the past, so I am hoping this group will help me again. I need to build an IIS database-based webDAV server, for want of a better description. My fundamental problem seems to be that I can't stop IIS from taking the webDAV request, and, i) on the one hand, locking my script files as if they were the files to be manipulated rather than a script to be run, and ii) on the other (if I lock webDAV down in attempt to let the header rewrite pass to my script), forbidding passage of any webDAV HTTP at all to my header-rewriting ISAPI filter. I have to pass the webDAV traffic to a script where I can parse the headers and translate them into database calls. I don't want to have to write my own webDAV client to do this, as I would like the system to interface with Dreamweaver 4 and Homesite 5 webDAV clients, where the locking phenomena appears. I don't see any other way of implementing the multi-user, version-controlled asset management that my application needs. yours hopefully Simon From w3c-dist-auth-request@w3.org Thu Jan 10 20:54:19 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27575 for ; Thu, 10 Jan 2002 20:54:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA12179; Thu, 10 Jan 2002 20:52:47 -0500 (EST) Resent-Date: Thu, 10 Jan 2002 20:52:47 -0500 (EST) Resent-Message-Id: <200201110152.UAA12179@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA12159 for ; Thu, 10 Jan 2002 20:52:43 -0500 (EST) Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA03376 for ; Thu, 10 Jan 2002 20:52:42 -0500 Received: from unx51.staff.flyingcroc.net (unx51.staff.flyingcroc.net [207.246.150.51]) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) with ESMTP id RAA61009; Thu, 10 Jan 2002 17:52:35 -0800 (PST) Received: (from erk@localhost) by unx51.staff.flyingcroc.net (8.11.6/8.11.6) id g0B1psj31801; Thu, 10 Jan 2002 17:51:54 -0800 (PST) (envelope-from erk) To: w3c-dist-auth@w3c.org Cc: Lisa Dusseault In-Reply-To: References: From: Erik Seaberg Date: 10 Jan 2002 17:51:54 -0800 Message-ID: <86lmf5u01x.fsf@unx51.staff.flyingcroc.net> Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5765 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Lisa Dusseault writes: > A new draft is now out on quota. I've addressed a number of > comments, mostly from Jim. Note that as a result of this review the > property names have changed. Please review, it's not long. A client that wants to know how much storage is actually available in a collection has to PROPFIND each parent up to "/" looking for the minimum (quota-bytes - space-used-bytes) value. That number should be a live property, since any server enforcing quotas must be able to produce it fairly efficiently. It's natural to want to handle this through quotactl(2) on Unix, but the draft says {DAV:}space-used-bytes "MUST include child collections and all resources inside those child collections" without regard for who created them. Is the intent that all users MUST (or SHOULD) see identical {DAV:}quota-bytes and {DAV:}space-used-bytes values, or may an admin reveal quotas they've assigned to particular users? Should a client be able to atomically reserve some of a collection's storage so expensive requests don't have to race with others to claim the last bytes? It could be a header like Expect: 100-continue, reserve; content-length="999999" in a large PUT for example, or a live property on a collection allowing a reservation for several smaller resources or properties. On style, HTTP seems to use "octets" rather than "bytes" everywhere other than range requests. (BTW, what's the correct charset for the draft? 0xF4 and 0xF6 octets appear in place of a few quotation marks.) From w3c-dist-auth-request@w3.org Thu Jan 10 23:44:53 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01572 for ; Thu, 10 Jan 2002 23:44:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA25253; Thu, 10 Jan 2002 23:43:56 -0500 (EST) Resent-Date: Thu, 10 Jan 2002 23:43:56 -0500 (EST) Resent-Message-Id: <200201110443.XAA25253@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA25233 for ; Thu, 10 Jan 2002 23:43:51 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37068.rational.com [192.229.37.68]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA20991 for ; Thu, 10 Jan 2002 23:43:51 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Thu, 10 Jan 2002 23:42:49 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 23:42:49 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E1353@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 10 Jan 2002 23:42:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5766 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Daniel Brotsky [mailto:dbrotsky@adobe.com] I think there are a variety of client needs here. These are probably a little too fuzzy to be called requirements :^), but it's the best I can do right now. 1. This came up at the first interop, and most servers seemed to be compliant by the second interop: The part of a lock is to be completely controlled by the client. The server MUST not alter it (i.e., lock discovery, if it returns the information, must return exactly equivalent XML to that in the LOCK request). There's a lot of discussion of why this is needed in the archives; the gist is that it's the only client-controlled XML that's always associated with a LOCK, so clients of a given ilk can use it to exchange conventional information with each other about the lock. I agree. 2. There's some well-known specification of "principal" in the sense of "authenticated user ID whose authorization is being used for the current request." Probably this is a string of some kind, and probably there are localization issues so we will want this string to be in a known encoding (e.g., UTF-8) or else all mechanisms that return this string must be able to return the encoding. In general, the user will not map 1-1 with a "principal", but rather a user will "match" one or more principals. Therefore I do not see that it is feasible or desireable to try to identify a particular principal for the current user. 3. Clients need to know/be able to discover which "principal" they are. I don't really know enough about the range of authentication schemes to understand whether clients can always know for sure what "principal" the server is associating with them based on the client-generated authentication header, or whether the client might simply have been given some set of opaque credentials and need the server to tell it which "principal" those credentials make it. I believe this is the same as (2), and the same counter-arguments apply. 4. Clients need to know/be able to discover which "principal" owns a given lock, that is, which principal made the original lock request. We did agree in an earlier thread that a "DAV:can-lock" and a "DAV:can-unlock" privilege should be supported, so that an ACL can indicate who can lock or unlock a resource. But I disagree that it is necessary or useful to identify a principal that "owns" the lock, since it is the DAV:can-lock and DAV:can-unlock ACL that matters, and that is not determinable from the "principal" that created the lock. 5. Clients need to know/be able to discover where the "root resource" of a lock is; that is, the resource on which the lock owner can do an UNLOCK of the right depth and get the lock released. I agree. So my set of requirements would be: A) The DAV:owner field of the lock is under client control. B) A DAV:can-lock and DAV:can-unlock privilege should be defined. C) The root resource of a lock should be discoverable. From w3c-dist-auth-request@w3.org Fri Jan 11 00:50:52 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02419 for ; Fri, 11 Jan 2002 00:50:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA27556; Fri, 11 Jan 2002 00:49:58 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 00:49:58 -0500 (EST) Resent-Message-Id: <200201110549.AAA27556@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA27533 for ; Fri, 11 Jan 2002 00:49:52 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA27029 for ; Fri, 11 Jan 2002 00:49:51 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g0B5ob600818 for ; Thu, 10 Jan 2002 21:50:38 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g0B5mAs23173 for ; Thu, 10 Jan 2002 21:48:10 -0800 (PST) Received: from [153.32.158.166] ([130.248.188.68]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GPREU300.AUL; Thu, 10 Jan 2002 21:49:15 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1056E1353@SUS-MA1IT01> References: <3906C56A7BD1F54593344C05BD1374B1056E1353@SUS-MA1IT01> Date: Thu, 10 Jan 2002 21:49:38 -0800 To: "Clemm, Geoff" From: Daniel Brotsky Cc: w3c-dist-auth@w3c.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5767 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Geoff, I think you and I are basically in agreement, but that you are using a farily well-refined notion of principal based on the ACL spec while I'm talking about the unrefined/undefined notion of "principal" used in the DAV spec. The intuition here, at least for me, is that the DAV spec basically says the following: 1. when you obtain a lock, the lock is "identified with" the authenticated principal your request is authorized as and the lock token. 2. (modulo administrative privileges for some users) only the principal who obtained the lock can use it or unlock it, and that principal must supply the token in any request that uses/unlocks the lock. It's against that intution that I claim simple DAV clients (not necessarily ACL clients) need to be able to find out "who does the server think I am" and "who does the server think the principal identified with this lock is" so they can compare the two. Notice that it's really the comparing of the two that is important: I agree that many servers will not want to reveal other user identities so just having a way of saying "am I the owner of this lock" is actually enough. dan At 11:42 PM -0500 1/10/02, Clemm, Geoff wrote: > From: Daniel Brotsky [mailto:dbrotsky@adobe.com] > > I think there are a variety of client needs here. These are > probably a little too fuzzy to be called requirements :^), but it's > the best I can do right now. > > 1. This came up at the first interop, and most servers seemed to be > compliant by the second interop: > > The part of a lock is to be completely controlled by the > client. The server MUST not alter it (i.e., lock discovery, if it > returns the information, must return exactly equivalent XML > to that in the LOCK request). > > There's a lot of discussion of why this is needed in the archives; > the gist is that it's the only client-controlled XML that's always > associated with a LOCK, so clients of a given ilk can use it to > exchange conventional information with each other about the lock. > >I agree. > > 2. There's some well-known specification of "principal" in the > sense of "authenticated user ID whose authorization is being used > for the current request." Probably this is a string of some kind, > and probably there are localization issues so we will want this > string to be in a known encoding (e.g., UTF-8) or else all > mechanisms that return this string must be able to return the > encoding. > >In general, the user will not map 1-1 with a "principal", but rather >a user will "match" one or more principals. Therefore I do not see >that it is feasible or desireable to try to identify a particular >principal for the current user. > > 3. Clients need to know/be able to discover which "principal" they > are. I don't really know enough about the range of authentication > schemes to understand whether clients can always know for sure what > "principal" the server is associating with them based on the > client-generated authentication header, or whether the client might > simply have been given some set of opaque credentials and need the > server to tell it which "principal" those credentials make it. > >I believe this is the same as (2), and the same counter-arguments >apply. > > 4. Clients need to know/be able to discover which "principal" owns > a given lock, that is, which principal made the original lock > request. > >We did agree in an earlier thread that a "DAV:can-lock" and a >"DAV:can-unlock" privilege should be supported, so that an ACL >can indicate who can lock or unlock a resource. > >But I disagree that it is necessary or useful to identify a principal >that "owns" the lock, since it is the DAV:can-lock and DAV:can-unlock >ACL that matters, and that is not determinable from the "principal" >that created the lock. > > 5. Clients need to know/be able to discover where the "root > resource" of a lock is; that is, the resource on which the lock > owner can do an UNLOCK of the right depth and get the lock > released. > >I agree. > >So my set of requirements would be: > >A) The DAV:owner field of the lock is under client control. > >B) A DAV:can-lock and DAV:can-unlock privilege should be defined. > >C) The root resource of a lock should be discoverable. -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Fri Jan 11 03:10:36 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11767 for ; Fri, 11 Jan 2002 03:10:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA03186; Fri, 11 Jan 2002 03:09:26 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 03:09:26 -0500 (EST) Resent-Message-Id: <200201110809.DAA03186@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA03162 for ; Fri, 11 Jan 2002 03:09:17 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA07320 for ; Fri, 11 Jan 2002 03:09:17 -0500 Received: from apu [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 11 Jan 2002 09:08:38 +0100 From: "Stefan Eissing" To: "Daniel Brotsky" , "Clemm, Geoff" Cc: Date: Fri, 11 Jan 2002 09:08:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5768 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky > > Geoff, > > I think you and I are basically in agreement, but that you are using > a farily well-refined notion of principal based on the ACL spec while > I'm talking about the unrefined/undefined notion of "principal" used All true, but when you define a principal for locking, this principal should comply to the definition of principal in the ACL spec. > in the DAV spec. The intuition here, at least for me, is that the > DAV spec basically says the following: > > 1. when you obtain a lock, the lock is "identified with" the > authenticated principal your request is authorized as and the lock > token. > > 2. (modulo administrative privileges for some users) only the > principal who obtained the lock can use it or unlock it, and that > principal must supply the token in any request that uses/unlocks the > lock. > > It's against that intution that I claim simple DAV clients (not > necessarily ACL clients) need to be able to find out "who does the > server think I am" and "who does the server think the principal > identified with this lock is" so they can compare the two. > > Notice that it's really the comparing of the two that is important: I > agree that many servers will not want to reveal other user identities > so just having a way of saying "am I the owner of this lock" is > actually enough. > > dan > > At 11:42 PM -0500 1/10/02, Clemm, Geoff wrote: > > From: Daniel Brotsky [mailto:dbrotsky@adobe.com] > > > > I think there are a variety of client needs here. These are > > probably a little too fuzzy to be called requirements :^), but it's > > the best I can do right now. > > > > 1. This came up at the first interop, and most servers seemed to be > > compliant by the second interop: > > > > The part of a lock is to be completely controlled by the > > client. The server MUST not alter it (i.e., lock discovery, if it > > returns the information, must return exactly equivalent XML > > to that in the LOCK request). > > > > There's a lot of discussion of why this is needed in the archives; > > the gist is that it's the only client-controlled XML that's always > > associated with a LOCK, so clients of a given ilk can use it to > > exchange conventional information with each other about the lock. > > > >I agree. > > > > 2. There's some well-known specification of "principal" in the > > sense of "authenticated user ID whose authorization is being used > > for the current request." Probably this is a string of some kind, > > and probably there are localization issues so we will want this > > string to be in a known encoding (e.g., UTF-8) or else all > > mechanisms that return this string must be able to return the > > encoding. > > > >In general, the user will not map 1-1 with a "principal", but rather > >a user will "match" one or more principals. Therefore I do not see > >that it is feasible or desireable to try to identify a particular > >principal for the current user. > > > > 3. Clients need to know/be able to discover which "principal" they > > are. I don't really know enough about the range of authentication > > schemes to understand whether clients can always know for sure what > > "principal" the server is associating with them based on the > > client-generated authentication header, or whether the client might > > simply have been given some set of opaque credentials and need the > > server to tell it which "principal" those credentials make it. > > > >I believe this is the same as (2), and the same counter-arguments > >apply. > > > > 4. Clients need to know/be able to discover which "principal" owns > > a given lock, that is, which principal made the original lock > > request. > > > >We did agree in an earlier thread that a "DAV:can-lock" and a > >"DAV:can-unlock" privilege should be supported, so that an ACL > >can indicate who can lock or unlock a resource. > > > >But I disagree that it is necessary or useful to identify a principal > >that "owns" the lock, since it is the DAV:can-lock and DAV:can-unlock > >ACL that matters, and that is not determinable from the "principal" > >that created the lock. > > > > 5. Clients need to know/be able to discover where the "root > > resource" of a lock is; that is, the resource on which the lock > > owner can do an UNLOCK of the right depth and get the lock > > released. > > > >I agree. > > > >So my set of requirements would be: > > > >A) The DAV:owner field of the lock is under client control. > > > >B) A DAV:can-lock and DAV:can-unlock privilege should be defined. > > > >C) The root resource of a lock should be discoverable. > > > -- > Daniel Brotsky, Adobe Systems > tel 408-536-4150, pager 877-704-4062 > 2-way pager email: > > > From w3c-dist-auth-request@w3.org Fri Jan 11 03:15:49 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11810 for ; Fri, 11 Jan 2002 03:15:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA03602; Fri, 11 Jan 2002 03:14:53 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 03:14:53 -0500 (EST) Resent-Message-Id: <200201110814.DAA03602@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA03582 for ; Fri, 11 Jan 2002 03:14:42 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA07788 for ; Fri, 11 Jan 2002 03:14:42 -0500 Received: from apu [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 11 Jan 2002 09:14:02 +0100 From: "Stefan Eissing" To: "Clemm, Geoff" , Date: Fri, 11 Jan 2002 09:14:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1056E1353@SUS-MA1IT01> X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5769 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > From: Daniel Brotsky [mailto:dbrotsky@adobe.com] > [...] > > 2. There's some well-known specification of "principal" in the > sense of "authenticated user ID whose authorization is being used > for the current request." Probably this is a string of some kind, > and probably there are localization issues so we will want this > string to be in a known encoding (e.g., UTF-8) or else all > mechanisms that return this string must be able to return the > encoding. > > In general, the user will not map 1-1 with a "principal", but rather > a user will "match" one or more principals. Therefore I do not see > that it is feasible or desireable to try to identify a particular > principal for the current user. I do not fully understand. There is always a principal for a request (and be it {DAV:}anonymous), so it would be easy for a server to keep this information with an active lock. When there is a ACL privilege {DAV:}can-unlock and this is granted to a particular principal on the locked resource, the usualy ACL matching of principals would apply. So, I do not see the problem with reporting a locking-principal as part of an active lock. What am I missing? Servers without ACL? //Stefan From w3c-dist-auth-request@w3.org Fri Jan 11 03:29:20 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11896 for ; Fri, 11 Jan 2002 03:29:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA04339; Fri, 11 Jan 2002 03:28:25 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 03:28:25 -0500 (EST) Resent-Message-Id: <200201110828.DAA04339@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA04319 for ; Fri, 11 Jan 2002 03:28:17 -0500 (EST) Received: from nike.mediafactory.de ([194.25.116.194]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA09194 for ; Fri, 11 Jan 2002 03:28:17 -0500 Message-Id: <200201110828.DAA09194@tux.w3.org> Received: FROM nike BY nike.mediafactory.de ; Fri Jan 11 09:28:12 2002 +0100 From: "Henrik Genssen" To: Cc: References: <000201c19a27$17411db0$a10325d9@simonh> Date: Fri, 11 Jan 2002 09:28:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id DAA04319 Subject: Re: Database-based webDAV server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5770 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Do you want to handle the Webdav calls by a script or an ISAPI extension? I think the ASP-dll won't let you do this - maybe perl or php via cgi or isapi... but what you can do is: build an ISAPI-filter manipulating the requested file by adding a new extension - saying ".dav" and than let IIS handel all incomming calls by a second ISAPI extension that does your job. This works fine throughout IIS3+. Henrik ----- Original Message ----- From: "Simon Hill" To: "'WebDAV'" Sent: Thursday, January 10, 2002 11:35 PM Subject: Database-based webDAV server > Hi all > > Some of you have helped me out in the past, so I am hoping this group will > help me again. > > I need to build an IIS database-based webDAV server, for want of a better > description. > > My fundamental problem seems to be that I can't stop IIS from taking the > webDAV request, and, i) on the one hand, locking my script files as if they > were the files to be manipulated rather than a script to be run, and ii) on > the other (if I lock webDAV down in attempt to let the header rewrite pass > to my script), forbidding passage of any webDAV HTTP at all to my > header-rewriting ISAPI filter. > > I have to pass the webDAV traffic to a script where I can parse the headers > and translate them into database calls. > > I don't want to have to write my own webDAV client to do this, as I would > like the system to interface with Dreamweaver 4 and Homesite 5 webDAV > clients, where the locking phenomena appears. > > I don't see any other way of implementing the multi-user, version-controlled > asset management that my application needs. > > yours hopefully > > Simon > > > From w3c-dist-auth-request@w3.org Fri Jan 11 03:43:09 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11982 for ; Fri, 11 Jan 2002 03:43:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA05040; Fri, 11 Jan 2002 03:42:00 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 03:42:00 -0500 (EST) Resent-Message-Id: <200201110842.DAA05040@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA05020 for ; Fri, 11 Jan 2002 03:41:52 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA10677 for ; Fri, 11 Jan 2002 03:41:49 -0500 Received: from apu [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 11 Jan 2002 09:41:13 +0100 From: "Stefan Eissing" To: "Lisa Dusseault" , "Webdav WG" Date: Fri, 11 Jan 2002 09:41:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5771 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I can see how this draft is applied to servers like Sharemation which have a separate collection hierarchy for each user. I have more trouble applying it to servers where it is common that more than one user has write access to collections. Imagine that Sharemation has a collection containing all your user collections. How would the quota properties appear on that collection? Where I see a real problem is a server supporting bindings. Suppose I have the following hierarchy: - A |-B | |- b' | |-C |- b" where b' and b" are bindings to the resource b. How will a server show the quota properties on B, C and A? Will space-used-bytes count b' and b" for B and C and will the space appear duplicate in A? //Stefan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, January 10, 2002 8:58 PM > To: Webdav WG > Subject: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > A new draft is now out on quota. I've addressed a number of comments, > mostly from Jim. Note that as a result of this review the property names > have changed. Please review, it's not long. > > Lisa > > -----Original Message----- > From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf > Of Internet-Drafts@ietf.org > Sent: Wednesday, January 09, 2002 1:03 PM > To: IETF-Announce: > Subject: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Quota and Size Properties for DAV Collections > Author(s) : L. Dusseault, C. Warner > Filename : draft-dusseault-dav-quota-01.txt > Pages : 7 > Date : 08-Jan-02 > > WebDAV servers are frequently deployed with collection quota (size) > limitations. This Internet-Draft discusses the two properties and > minor behaviors needed for clients to interoperate with quota > implementations on WebDAV repositories. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-dusseault-dav-quota-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-dusseault-dav-quota-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-dusseault-dav-quota-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From w3c-dist-auth-request@w3.org Fri Jan 11 08:33:39 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14300 for ; Fri, 11 Jan 2002 08:33:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA28393; Fri, 11 Jan 2002 08:31:58 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 08:31:58 -0500 (EST) Resent-Message-Id: <200201111331.IAA28393@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA28299 for ; Fri, 11 Jan 2002 08:31:42 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37068.rational.com [192.229.37.68]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA16303 for ; Fri, 11 Jan 2002 08:31:42 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Fri, 11 Jan 2002 08:30:40 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 08:30:40 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E139E@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 11 Jan 2002 08:30:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5773 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Daniel Brotsky [mailto:dbrotsky@adobe.com] I think you and I are basically in agreement, but that you are using a farily well-refined notion of principal based on the ACL spec while I'm talking about the unrefined/undefined notion of "principal" used in the DAV spec. Yes, but we do need a well-refined notion to produce an interoperable protocol here (i.e. the vague notion in 2518 would not suffice). The intuition here, at least for me, is that the DAV spec basically says the following: 1. when you obtain a lock, the lock is "identified with" the authenticated principal your request is authorized as and the lock token. 2. (modulo administrative privileges for some users) only the principal who obtained the lock can use it or unlock it, and that principal must supply the token in any request that uses/unlocks the lock. This vague notion of principal does not provide an interoperable mechanism. The client presents credentials which may or may not match a variety of "principals" relevant for access to a given resource. It is not the case that the client *is* exactly one of those principals, but rather just that its presented credentials "match" one or more of the principals relevant for ACEs on that resource. It is true that you can have properties of a resource that identify special principals (e.g. a DAV:owner property), but that is to provide a level of indirection in the ACL mechanism, not to persistently "identify" the client that created the resource. Thus the vague notion of principal from 2518 has been firmed up in the context of the ACL spec with the idea that there are DAV:can-lock and DAV:can-unlock privileges on the locked resource. It's against that intution that I claim simple DAV clients (not necessarily ACL clients) need to be able to find out "who does the server think I am" and "who does the server think the principal identified with this lock is" so they can compare the two. The ACL protocol specifically does not provide a "who am I" mechanism, because that is an ambiguous question. In general, all you can say is which of a set of principals they "match", and the set of principals can vary depending on what resource you are talking about, and what operation on that resource you are talking about. The only well formed question is "what things can I do to this particular resource". Notice that it's really the comparing of the two that is important: I agree that many servers will not want to reveal other user identities so just having a way of saying "am I the owner of this lock" is actually enough. Yes, that is another reason why the ACL spec does not depend on the ability for a client to "match" principal URLs. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Jan 11 08:33:39 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14303 for ; Fri, 11 Jan 2002 08:33:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA28347; Fri, 11 Jan 2002 08:31:49 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 08:31:49 -0500 (EST) Resent-Message-Id: <200201111331.IAA28347@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA28297 for ; Fri, 11 Jan 2002 08:31:42 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37068.rational.com [192.229.37.68]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA16302 for ; Fri, 11 Jan 2002 08:31:42 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Fri, 11 Jan 2002 08:30:40 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 08:30:40 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E139F@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 11 Jan 2002 08:30:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5772 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > From: Clemm, Geoff > > In general, the user will not map 1-1 with a "principal", but rather > a user will "match" one or more principals. Therefore I do not see > that it is feasible or desireable to try to identify a particular > principal for the current user. I do not fully understand. There is always a principal for a request (and be it {DAV:}anonymous), so it would be easy for a server to keep this information with an active lock. No, there are credentials for a request, but those credentials can match a variety of principals in a variety of different principal spaces relevant to the ACL on a resource. When there is a ACL privilege {DAV:}can-unlock and this is granted to a particular principal on the locked resource, the usualy ACL matching of principals would apply. It is not matching of principals that takes place, but rather the matching of the client credentials against the principals identified in the ACE of an ACL. So, I do not see the problem with reporting a locking-principal as part of an active lock. What am I missing? Servers without ACL? I think the only thing being missed is that a client has credentials, and that these credentials match a variety of principals, as opposed to identifying the client as *being* a particular principal. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Jan 11 09:07:49 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15162 for ; Fri, 11 Jan 2002 09:07:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA04232; Fri, 11 Jan 2002 09:06:30 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 09:06:30 -0500 (EST) Resent-Message-Id: <200201111406.JAA04232@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA04110 for ; Fri, 11 Jan 2002 09:06:14 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA21972 for ; Fri, 11 Jan 2002 09:06:14 -0500 Received: from apu [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 11 Jan 2002 15:05:39 +0100 From: "Stefan Eissing" To: "Clemm, Geoff" , Date: Fri, 11 Jan 2002 15:05:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1056E139F@SUS-MA1IT01> X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5774 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > > > From: Clemm, Geoff > > > > In general, the user will not map 1-1 with a "principal", but rather > > a user will "match" one or more principals. Therefore I do not see > > that it is feasible or desireable to try to identify a particular > > principal for the current user. > > I do not fully understand. There is always a principal for a request > (and be it {DAV:}anonymous), so it would be easy for a server to keep > this information with an active lock. > > No, there are credentials for a request, but those credentials > can match a variety of principals in a variety of different > principal spaces relevant to the ACL on a resource. ...scanning acl spec...done. I see what you mean. There could be an ACL server which just has "group" principals and no principals with one-one relation to users (well it could even skip user credentials and just have credentials matching groups). As for identifying the owner of a lock this means one of the following: a) the server has a "primary" principal and could report it as lock owner. It may nevertheless choose not to do so, due to confidentiality reasons. b) the server has no such thing and thus cannot report who owns a lock. It only can tell if your credentials are sufficient to lock/unlock a resource. That leaves possible lock-owner information up to the client. Either it provides something meaningful to others (e.g. mailto:) or it is silent. Would that be a feasible way forward? //Stefan From w3c-dist-auth-request@w3.org Fri Jan 11 09:27:15 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15681 for ; Fri, 11 Jan 2002 09:27:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA06827; Fri, 11 Jan 2002 09:26:08 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 09:26:08 -0500 (EST) Resent-Message-Id: <200201111426.JAA06827@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA06793 for ; Fri, 11 Jan 2002 09:25:57 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37068.rational.com [192.229.37.68]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA25014 for ; Fri, 11 Jan 2002 09:25:58 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Fri, 11 Jan 2002 09:24:56 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 09:24:56 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E13D0@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 11 Jan 2002 09:24:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5775 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I see no evidence of a BATCH method or a Request-Id header in my copy of 2616. Could you indicate what sections of 2616 you are referring to? Thanks, Geoff -----Original Message----- From: Erik Seaberg [mailto:erk@flyingcroc.com] Sent: Wednesday, January 09, 2002 1:53 PM To: w3c-dist-auth@w3.org Subject: Re: Interest in standardizing Batch methods? Juergen Pill writes: > This BATCH method would open the door into a BATCH language, e.g. execute > request #2 only if request #1 results in a 200/OK response code. RFC 2616 already has a (non-XML) encoding for a series of requests or responses, and each request could have an ID that dependent requests can check the state of: BATCH * HTTP/1.1 Host: www.example.com Content-Type: application/http Transfer-Encoding: chunked 141 MKCOL /foo HTTP/1.1 Host: www.example.com Request-Id: Authorization: Digest response="..." PUT /foo/bar HTTP/1.1 Host: www.example.com Content-Type: text/plain Authorization: Digest response="..." If: (["2xx"]) hello world 0 Microsoft's approach of applying a common request to each of several resources also handles the basic performance problem and is probably simpler to implement, though moving it from custom bodies up to HTTP (for example, use "*" as the Request-URI and put a list of resources in a "Request-URIs:" header) would make it more reusable. From w3c-dist-auth-request@w3.org Fri Jan 11 09:45:28 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16012 for ; Fri, 11 Jan 2002 09:45:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA09502; Fri, 11 Jan 2002 09:44:19 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 09:44:19 -0500 (EST) Resent-Message-Id: <200201111444.JAA09502@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA09482 for ; Fri, 11 Jan 2002 09:44:14 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37068.rational.com [192.229.37.68]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA27604 for ; Fri, 11 Jan 2002 09:44:14 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Fri, 11 Jan 2002 09:40:44 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 09:40:44 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E13DB@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 11 Jan 2002 09:40:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5776 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] ...scanning acl spec...done. I see what you mean. There could be an ACL server which just has "group" principals and no principals with one-one relation to users (well it could even skip user credentials and just have credentials matching groups). As for identifying the owner of a lock this means one of the following: a) the server has a "primary" principal and could report it as lock owner. It may nevertheless choose not to do so, due to confidentiality reasons. b) the server has no such thing and thus cannot report who owns a lock. It only can tell if your credentials are sufficient to lock/unlock a resource. That leaves possible lock-owner information up to the client. Either it provides something meaningful to others (e.g. mailto:) or it is silent. Would that be a feasible way forward? Yes, I believe there is agreement that the current DAV:owner field in the DAV:lockinfo should be used for this purpose (and is client defined). If you add the definition of appropriate privileges (e.g. DAV:can-lock and DAV:can-unlock), then I believe we have all we need, while supporting servers that fall into those cases you describe above (i.e. do not want to repot principals for confidentiality reasons, or have no such principal to report). Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Jan 11 12:44:15 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23069 for ; Fri, 11 Jan 2002 12:44:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA12526; Fri, 11 Jan 2002 12:41:33 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 12:41:33 -0500 (EST) Resent-Message-Id: <200201111741.MAA12526@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA12498 for ; Fri, 11 Jan 2002 12:41:21 -0500 (EST) Received: from smtp-server3.tampabay.rr.com (smtp-server3.tampabay.rr.com [65.32.1.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA04482 for ; Fri, 11 Jan 2002 12:41:21 -0500 Received: from redfish (6532112hfc151.tampabay.rr.com [65.32.112.151]) by smtp-server3.tampabay.rr.com (8.11.2/8.11.2) with SMTP id g0BHanW11865; Fri, 11 Jan 2002 12:36:50 -0500 (EST) From: "Steve Lomicka" To: , "'WebDAV'" Date: Fri, 11 Jan 2002 12:36:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <000201c19a27$17411db0$a10325d9@simonh> Subject: RE: Database-based webDAV server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5777 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit If by script you mean .ASP script, I don't think .ASP will let you intercept HTTP requests soon enough in the IIS chain of events. I'm feel pretty confident that you will have to get inside of IIS via ISAPI filters and C++. HTH, Steve > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Simon Hill > Sent: Thursday, January 10, 2002 5:35 PM > To: 'WebDAV' > Subject: Database-based webDAV server > > > Hi all > > Some of you have helped me out in the past, so I am hoping this group will > help me again. > > I need to build an IIS database-based webDAV server, for want of a better > description. > > My fundamental problem seems to be that I can't stop IIS from taking the > webDAV request, and, i) on the one hand, locking my script files > as if they > were the files to be manipulated rather than a script to be run, > and ii) on > the other (if I lock webDAV down in attempt to let the header rewrite pass > to my script), forbidding passage of any webDAV HTTP at all to my > header-rewriting ISAPI filter. > > I have to pass the webDAV traffic to a script where I can parse > the headers > and translate them into database calls. > > I don't want to have to write my own webDAV client to do this, as I would > like the system to interface with Dreamweaver 4 and Homesite 5 webDAV > clients, where the locking phenomena appears. > > I don't see any other way of implementing the multi-user, > version-controlled > asset management that my application needs. > > yours hopefully > > Simon > From w3c-dist-auth-request@w3.org Fri Jan 11 13:28:14 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24648 for ; Fri, 11 Jan 2002 13:28:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA19386; Fri, 11 Jan 2002 13:25:50 -0500 (EST) Resent-Date: Fri, 11 Jan 2002 13:25:50 -0500 (EST) Resent-Message-Id: <200201111825.NAA19386@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA19362 for ; Fri, 11 Jan 2002 13:25:42 -0500 (EST) Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA12493 for ; Fri, 11 Jan 2002 13:25:42 -0500 Received: from unx51.staff.flyingcroc.net (unx51.staff.flyingcroc.net [207.246.150.51]) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) with ESMTP id KAA14677; Fri, 11 Jan 2002 10:25:11 -0800 (PST) Received: (from erk@localhost) by unx51.staff.flyingcroc.net (8.11.6/8.11.6) id g0BIOVd45429; Fri, 11 Jan 2002 10:24:31 -0800 (PST) (envelope-from erk) To: w3c-dist-auth@w3.org Cc: Geoff Clemm Organization: Accretive Technology Group In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1056E13D0@SUS-MA1IT01> References: <86ofk39x1q.fsf@unx51.staff.flyingcroc.net> <3906C56A7BD1F54593344C05BD1374B1056E13D0@SUS-MA1IT01> From: Erik Seaberg Date: 11 Jan 2002 10:24:31 -0800 Message-ID: <86ofk0hhk0.fsf@unx51.staff.flyingcroc.net> Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Re: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5778 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Geoff Clemm writes: > I see no evidence of a BATCH method or a Request-Id header in my > copy of 2616. Could you indicate what sections of 2616 you are > referring to? Sorry I was unclear. I only reused 2616's "application/http" media type, rather than invent a new encoding for a sequence of HTTP requests. The BATCH method and Request-Id header I suggested are new (Content-Id could also be used in a multipart with a "message/http" body for each request). From w3c-dist-auth-request@w3.org Sun Jan 13 18:49:53 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15972 for ; Sun, 13 Jan 2002 18:49:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA13577; Sun, 13 Jan 2002 18:47:21 -0500 (EST) Resent-Date: Sun, 13 Jan 2002 18:47:21 -0500 (EST) Resent-Message-Id: <200201132347.SAA13577@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA13557 for ; Sun, 13 Jan 2002 18:47:15 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA29213 for ; Sun, 13 Jan 2002 18:47:14 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA99766; Sun, 13 Jan 2002 18:43:42 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0DNke3174960; Sun, 13 Jan 2002 18:46:40 -0500 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sun, 13 Jan 2002 17:42:21 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 01/13/2002 06:46:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5779 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > C) The root resource of a lock should be discoverable. I don't want to distract the discussion, but why is this necessary? Do we have a specific reason? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Jan 14 05:27:51 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00857 for ; Mon, 14 Jan 2002 05:27:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA19543; Mon, 14 Jan 2002 05:26:34 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 05:26:34 -0500 (EST) Resent-Message-Id: <200201141026.FAA19543@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA19523 for ; Mon, 14 Jan 2002 05:26:25 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA20744 for ; Mon, 14 Jan 2002 05:26:25 -0500 Received: (qmail 4450 invoked by uid 0); 14 Jan 2002 10:25:54 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 14 Jan 2002 10:25:54 -0000 From: "Julian Reschke" To: "Stefan Eissing" , "Clemm, Geoff" , Date: Mon, 14 Jan 2002 11:25:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5780 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Friday, January 11, 2002 3:06 PM > To: Clemm, Geoff; w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > > > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > > > > > From: Clemm, Geoff > > > > > > In general, the user will not map 1-1 with a "principal", > but rather > > > a user will "match" one or more principals. Therefore I do not see > > > that it is feasible or desireable to try to identify a particular > > > principal for the current user. > > > > I do not fully understand. There is always a principal for a request > > (and be it {DAV:}anonymous), so it would be easy for a server to keep > > this information with an active lock. > > > > No, there are credentials for a request, but those credentials > > can match a variety of principals in a variety of different > > principal spaces relevant to the ACL on a resource. > > ...scanning acl spec...done. > I see what you mean. There could be an ACL server which just has > "group" principals and no principals with one-one relation to users > (well it could even skip user credentials and just have credentials > matching groups). Well, if the set of principals with the ability to unlock the resource is bigger than one, why not report all of them (or a subset whicht the server thinks makes sense)? > As for identifying the owner of a lock this means one of the following: > a) the server has a "primary" principal and could report it as lock owner. > It may nevertheless choose not to do so, due to > confidentiality reasons. > b) the server has no such thing and thus cannot report who owns a lock. > It only can tell if your credentials are sufficient to lock/unlock > a resource. > > That leaves possible lock-owner information up to the client. Either it > provides something meaningful to others (e.g. mailto:) or it is silent. > Would that be a feasible way forward? That would still require that we define a format for this information (and we would have to deice whether to put it into the lockowner or into a new element). Julian From w3c-dist-auth-request@w3.org Mon Jan 14 12:44:26 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09043 for ; Mon, 14 Jan 2002 12:44:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA05712; Mon, 14 Jan 2002 12:43:17 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 12:43:17 -0500 (EST) Resent-Message-Id: <200201141743.MAA05712@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA05692 for ; Mon, 14 Jan 2002 12:43:09 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-074006.rational.com [130.213.74.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA32584 for ; Mon, 14 Jan 2002 12:43:07 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Mon, 14 Jan 2002 12:42:05 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 12:42:05 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AE99@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Mon, 14 Jan 2002 12:42:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5781 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: If a client does an UNLOCK, it would be good for it to know the set of resources that will be affected by the UNLOCK (especially if it is an adminstrative override of a lock held by some other principal). This would provide that information. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Sunday, January 13, 2002 5:42 PM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > C) The root resource of a lock should be discoverable. I don't want to distract the discussion, but why is this necessary? Do we have a specific reason? From w3c-dist-auth-request@w3.org Mon Jan 14 13:32:53 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11436 for ; Mon, 14 Jan 2002 13:32:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11393; Mon, 14 Jan 2002 13:31:22 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 13:31:22 -0500 (EST) Resent-Message-Id: <200201141831.NAA11393@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA11341 for ; Mon, 14 Jan 2002 13:31:06 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA12474 for ; Mon, 14 Jan 2002 13:31:06 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g0EITKP04748 for ; Mon, 14 Jan 2002 10:29:20 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g0EITPs14081 for ; Mon, 14 Jan 2002 10:29:25 -0800 (PST) Received: from [192.168.1.8] ([153.32.159.216]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GPXY2U00.FTZ; Mon, 14 Jan 2002 10:30:30 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Mon, 14 Jan 2002 10:16:21 -0800 To: "Stefan Eissing" From: Daniel Brotsky Cc: "Clemm, Geoff" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5783 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 3:05 PM +0100 1/11/02, Stefan Eissing wrote: >I see what you mean. There could be an ACL server which just has >"group" principals and no principals with one-one relation to users >(well it could even skip user credentials and just have credentials >matching groups). > >As for identifying the owner of a lock this means one of the following: >a) the server has a "primary" principal and could report it as lock owner. > It may nevertheless choose not to do so, due to confidentiality reasons. >b) the server has no such thing and thus cannot report who owns a lock. > It only can tell if your credentials are sufficient to lock/unlock > a resource. But (b) misses the point of my requirement, which is that a client needs to be able to issue a request that says "am I the that obtained this lock"? The client is *not* asking an ACL question: can I unlock this resource; the client is asking a workflow question: would I be unlocking someone else's lock if I did unlock the resource? It's the workflow question that's at the heart of the requirement. So, Geoff, given ACL's (desirable) vagueness about "principals", and building on your language about "request credentials", can we alter the DAV spec language so that servers can return info about "is this request authorized with the same credentials as the lock request" and still be compatible with ACL? dan P.S. Another way of looking at this is to say: the ACL info provides a way of distinguishing between principals (i.e., they have different capabilities), but that way of distinguishing is not required to be fine-grained enough to support what I claim is the "workflow intuition" behind DAV locking: locks are held by a particular and are only allowed to be used (in the absence of ACL or other server admin magic) by that regardless of token. My requirement is that users be able to determine whether they are currently authenticating requests as the same as the request that locked the resource was. -d. -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Mon Jan 14 13:32:55 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11447 for ; Mon, 14 Jan 2002 13:32:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11372; Mon, 14 Jan 2002 13:31:17 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 13:31:17 -0500 (EST) Resent-Message-Id: <200201141831.NAA11372@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA11337 for ; Mon, 14 Jan 2002 13:31:06 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA12469 for ; Mon, 14 Jan 2002 13:31:05 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g0EITKP04735 for ; Mon, 14 Jan 2002 10:29:20 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g0EIUp504026 for ; Mon, 14 Jan 2002 10:30:51 -0800 (PST) Received: from [192.168.1.8] ([153.32.159.216]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GPXY2T00.7YJ; Mon, 14 Jan 2002 10:30:29 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Mon, 14 Jan 2002 10:07:54 -0800 To: "Jason Crawford" From: Daniel Brotsky Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5782 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 5:42 PM -0500 1/13/02, Jason Crawford wrote: > > C) The root resource of a lock should be discoverable. > >I don't want to distract the discussion, but why is this necessary? Do we >have a specific reason? In addition to Geoff's answer: If you are an administrator trying to unlock a resource obtained by someone else, you have to be able to figure out which resource to unlock. You can't unlock an internal member of a collection that's locked by a depth-inifinity lock without knowing which collection was actually locked. Then you can decide whether unlocking that is the right thing to do. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Mon Jan 14 13:36:16 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11554 for ; Mon, 14 Jan 2002 13:36:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11703; Mon, 14 Jan 2002 13:34:53 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 13:34:53 -0500 (EST) Resent-Message-Id: <200201141834.NAA11703@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA11679 for ; Mon, 14 Jan 2002 13:34:43 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA13749 for ; Mon, 14 Jan 2002 13:34:43 -0500 Received: (qmail 20929 invoked by uid 0); 14 Jan 2002 18:34:11 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp008-rz3) with SMTP; 14 Jan 2002 18:34:11 -0000 From: "Julian Reschke" To: Date: Mon, 14 Jan 2002 19:34:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AE99@SUS-MA1IT01> Subject: Windows XP Webdav redirector Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5784 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I've been trying to get the WebDAV "redirector" (UA WebDAV-MiniRedir/5.1.2600) in Windows XP to mount our WebDAV server. I've found three issues for which I have workarounds, however, I'm still not able to mount from my server. Problem #1: basic authentication seems to be broken if the redirector *prompts* for the credentials. If you supply them on the command line: "net use * URI password /user:username" it seems to work. Problem #2: given a URI like "http://server/a/b/c", the client tries OPTIONS and PROPFIND on "http://server/a" (which is wrong because this resource may not be WebDAV enabled). A similar (known!) problem exists in IE's "open as web folder", while mounting a web folder using network places behaves correctly. Problem #3: the URI may not contain a port number (even if it's 80!) All these problems lead to error message 67 ("network name not found") with absolutely no useful additional information. After working around these issues, I can get the redirector to issue a PROPFIND (Depth: 0) against by target URI (with correct Basic Authentication credentials), and my server is responding with 207 (MULTISTATUS) and a response body which seems to be just fine (and is accepted by the webfolder client). However, I'm still getting error #67. Did anybody else have a similar problem and knows what might be going wrong? Julian From w3c-dist-auth-request@w3.org Mon Jan 14 14:03:23 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13101 for ; Mon, 14 Jan 2002 14:03:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA16715; Mon, 14 Jan 2002 14:02:23 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 14:02:23 -0500 (EST) Resent-Message-Id: <200201141902.OAA16715@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA16695 for ; Mon, 14 Jan 2002 14:02:19 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-074006.rational.com [130.213.74.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA19637 for ; Mon, 14 Jan 2002 14:02:19 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Mon, 14 Jan 2002 14:01:17 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 14:01:17 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AE9B@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Mon, 14 Jan 2002 14:01:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5785 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The client should never automatically reuse a lock taken out by another client (irrespective of whether or not it was another client with the same authentication credentials), but should only steal another client's lock on explicit request by the user. So the client should present to the user the information stored in the DAV:owner field of the lock, and the user will use that information to decide whether he/she really wants to steal that lock. So I agree that information about the user that took out the lock is required, but this info is available in the DAV:owner field. The only reason this information needs to be supplemented, is to let the client know whether or not the user will in fact be allowed to steal the lock (assuming that he/she wants to), and that is the info provided by the DAV:can-lock and DAV:can-unlock privileges. Cheers, Geoff -----Original Message----- From: Daniel Brotsky [mailto:dbrotsky@adobe.com] Sent: Monday, January 14, 2002 1:16 PM To: Stefan Eissing Cc: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER At 3:05 PM +0100 1/11/02, Stefan Eissing wrote: >I see what you mean. There could be an ACL server which just has >"group" principals and no principals with one-one relation to users >(well it could even skip user credentials and just have credentials >matching groups). > >As for identifying the owner of a lock this means one of the following: >a) the server has a "primary" principal and could report it as lock owner. > It may nevertheless choose not to do so, due to confidentiality reasons. >b) the server has no such thing and thus cannot report who owns a lock. > It only can tell if your credentials are sufficient to lock/unlock > a resource. But (b) misses the point of my requirement, which is that a client needs to be able to issue a request that says "am I the that obtained this lock"? The client is *not* asking an ACL question: can I unlock this resource; the client is asking a workflow question: would I be unlocking someone else's lock if I did unlock the resource? It's the workflow question that's at the heart of the requirement. So, Geoff, given ACL's (desirable) vagueness about "principals", and building on your language about "request credentials", can we alter the DAV spec language so that servers can return info about "is this request authorized with the same credentials as the lock request" and still be compatible with ACL? dan P.S. Another way of looking at this is to say: the ACL info provides a way of distinguishing between principals (i.e., they have different capabilities), but that way of distinguishing is not required to be fine-grained enough to support what I claim is the "workflow intuition" behind DAV locking: locks are held by a particular and are only allowed to be used (in the absence of ACL or other server admin magic) by that regardless of token. My requirement is that users be able to determine whether they are currently authenticating requests as the same as the request that locked the resource was. -d. -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Mon Jan 14 14:29:34 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14556 for ; Mon, 14 Jan 2002 14:29:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA20026; Mon, 14 Jan 2002 14:28:36 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 14:28:36 -0500 (EST) Resent-Message-Id: <200201141928.OAA20026@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA19990 for ; Mon, 14 Jan 2002 14:28:28 -0500 (EST) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA25574 for ; Mon, 14 Jan 2002 14:28:27 -0500 Received: from [216.36.111.249] (HELO moose) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.1) with SMTP id 16709970; Mon, 14 Jan 2002 11:25:58 -0800 From: "Lisa Dusseault" To: "Clemm, Geoff" , Date: Mon, 14 Jan 2002 11:25: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.2911.0) Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AE9B@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5786 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff said: > The client should never automatically reuse a lock taken out > by another client (irrespective of whether or not it was another > client with the same authentication credentials), but should only > steal another client's lock on explicit request by the user. Not even that liberal: the client should only *remove* another client's lock on explicit request by the user. The client should never reuse another client's lock. Ever. (The ambiguity may just be in the word steal - I'm not sure what you intend here Geoff) > So I agree that information about the user that took out the lock > is required, but this info is available in the DAV:owner field. No, this info is not necessarily available in the DAV:owner field. Because the client can submit this field, the client can submit bogus information, and it's not necessarily possible for the server to decide if the information is bogus. > The only reason this information needs to be supplemented, is to > let the client know whether or not the user will in fact be allowed > to steal the lock (assuming that he/she wants to), and that is the > info provided by the DAV:can-lock and DAV:can-unlock privileges. It's not necessarily an issue of privilege, it may be an issue of system policy. I'm not sure if using can-lock and can-unlock privileges addresses that. lisa From w3c-dist-auth-request@w3.org Mon Jan 14 15:09:58 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16646 for ; Mon, 14 Jan 2002 15:09:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26244; Mon, 14 Jan 2002 15:08:29 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 15:08:29 -0500 (EST) Resent-Message-Id: <200201142008.PAA26244@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA26204 for ; Mon, 14 Jan 2002 15:08:19 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA01666 for ; Mon, 14 Jan 2002 15:08:18 -0500 Received: (qmail 31518 invoked by uid 0); 14 Jan 2002 20:07:47 -0000 Received: from pd9535a6b.dip.t-dialin.net (HELO lisa) (217.83.90.107) by mail.gmx.net (mp012-rz3) with SMTP; 14 Jan 2002 20:07:47 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Clemm, Geoff" , Date: Mon, 14 Jan 2002 21:07:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5787 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, January 14, 2002 8:26 PM > To: Clemm, Geoff; w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > ... > > No, this info is not necessarily available in the DAV:owner > field. Because > the client can submit this field, the client can submit bogus information, > and it's not necessarily possible for the server to decide if the > information is bogus. Furthermore, there is no standard format for this information, but this would be needed for a interoperability. From w3c-dist-auth-request@w3.org Mon Jan 14 15:10:31 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16672 for ; Mon, 14 Jan 2002 15:10:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26432; Mon, 14 Jan 2002 15:09:31 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 15:09:31 -0500 (EST) Resent-Message-Id: <200201142009.PAA26432@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA26407 for ; Mon, 14 Jan 2002 15:09:20 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA01920 for ; Mon, 14 Jan 2002 15:09:20 -0500 Received: (qmail 4144 invoked by uid 0); 14 Jan 2002 20:08:48 -0000 Received: from pd9535a6b.dip.t-dialin.net (HELO lisa) (217.83.90.107) by mail.gmx.net (mp012-rz3) with SMTP; 14 Jan 2002 20:08:48 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Mon, 14 Jan 2002 21:08:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AE9B@SUS-MA1IT01> Importance: Normal Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5788 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, January 14, 2002 8:01 PM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > The client should never automatically reuse a lock taken out > by another client (irrespective of whether or not it was another > client with the same authentication credentials), but should only > steal another client's lock on explicit request by the user. > So the client should present to the user the information stored > in the DAV:owner field of the lock, and the user will use that > information to decide whether he/she really wants to steal that lock. *How* would a client present this information if the contents of DAV.owner is not specified at all? From w3c-dist-auth-request@w3.org Mon Jan 14 15:22:42 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17327 for ; Mon, 14 Jan 2002 15:22:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27253; Mon, 14 Jan 2002 15:21:51 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 15:21:51 -0500 (EST) Resent-Message-Id: <200201142021.PAA27253@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA27233 for ; Mon, 14 Jan 2002 15:21:40 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA03712 for ; Mon, 14 Jan 2002 15:21:40 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA160606; Mon, 14 Jan 2002 15:17:39 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0EKKZ7134866; Mon, 14 Jan 2002 15:20:35 -0500 To: Daniel Brotsky Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 14 Jan 2002 15:19:50 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 01/14/2002 03:20:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5789 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > In addition to Geoff's answer: > If you are an administrator trying to unlock a resource obtained by > someone else, you have to be able to figure out which resource to > unlock. You can't unlock an internal member of a collection that's > locked by a depth-inifinity lock without knowing which collection was > actually locked. CAN'T? > Then you can decide whether unlocking that is the > right thing to do. I think this is what Geoff was saying. He's saying it is probably irresponsible to unlock a set of resources without knowing what resources actually will become unlocked. But apparently before this sentence you are saying something different than Geoff. Please explain. From w3c-dist-auth-request@w3.org Mon Jan 14 16:24:53 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20019 for ; Mon, 14 Jan 2002 16:24:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA01944; Mon, 14 Jan 2002 16:23:31 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 16:23:31 -0500 (EST) Resent-Message-Id: <200201142123.QAA01944@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA01923 for ; Mon, 14 Jan 2002 16:23:20 -0500 (EST) Received: from bhh5.na.pg.com (bhh5.na.pg.com [192.44.184.129]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA13206 for ; Mon, 14 Jan 2002 16:23:20 -0500 From: hanna.ji@pg.com X-ExtMailInfo: bdc-notes041.na.pg.com [155.125.116.41] Received: from bdc-notes041.na.pg.com (bdc-notes041.na.pg.com [155.125.116.41]) by bhh5.na.pg.com (8.8.8/8.11.1/v1r36) with ESMTP id g0ELN8F02229; Mon, 14 Jan 2002 16:23:08 -0500 (EST) To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 14 Jan 2002 16:16:06 -0500 X-MIMETrack: Serialize by Router on BDC-NOTES041.NA.PG.COM/PGI(Release 5.0.3 (Intl)|21 March 2000) at 01/14/2002 04:23:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Windows XP Webdav redirector Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5790 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I opened an incident with Microsoft last fall around mapping a drive with XP using the mini-redirector. We were encountering issue #1 where we could not authenticate to the WebDAV server. A workaround for the issue was to choose an alternate user to log on as vs. the current user when mapping the drive. This appears to also affect using UNC pathing for the redirector. Jim Internet Mail Message Received from host: w3c-dist-auth@w3.org Sent To: by: cc: (bcc: Jim Hanna-JI/PGI) w3c-dist-auth-request@w3.org Subject: Windows XP Webdav redirector 01/14/2002 01:34 PM Hi, I've been trying to get the WebDAV "redirector" (UA WebDAV-MiniRedir/5.1.2600) in Windows XP to mount our WebDAV server. I've found three issues for which I have workarounds, however, I'm still not able to mount from my server. Problem #1: basic authentication seems to be broken if the redirector *prompts* for the credentials. If you supply them on the command line: "net use * URI password /user:username" it seems to work. Problem #2: given a URI like "http://server/a/b/c", the client tries OPTIONS and PROPFIND on "http://server/a" (which is wrong because this resource may not be WebDAV enabled). A similar (known!) problem exists in IE's "open as web folder", while mounting a web folder using network places behaves correctly. Problem #3: the URI may not contain a port number (even if it's 80!) All these problems lead to error message 67 ("network name not found") with absolutely no useful additional information. After working around these issues, I can get the redirector to issue a PROPFIND (Depth: 0) against by target URI (with correct Basic Authentication credentials), and my server is responding with 207 (MULTISTATUS) and a response body which seems to be just fine (and is accepted by the webfolder client). However, I'm still getting error #67. Did anybody else have a similar problem and knows what might be going wrong? Julian From w3c-dist-auth-request@w3.org Mon Jan 14 17:09:16 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21699 for ; Mon, 14 Jan 2002 17:09:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06380; Mon, 14 Jan 2002 17:08:25 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 17:08:25 -0500 (EST) Resent-Message-Id: <200201142208.RAA06380@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA06360 for ; Mon, 14 Jan 2002 17:08:20 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA20430 for ; Mon, 14 Jan 2002 17:08:20 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id SAA06469; Mon, 14 Jan 2002 18:08:08 -0500 Reply-To: From: "Matt Timmermans" To: "'Julian Reschke'" , Date: Mon, 14 Jan 2002 17:07:39 -0500 Message-ID: <000b01c19d47$e2937d00$d482a8c0@mt2k> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Subject: RE: Windows XP Webdav redirector Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5791 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > > Problem #1: basic authentication seems to be broken if the redirector > *prompts* for the credentials. If you supply them on the command line: > > "net use * URI password /user:username" > > it seems to work. I found that when you enter your credentials in the dialog, XP _always_ sends the username as user@domain. If you don't supply a domain, it'll add your machine's name or domain. (ick) From w3c-dist-auth-request@w3.org Mon Jan 14 21:48:04 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01067 for ; Mon, 14 Jan 2002 21:48:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA00118; Mon, 14 Jan 2002 21:46:26 -0500 (EST) Resent-Date: Mon, 14 Jan 2002 21:46:26 -0500 (EST) Resent-Message-Id: <200201150246.VAA00118@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA00076 for ; Mon, 14 Jan 2002 21:46:17 -0500 (EST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA16589 for ; Mon, 14 Jan 2002 21:46:17 -0500 Received: from northrelay02.pok.ibm.com ([9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA49556; Mon, 14 Jan 2002 13:17:25 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0EIJm7177530; Mon, 14 Jan 2002 13:19:48 -0500 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org, w3c-dist-auth-request@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 14 Jan 2002 13:16:30 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 01/14/2002 01:19:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5792 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << If a client does an UNLOCK, it would be good for it to know the set of resources that will be affected by the UNLOCK (especially if it is an adminstrative override of a lock held by some other principal). This would provide that information. >> It doesn't sound like a priority yet, but I have just put it on the issues list. From w3c-dist-auth-request@w3.org Tue Jan 15 10:47:41 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29625 for ; Tue, 15 Jan 2002 10:47:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA03134; Tue, 15 Jan 2002 10:45:10 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 10:45:10 -0500 (EST) Resent-Message-Id: <200201151545.KAA03134@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA03038 for ; Tue, 15 Jan 2002 10:44:46 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-074006.rational.com [130.213.74.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA04115 for ; Tue, 15 Jan 2002 10:44:45 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Tue, 15 Jan 2002 10:43:43 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 10:43:43 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E1A57@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 15 Jan 2002 10:43:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5795 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] Well, if the set of principals with the ability to unlock the resource is bigger than one, why not report all of them (or a subset whicht the server thinks makes sense)? That's exactly what the DAV:acl property would do (i.e. the ACEs for DAV:can-unlock). Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Jan 15 10:47:44 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29636 for ; Tue, 15 Jan 2002 10:47:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA03070; Tue, 15 Jan 2002 10:44:53 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 10:44:53 -0500 (EST) Resent-Message-Id: <200201151544.KAA03070@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA03014 for ; Tue, 15 Jan 2002 10:44:42 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-074006.rational.com [130.213.74.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA04079 for ; Tue, 15 Jan 2002 10:44:41 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Tue, 15 Jan 2002 10:43:39 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 10:43:39 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E1A54@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 15 Jan 2002 10:43:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5793 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Lisa Dusseault [mailto:lisa@xythos.com] Geoff said: > The client should never automatically reuse a lock taken out > by another client (irrespective of whether or not it was another > client with the same authentication credentials), but should only > steal another client's lock on explicit request by the user. Not even that liberal: the client should only *remove* another client's lock on explicit request by the user. The client should never reuse another client's lock. Ever. (The ambiguity may just be in the word steal - I'm not sure what you intend here Geoff) I completely agree with Lisa here. By "steal", I meant unlocking the old lock, and creating a new lock on the same resource. > So I agree that information about the user that took out the lock > is required, but this info is available in the DAV:owner field. No, this info is not necessarily available in the DAV:owner field. Because the client can submit this field, the client can submit bogus information, and it's not necessarily possible for the server to decide if the information is bogus. It doesn't matter what the server thinks ... the purpose of the DAV:owner field is to let a client know whether it is "his own" lock, and if not, how to contact the lock owner. In either case this is a client/client communication, not a client/server. For security reasons, if a client wishes/needs to submit "bogus" (or obscure) information, it should be allowed to do so, and not have these security wishes violated by the server. The only "harm" of this bogus information is that the user might not recognize "his own" lock (which should be the user's choice) or that another user might not be able to contact him (which also should be his choice). > The only reason this information needs to be supplemented, is to > let the client know whether or not the user will in fact be allowed > to steal the lock (assuming that he/she wants to), and that is the > info provided by the DAV:can-lock and DAV:can-unlock privileges. It's not necessarily an issue of privilege, it may be an issue of system policy. I'm not sure if using can-lock and can-unlock privileges addresses that. The DAV:can-lock and DAV:can-unlock address the system policy issues that I am aware of. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Jan 15 10:47:47 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29649 for ; Tue, 15 Jan 2002 10:47:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA03166; Tue, 15 Jan 2002 10:45:18 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 10:45:18 -0500 (EST) Resent-Message-Id: <200201151545.KAA03166@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA03051 for ; Tue, 15 Jan 2002 10:44:47 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-074006.rational.com [130.213.74.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA04121 for ; Tue, 15 Jan 2002 10:44:46 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Tue, 15 Jan 2002 10:43:41 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 10:43:41 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E1A56@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 15 Jan 2002 10:43:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5796 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > The client should never automatically reuse a lock taken out > by another client (irrespective of whether or not it was another > client with the same authentication credentials), but should only > steal another client's lock on explicit request by the user. > So the client should present to the user the information stored > in the DAV:owner field of the lock, and the user will use that > information to decide whether he/she really wants to steal that lock. *How* would a client present this information if the contents of DAV.owner is not specified at all? The same way it presents DAV:displayname and DAV:comment information: copying out the value of the field as a string, unless it recognizes something about the string (e.g. some nested XML or HTML), in which case it can massage the string first. If we want to develop some standards for the DAV:owner field format, that is fine with me. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Jan 15 10:48:31 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29696 for ; Tue, 15 Jan 2002 10:48:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA03097; Tue, 15 Jan 2002 10:44:59 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 10:44:59 -0500 (EST) Resent-Message-Id: <200201151544.KAA03097@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA03026 for ; Tue, 15 Jan 2002 10:44:44 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-074006.rational.com [130.213.74.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA04089 for ; Tue, 15 Jan 2002 10:44:43 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Tue, 15 Jan 2002 10:43:41 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 10:43:41 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E1A55@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 15 Jan 2002 10:43:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5794 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Developing a standard format for the DAV:owner field would be fine with me. This addresses the client/client interoperability problem without introducing the overhead and security hole that capturing and displaying a "principal" introduces. The ability to submit "bogus" information is a security feature, not a bug. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, January 14, 2002 8:26 PM > To: Clemm, Geoff; w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > ... > > No, this info is not necessarily available in the DAV:owner > field. Because > the client can submit this field, the client can submit bogus information, > and it's not necessarily possible for the server to decide if the > information is bogus. Furthermore, there is no standard format for this information, but this would be needed for a interoperability. From w3c-dist-auth-request@w3.org Tue Jan 15 10:53:10 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29984 for ; Tue, 15 Jan 2002 10:53:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA04313; Tue, 15 Jan 2002 10:51:47 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 10:51:47 -0500 (EST) Resent-Message-Id: <200201151551.KAA04313@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA04277 for ; Tue, 15 Jan 2002 10:51:37 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA05955 for ; Tue, 15 Jan 2002 10:51:37 -0500 Received: (qmail 18850 invoked by uid 0); 15 Jan 2002 15:51:06 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009-rz3) with SMTP; 15 Jan 2002 15:51:06 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Tue, 15 Jan 2002 16:51:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1056E1A57@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5797 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, January 15, 2002 4:44 PM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Well, if the set of principals with the ability to unlock the > resource is bigger than one, why not report all of them (or a > subset whicht the server thinks makes sense)? > > That's exactly what the DAV:acl property would do (i.e. > the ACEs for DAV:can-unlock). Yes, but we don't have a standard privilege for this, right? From w3c-dist-auth-request@w3.org Tue Jan 15 11:22:14 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01186 for ; Tue, 15 Jan 2002 11:22:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09189; Tue, 15 Jan 2002 11:17:41 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 11:17:41 -0500 (EST) Resent-Message-Id: <200201151617.LAA09189@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA09165 for ; Tue, 15 Jan 2002 11:17:29 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA13390 for ; Tue, 15 Jan 2002 11:17:29 -0500 Received: (qmail 14348 invoked by uid 0); 15 Jan 2002 16:16:58 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp012-rz3) with SMTP; 15 Jan 2002 16:16:58 -0000 From: "Julian Reschke" To: "Julian Reschke" , Date: Tue, 15 Jan 2002 17:16:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Windows XP Webdav redirector Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5798 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK, we finally fingured out the WebDAV redirector was refusing to connect: it *requires* that XML elements in the DAV: namespace use a prefix. This means, it won't recognize while will work. Sigh. It would be really great if Microsoft would start fixing the WebDAV support in their clients and servers. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Monday, January 14, 2002 7:34 PM > To: w3c-dist-auth@w3c.org > Subject: Windows XP Webdav redirector > > > Hi, > > I've been trying to get the WebDAV "redirector" (UA > WebDAV-MiniRedir/5.1.2600) in Windows XP to mount our WebDAV server. I've > found three issues for which I have workarounds, however, I'm > still not able > to mount from my server. > > Problem #1: basic authentication seems to be broken if the redirector > *prompts* for the credentials. If you supply them on the command line: > > "net use * URI password /user:username" > > it seems to work. > > Problem #2: given a URI like "http://server/a/b/c", the client > tries OPTIONS > and PROPFIND on "http://server/a" (which is wrong because this > resource may > not be WebDAV enabled). A similar (known!) problem exists in IE's "open as > web folder", while mounting a web folder using network places behaves > correctly. > > Problem #3: the URI may not contain a port number (even if it's 80!) > > All these problems lead to error message 67 ("network name not > found") with > absolutely no useful additional information. > > > After working around these issues, I can get the redirector to issue a > PROPFIND (Depth: 0) against by target URI (with correct Basic > Authentication > credentials), and my server is responding with 207 (MULTISTATUS) and a > response body which seems to be just fine (and is accepted by the > webfolder > client). However, I'm still getting error #67. > > Did anybody else have a similar problem and knows what might be > going wrong? > > Julian > From w3c-dist-auth-request@w3.org Tue Jan 15 12:07:53 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05411 for ; Tue, 15 Jan 2002 12:07:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA16116; Tue, 15 Jan 2002 12:02:19 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 12:02:19 -0500 (EST) Resent-Message-Id: <200201151702.MAA16116@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA16086 for ; Tue, 15 Jan 2002 12:02:07 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-074006.rational.com [130.213.74.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA27025 for ; Tue, 15 Jan 2002 12:02:06 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Tue, 15 Jan 2002 12:01:04 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 12:01:04 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AEA6@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 15 Jan 2002 12:01:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5799 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: No, we don't currently have standard locking privileges, but the proposal I support is to add them. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, January 15, 2002 10:51 AM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, January 15, 2002 4:44 PM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Well, if the set of principals with the ability to unlock the > resource is bigger than one, why not report all of them (or a > subset whicht the server thinks makes sense)? > > That's exactly what the DAV:acl property would do (i.e. > the ACEs for DAV:can-unlock). Yes, but we don't have a standard privilege for this, right? From w3c-dist-auth-request@w3.org Tue Jan 15 12:28:39 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06187 for ; Tue, 15 Jan 2002 12:28:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA19665; Tue, 15 Jan 2002 12:24:11 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 12:24:11 -0500 (EST) Resent-Message-Id: <200201151724.MAA19665@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA19645 for ; Tue, 15 Jan 2002 12:23:59 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-074006.rational.com [130.213.74.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA32346 for ; Tue, 15 Jan 2002 12:24:00 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Tue, 15 Jan 2002 12:22:58 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 12:22:58 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AEA8@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Tue, 15 Jan 2002 12:22:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5800 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Lisa Dusseault [mailto:lisa@xythos.com] > Personally, I'm going to guess they didn't pipeline requests, so > a batch mechanism was a must to get around deficiencies in their > protocol stack. There's potentially a little more to it than that. (1) Imagine a client selects a bunch of resources and drags to move them all to a different folder. A batch MOVE operation can do those in one transaction, so that the whole request fails if not all can be moved. This becomes rather more important if the client is actually using an API (MSDAIPP??) that offers large-scope operations, yet how can it guarantee that operation will work or won't work if it can only send it piecemeal to the server? We should carefully distinguish between BATCH for "pipelining" and BATCH for "transactions". Every server should be able to support a pipelined request, but only servers whose repository is inherently transactioned-based are likely to be able to support transactions. Note that the Bxxx methods supported by the Microsoft Exchange 2000 server are pipelining batch requests, not transactioning batch requests. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Jan 15 12:36:53 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06470 for ; Tue, 15 Jan 2002 12:36:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA21046; Tue, 15 Jan 2002 12:31:52 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 12:31:52 -0500 (EST) Resent-Message-Id: <200201151731.MAA21046@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA20995 for ; Tue, 15 Jan 2002 12:31:38 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-074006.rational.com [130.213.74.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01208 for ; Tue, 15 Jan 2002 12:31:38 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Tue, 15 Jan 2002 12:30:37 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 12:30:37 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AEA9@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Tue, 15 Jan 2002 12:30:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Interest in standardizing Batch methods? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5801 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It probably makes sense to include both, i.e. "better support for pipelining" and "transactions" I personally am more optimistic that we can agree on an interoperable way of improving pipelining than that we can agree on an interoperable way of doing transactions. Cheers, Geoff -----Original Message----- From: Daniel Brotsky [mailto:dbrotsky@adobe.com] Sent: Wednesday, January 09, 2002 6:46 PM To: Jim Whitehead Cc: WebDAV Subject: RE: Interest in standardizing Batch methods? At 9:57 AM -0800 1/9/02, Jim Whitehead wrote: > > That said, it's still not clear batch methods are so necessary they'd >> preempt other work we've got to do. > >I agree that other work, especially the revision of RFC 2518, has higher >priority than this. But, since we'll be revising our charter soon, I was >mostly interested to see if it should be added as a charter to-do item. > >- Jim I would say "yes" if you phrase it in terms of general transactionality, not batch operations in particular. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Tue Jan 15 14:51:41 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11278 for ; Tue, 15 Jan 2002 14:51:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA06178; Tue, 15 Jan 2002 14:43:37 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 14:43:37 -0500 (EST) Resent-Message-Id: <200201151943.OAA06178@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA06133 for ; Tue, 15 Jan 2002 14:43:30 -0500 (EST) Received: from hq-exgw1.filenet.com (Filenet-gw.filenet.com [198.3.8.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA25035; Tue, 15 Jan 2002 14:43:28 -0500 Received: by cm-exgw1.filenet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 11:42:57 -0800 Message-ID: From: "Babich, Alan" To: "'webdav'" Cc: "'DASL'" Date: Tue, 15 Jan 2002 11:42:56 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: DANGER!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5802 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: DANGER!! I received the e-mail below, because I am on the webdav and dasl mailing lists, as are you. If you received the e-mail below, DO NOT RESPOND!! Do not send you bank account number. It is the infamous Nigerian oil fraud trolling for victims. I won't take the time to explain how it works here. People who have been taken, and have gone over there to find out what happened to their money disappear. Alan Babich -----Original Message----- From: anthony aluga [mailto:anthony_aluga1@yahoo.com] Sent: Tuesday, January 15, 2002 12:44 AM To: anthony_aluga1@yahoo.com Subject: [www-webdav-dasl] Union Bank Of Nig. Plc Union House Marina Lagos State Nigeria. Request For Foreign Partner Dear Sir, I sincerely write to seek your co-operation and trust to enable my colleagues and I carry out an urgent business opportunity in my department. I work with the Union Bank of Nigeria PLC; currently I am the senior manager of bills and exchange at the foreign remittance department of my bank. I was the account officer to one Mr. Ali B. Ashraf who died along with his family on the 8th of November 1996 in an ADC Boeing 727 plane crash at Egirin River. All 141 passengers on board were feared dead. He left in his domiciliary account the total sum of $15.5million Fifteen million five hundred thousand USA Dollars. Since the management got the information of his death we have been expecting any of his relation or his next of kin to come up and claim his money. Unfortunately from the day of his death till the time of this letter none of his relation or friends has come up for the claim. The banking and financial law of Union bank of Nigeria Plc stipulates that if such fund remained unclaimed after a period of four (4) it will be transferred into the bank treasury as unclaimed bill. On this discovery sir, I and two other senior staffs now decided do business with you and release the money to you as the next of kin to Ali B. Ashraf for safety and subsequent disbursement. I will soon proceed for my retirement leave this year, and I personally do not want this fund to be transferred into the bank treasury as unclaimed bill. That is why I wanted the fund to be move out of the bank before I proceed on my retirement from the banking services by february 15th 2002. The need for a foreigner as next of kin in this project is occasioned by the fact that the customer Mr. Ali Ashraf was a foreigner and a Nigerian cannot stand as his next of kin or heir. We have agreed that 20% of the Fund would be for you as foreign partner; thereafter my colleague and I will visit your country for disbursement according to the percentages indicated. To enable the immediate transfer of the fund into your nominated account, you will first apply to the bank as the next of kin of the deceased, indicating your bank account number and location wherein the money will be remitted. Upon receipt of your acknowledgement indicating your interest, I will send to you the text of the application that you will send to the Union Bank authority for an approval to submit your claims. Send your reply through my direct and private email address (anthony_aluga@yahoo.com)or my hotmail account (anthony_aluga@hotmail.com) indicates your direct Fax and telephone numbers for effective communication that this transaction needs. Do not reply through the union bank email address because it's belonged to the senior staffs for public use. Please note that you are not to appear in person, as every thing regarding this project will be strictly on documentations and every banking documents needed for this transaction will be taken care of by my self. Looking forward to urgently hearing from you. Yours Faithfully Anthony Aluga. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From w3c-dist-auth-request@w3.org Tue Jan 15 15:52:02 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12991 for ; Tue, 15 Jan 2002 15:52:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13816; Tue, 15 Jan 2002 15:47:22 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 15:47:22 -0500 (EST) Resent-Message-Id: <200201152047.PAA13816@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA13792 for ; Tue, 15 Jan 2002 15:47:13 -0500 (EST) Received: from web9905.mail.yahoo.com (web9905.mail.yahoo.com [216.136.129.248]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA06720 for ; Tue, 15 Jan 2002 15:47:12 -0500 Message-ID: <20020115204708.18369.qmail@web9905.mail.yahoo.com> Received: from [63.214.191.66] by web9905.mail.yahoo.com via HTTP; Tue, 15 Jan 2002 12:47:08 PST Date: Tue, 15 Jan 2002 12:47:08 -0800 (PST) From: Michael Datuin To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Q] - making a Win32 app DAV-aware... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5803 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Thanks for the information. I've done a little more digging on the Web and found some tidbits of information. From an article on www.extremetech.com (http://www.extremetech.com/article/0,3396,apn%253D10%2526s%253D1027%2526a%253D2473%2526app%253D8%2526ap%253D9,00.asp), it appears that WinXP contains an integrated WebDAV redirector. According to the article, "you can open a file on the web with notepad, make changes, and if you have write permission, save it back...When you open a file from the Web, the file is copied locally to Internet Explorer's cache. Once you make your mchanges and close the file, Windows XP automatically puts the updated file back to the Web location." I tried to open a file in Notepad and save it (via the common save dialog) to the web folder (that I just created in My Network Places to point to an Apache server), and it doesn't work. So, you really can't get WebDAV "for free" using XP, right? How does the redirector actually work? Does it work similarly to WebDrive (www.webdrive.com), where a user can map a drive letter to a web folder (created in WinXP's My Network Places) or ftp site? Actually, this is all I really need. It would be ideal to just be able to let the user of my application enter in the common save dialog the following possible filenames for the file they want to save \\my_remote_machine\filename.txt http:\\my_remote_machine\filename.txt my_remote_machine_shortcut\filename.txt (where "shortcut" is a web folder) X:\filename.txt (where "X" is the drive letter mapped to the web folder) and have the file be saved on the remote machine. WebDrive is a great tool, but I don't like the idea of telling the users of my application that they have to go out and buy another piece of software to be able to save to a web folder. I thought the WebDAV redirector in WinXP is supposed to handle this. Anyone have any suggestions? I understand that writing a network redirector is a significant undertaking, something I currently do not have the opportunity (nor the time and resources) to work on. Without having to write my own version of WebDrive, is there any other solution without having to significantly modify my existing Win32 app code to support saving (or writing directly via file I/O calls) to a web server? Thanks! __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From w3c-dist-auth-request@w3.org Tue Jan 15 16:01:06 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13231 for ; Tue, 15 Jan 2002 16:01:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA14813; Tue, 15 Jan 2002 15:56:51 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 15:56:51 -0500 (EST) Resent-Message-Id: <200201152056.PAA14813@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA14691 for ; Tue, 15 Jan 2002 15:56:41 -0500 (EST) Received: from web9903.mail.yahoo.com (web9903.mail.yahoo.com [216.136.129.246]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA08027 for ; Tue, 15 Jan 2002 15:56:41 -0500 Message-ID: <20020115205640.99563.qmail@web9903.mail.yahoo.com> Received: from [63.214.191.66] by web9903.mail.yahoo.com via HTTP; Tue, 15 Jan 2002 12:56:40 PST Date: Tue, 15 Jan 2002 12:56:40 -0800 (PST) From: Michael Datuin To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Q] - making a Win32 app DAV-aware...(continued)... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5804 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I forgot to mention that I did take a look at the WebFolder Object on Microsoft's MSDN site. From what I've read about it and WebFolders collection, it isn't clear how I can take this MS FrontPage 2000 reference and incorporate it into my Win32 app (written in C/C++). The sample they provide (if you can even call it a sample) is given in VB. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From w3c-dist-auth-request@w3.org Tue Jan 15 16:05:12 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13357 for ; Tue, 15 Jan 2002 16:05:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15389; Tue, 15 Jan 2002 16:00:52 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 16:00:52 -0500 (EST) Resent-Message-Id: <200201152100.QAA15389@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA15363 for ; Tue, 15 Jan 2002 16:00:41 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA09351 for ; Tue, 15 Jan 2002 16:00:38 -0500 Received: (qmail 15084 invoked by uid 0); 15 Jan 2002 21:00:35 -0000 Received: from pd9535819.dip.t-dialin.net (HELO lisa) (217.83.88.25) by mail.gmx.net (mp006-rz3) with SMTP; 15 Jan 2002 21:00:35 -0000 From: "Julian Reschke" To: "Michael Datuin" , Date: Tue, 15 Jan 2002 22:00:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020115204708.18369.qmail@web9905.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: [Q] - making a Win32 app DAV-aware... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5805 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Michael Datuin > Sent: Tuesday, January 15, 2002 9:47 PM > To: w3c-dist-auth@w3.org > Subject: [Q] - making a Win32 app DAV-aware... > > > Thanks for the information. I've done a little more > digging on the Web and found some tidbits of > information. > > >From an article on www.extremetech.com > (http://www.extremetech.com/article/0,3396,apn%253D10%2526s%253D10 > 27%2526a%253D2473%2526app%253D8%2526ap%253D9,00.asp), > it appears that WinXP contains an > integrated WebDAV redirector. According to the > article, "you can open a file on the web with notepad, > > make changes, and if you have write permission, save > it back...When you open a file from the Web, the file > is copied locally to Internet Explorer's cache. Once > you make your mchanges and close the file, Windows XP > automatically puts the updated file back to the Web > location." > > I tried to open a file in Notepad and save it (via the > common save dialog) to the web folder (that I just > created in My Network Places to point to an Apache > server), and it doesn't work. So, you really can't > get WebDAV "for free" using XP, right? Yes, you can. Problem is, there are no less then four different Microsoft WebDAV clients: - web folders - web folders as updated by the Sharepoint client software - the libraries used by Office - the XP redirector All have different kinds of known bugs, and haven't been updated for a long time (except obviously for the XP stuff). The XP WebDAV redirector is not available from "network places", nor from IE. You'll have to use the command line tool "net", for instance: net use * URI passwrd /user:username > How does the redirector actually work? Does it work > similarly to WebDrive (www.webdrive.com), where a user > can map a drive letter to a web folder (created in > WinXP's My Network Places) or ftp site? Yes. Hope this helps, Julian From w3c-dist-auth-request@w3.org Tue Jan 15 17:27:08 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15125 for ; Tue, 15 Jan 2002 17:27:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA22305; Tue, 15 Jan 2002 17:25:42 -0500 (EST) Resent-Date: Tue, 15 Jan 2002 17:25:42 -0500 (EST) Resent-Message-Id: <200201152225.RAA22305@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA22285 for ; Tue, 15 Jan 2002 17:25:38 -0500 (EST) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA22762 for ; Tue, 15 Jan 2002 17:25:38 -0500 Received: from [216.36.111.249] (HELO moose) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.1) with SMTP id 16061235; Tue, 15 Jan 2002 14:24:12 -0800 From: "Lisa Dusseault" To: "Clemm, Geoff" , Date: Tue, 15 Jan 2002 14:23:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1056E1A55@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5806 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As you point out, the DAV:owner field affects client/client interoperability. There exist shipping clients that have established interoperability based on specific syntax and information in the DAV:owner field. Therefore, we cannot now develop a standard format for that field without breaking those clients. Since DAV:owner was standardized as free text, we can't restrict it further. We can however create a new field that when supported uses a standard syntax. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, January 15, 2002 7:44 AM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > Developing a standard format for the DAV:owner field would > be fine with me. This addresses the client/client interoperability > problem without introducing the overhead and security hole > that capturing and displaying a "principal" introduces. > The ability to submit "bogus" information is a security feature, > not a bug. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Monday, January 14, 2002 8:26 PM > > To: Clemm, Geoff; w3c-dist-auth@w3c.org > > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > ... > > > > No, this info is not necessarily available in the DAV:owner > > field. Because > > the client can submit this field, the client can submit bogus > information, > > and it's not necessarily possible for the server to decide if the > > information is bogus. > > Furthermore, there is no standard format for this information, but this > would be needed for a interoperability. From w3c-dist-auth-request@w3.org Wed Jan 16 13:37:43 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17193 for ; Wed, 16 Jan 2002 13:37:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06435; Wed, 16 Jan 2002 13:35:48 -0500 (EST) Resent-Date: Wed, 16 Jan 2002 13:35:48 -0500 (EST) Resent-Message-Id: <200201161835.NAA06435@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA06407 for ; Wed, 16 Jan 2002 13:35:36 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA17121 for ; Wed, 16 Jan 2002 13:35:35 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA17042 for ; Wed, 16 Jan 2002 10:35:39 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 16 Jan 2002 10:34:32 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: Help on Dav Explorer Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5807 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added adil.serbouti@atosorigin.com to the accept2 list. - Jim -----Original Message----- From: Serbouti, Adil [mailto:adil.serbouti@atosorigin.com] Sent: Wednesday, January 16, 2002 8:54 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Help on Dav Explorer Hello, I'm learning WebDav, I downloaded dav explorer and everything went fine, I'm using my IIS as WebDav server (on my local machine). I connect to the server (localhost). But when I try to create a collection (file=>create collection) i get a message: 403 forbidden. Somebody can help. Many thanks in advance. From w3c-dist-auth-request@w3.org Wed Jan 16 15:19:39 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20015 for ; Wed, 16 Jan 2002 15:19:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA24883; Wed, 16 Jan 2002 15:18:43 -0500 (EST) Resent-Date: Wed, 16 Jan 2002 15:18:43 -0500 (EST) Resent-Message-Id: <200201162018.PAA24883@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA24852 for ; Wed, 16 Jan 2002 15:18:34 -0500 (EST) Received: from smtp-server6.tampabay.rr.com (smtp-server6.tampabay.rr.com [65.32.1.43]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA07035 for ; Wed, 16 Jan 2002 15:18:34 -0500 Received: from redfish (128bus78.tampabay.rr.com [24.94.128.78]) by smtp-server6.tampabay.rr.com (8.11.2/8.11.2) with SMTP id g0GKIV326086 for ; Wed, 16 Jan 2002 15:18:31 -0500 (EST) From: "Steve Lomicka" To: Date: Wed, 16 Jan 2002 15:18:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C19EA1.13EAE910" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: DASL client Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5808 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C19EA1.13EAE910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sorry to post in the WEBDAV v. DASL group but there is more activity, less spam here. We are building a WEBDAV front-end to our ERM repository and supporting both browse and search functionality. We can use a plethora of clients for testing the browse portion; IE, explorer DAV-Explorer, etc. We have not found a good DASL client (or a bad one for that matter). Does anyone know of a good, free or pay per view, DASL client? We would prefer to concentrate on our server rather than write a DASL search client. Thank you all in advance, Steve ------=_NextPart_000_0007_01C19EA1.13EAE910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sorry = to post in the=20 WEBDAV v. DASL group but there is more activity, less spam=20 here.
 
We are = building a=20 WEBDAV front-end to our ERM repository and supporting both browse and = search=20 functionality.  We can use a plethora of clients for testing the = browse=20 portion; IE, explorer DAV-Explorer, etc.  We have not found a good = DASL=20 client (or a bad one for that matter).  Does anyone know of a good, = free or=20 pay per view, DASL client?  We would prefer to concentrate on=20 our server rather than write a DASL search=20 client.
 
Thank = you all in=20 advance,
Steve
------=_NextPart_000_0007_01C19EA1.13EAE910-- From w3c-dist-auth-request@w3.org Thu Jan 17 17:07:23 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14330 for ; Thu, 17 Jan 2002 17:07:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06248; Thu, 17 Jan 2002 17:03:50 -0500 (EST) Resent-Date: Thu, 17 Jan 2002 17:03:50 -0500 (EST) Resent-Message-Id: <200201172203.RAA06248@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA06228 for ; Thu, 17 Jan 2002 17:03:38 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA10134 for ; Thu, 17 Jan 2002 17:03:38 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id OAA03561; Thu, 17 Jan 2002 14:03:38 -0800 (PST) From: "Jim Whitehead" To: "Steve Lomicka" , Date: Thu, 17 Jan 2002 14:02:30 -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.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: DASL client Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5809 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit To the best of my knowledge, there are no publically available DASL clients, or DASL client libraries. It certainly would be nice if some did become available... - Jim -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Steve Lomicka Sent: Wednesday, January 16, 2002 12:19 PM To: w3c-dist-auth@w3.org Subject: DASL client Sorry to post in the WEBDAV v. DASL group but there is more activity, less spam here. We are building a WEBDAV front-end to our ERM repository and supporting both browse and search functionality. We can use a plethora of clients for testing the browse portion; IE, explorer DAV-Explorer, etc. We have not found a good DASL client (or a bad one for that matter). Does anyone know of a good, free or pay per view, DASL client? We would prefer to concentrate on our server rather than write a DASL search client. Thank you all in advance, Steve From w3c-dist-auth-request@w3.org Fri Jan 18 04:30:50 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04792 for ; Fri, 18 Jan 2002 04:30:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA03184; Fri, 18 Jan 2002 04:28:43 -0500 (EST) Resent-Date: Fri, 18 Jan 2002 04:28:43 -0500 (EST) Resent-Message-Id: <200201180928.EAA03184@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA03142 for ; Fri, 18 Jan 2002 04:28:31 -0500 (EST) Received: from kebi.com (mail15.kebi.com [210.116.116.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA07924 for ; Fri, 18 Jan 2002 04:28:30 -0500 Received: (from kebi@localhost) by kebi.com (8.11.0/8.11.0) id g0I9SGA15373 for w3c-dist-auth@w3.org; Fri, 18 Jan 2002 18:28:16 +0900 (KST) Date: Fri, 18 Jan 2002 18:28:16 +0900 (KST) Message-Id: <200201180928.g0I9SGA15373@kebi.com> From: "Sung Kim" User-Host: 210.116.116.51 Reply-To: hunkim@kebi.com In-Reply-To: hunkim@kebi.com To: steve.lomicka@maximal.com Cc: w3c-dist-auth@w3.org X-Mailer: KEBI WWW-MAIL [version 1.0] X-Mail-Id: hunkim.153661011346096231 X-Priority: 3 MIME-Version: 1.0 Content-type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Subject: RE:DASL client Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5810 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit We have a plan to implement a DASL server and client. I just heard there is no DASL client , and one server(sharemation) so far. If you have interest about implementing DASL server and client, please visit and join our group. http://dasl.sf.net >Sorry to post in the WEBDAV v. DASL group but there is more activity, less >spam here. > >We are building a WEBDAV front-end to our ERM repository and supporting both >browse and search functionality. We can use a plethora of clients for >testing the browse portion; IE, explorer DAV-Explorer, etc. We have not >found a good DASL client (or a bad one for that matter). Does anyone know >of a good, free or pay per view, DASL client? We would prefer to >concentrate on our server rather than write a DASL search client. > >Thank you all in advance, >Steve > -- "Dreams become reality!" hunkim@kebi.com Free webmail hosting service MNARA.NET -- This e-mail was sent by FREE KEBI Mail at http://kebi.com/-- From w3c-dist-auth-request@w3.org Fri Jan 18 06:08:50 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06295 for ; Fri, 18 Jan 2002 06:08:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA15694; Fri, 18 Jan 2002 06:06:16 -0500 (EST) Resent-Date: Fri, 18 Jan 2002 06:06:16 -0500 (EST) Resent-Message-Id: <200201181106.GAA15694@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA15674 for ; Fri, 18 Jan 2002 06:06:08 -0500 (EST) Received: from hotmail.com (f61.pav1.hotmail.com [64.4.31.61]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA22108 for ; Fri, 18 Jan 2002 06:06:08 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Jan 2002 03:05:37 -0800 Received: from 203.197.119.102 by pv1fd.pav1.hotmail.msn.com with HTTP; Fri, 18 Jan 2002 11:05:35 GMT X-Originating-IP: [203.197.119.102] From: "Soumya Dasgupta" To: ejw@cse.ucsc.edu, w3c-dist-auth@w3.org Date: Fri, 18 Jan 2002 16:35:35 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jan 2002 11:05:37.0309 (UTC) FILETIME=[0EE7FCD0:01C1A010] Subject: Slide Project Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5811 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi All, I am working with the slide project and facing a few problems.I am running the command line client Slide.I am being able to connect to the WebDav server deployed in tomcat.The get operation from the server is also fine i.e I can download resources from the server.But when I am trying to upload a file to the server an authorization error message is coming.The entire log is given below. F:\jakarta-slide-1.0.16\build\client\classes>java org.apache.webdav.cmd.Slide [ Slide ] $ open Enter http URL: http://localhost:8080/ [LOCALHOST] / $ put [LOCALHOST] / $ put joy.txt Uploading 'joy.txt' to '/joy.txt': failed. Forbidden (403) [LOCALHOST] / $ --------------------------- My questions are 1)From which configuration file in the webdav server can I find set of user lists their passwords and their permissions to resources.Is it tomcat-user.xml? 2)What is the default login to the webdav server i.e. the login with which I am conecting in this case.Is it guest? 3)How do I connect to the webdav server with a particular userid password from this particular command line client. Regards Soumya. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From w3c-dist-auth-request@w3.org Fri Jan 18 14:07:49 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23828 for ; Fri, 18 Jan 2002 14:07:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA27004; Fri, 18 Jan 2002 14:00:41 -0500 (EST) Resent-Date: Fri, 18 Jan 2002 14:00:41 -0500 (EST) Resent-Message-Id: <200201181900.OAA27004@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA26924 for ; Fri, 18 Jan 2002 14:00:30 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA10508 for ; Fri, 18 Jan 2002 14:00:30 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA326874; Fri, 18 Jan 2002 13:51:56 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0IIsuA213414; Fri, 18 Jan 2002 13:54:56 -0500 To: Daniel Brotsky , w3c-dist-auth@w3c.org, "Lisa Dusseault" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 18 Jan 2002 13:35:15 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 01/18/2002 01:54:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5812 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It sounds like we've concluded that we can't reuse the lockowner field because we've already specified that it's free text. Do we still have the requirement mentioned at... http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html says... regarding identifying the owner of a lock? If so, now that we've had some discussion on this topic, can someone provide an improved definition of the requirement? And a proposal? Dan? Lisa? Geoff? Julian? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Jan 18 14:32:18 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24324 for ; Fri, 18 Jan 2002 14:32:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA02420; Fri, 18 Jan 2002 14:29:26 -0500 (EST) Resent-Date: Fri, 18 Jan 2002 14:29:26 -0500 (EST) Resent-Message-Id: <200201181929.OAA02420@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA02400 for ; Fri, 18 Jan 2002 14:29:21 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-084155.rational.com [130.213.84.155]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA15358 for ; Fri, 18 Jan 2002 14:29:21 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Fri, 18 Jan 2002 14:28:18 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 14:28:18 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AEC8@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 18 Jan 2002 14:28:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5813 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I would describe our conclusion as: We need to define a new field, say DAV:lockowner, that is specified in a LOCK request, and that takes an XML value. We will define some standard elements for that value. We should then deprecate the use of the DAV:owner field, as a field that contains non-interoperable data about the lock owner. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Friday, January 18, 2002 1:35 PM To: Daniel Brotsky; w3c-dist-auth@w3c.org; Lisa Dusseault Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER It sounds like we've concluded that we can't reuse the lockowner field because we've already specified that it's free text. Do we still have the requirement mentioned at... http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html says... regarding identifying the owner of a lock? If so, now that we've had some discussion on this topic, can someone provide an improved definition of the requirement? And a proposal? Dan? Lisa? Geoff? Julian? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Jan 18 14:45:57 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24712 for ; Fri, 18 Jan 2002 14:45:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA04404; Fri, 18 Jan 2002 14:43:31 -0500 (EST) Resent-Date: Fri, 18 Jan 2002 14:43:31 -0500 (EST) Resent-Message-Id: <200201181943.OAA04404@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA04381 for ; Fri, 18 Jan 2002 14:43:23 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-084155.rational.com [130.213.84.155]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA17322 for ; Fri, 18 Jan 2002 14:43:22 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Fri, 18 Jan 2002 14:42:17 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 14:42:17 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AECA@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 18 Jan 2002 14:42:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5814 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: And of course: The value specified in the DAV:lockowner field of a LOCK request is available in the DAV:lockowner field in the DAV:lockdiscovery property. Cheers, Geoff -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Friday, January 18, 2002 2:28 PM To: w3c-dist-auth@w3c.org Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER I would describe our conclusion as: We need to define a new field, say DAV:lockowner, that is specified in a LOCK request, and that takes an XML value. We will define some standard elements for that value. We should then deprecate the use of the DAV:owner field, as a field that contains non-interoperable data about the lock owner. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Friday, January 18, 2002 1:35 PM To: Daniel Brotsky; w3c-dist-auth@w3c.org; Lisa Dusseault Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER It sounds like we've concluded that we can't reuse the lockowner field because we've already specified that it's free text. Do we still have the requirement mentioned at... http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html says... regarding identifying the owner of a lock? If so, now that we've had some discussion on this topic, can someone provide an improved definition of the requirement? And a proposal? Dan? Lisa? Geoff? Julian? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Jan 18 20:33:40 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02480 for ; Fri, 18 Jan 2002 20:33:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA04800; Fri, 18 Jan 2002 20:32:32 -0500 (EST) Resent-Date: Fri, 18 Jan 2002 20:32:32 -0500 (EST) Resent-Message-Id: <200201190132.UAA04800@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA04776 for ; Fri, 18 Jan 2002 20:32:24 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA06071 for ; Fri, 18 Jan 2002 20:32:24 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA25652 for ; Fri, 18 Jan 2002 17:32:30 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 18 Jan 2002 17:31: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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: Wikified WebDAV documentation site Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5815 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I encourage you to make contributions to the WebDAV Wiki Web. The basic idea is that anyone can make contributions to a Wiki -- the access permissions are very open. - Jim -----Original Message----- From: dav-announce-admin@lyra.org [mailto:dav-announce-admin@lyra.org]On Behalf Of saqib ali Sent: Tuesday, January 15, 2002 8:58 PM To: dav-announce@lyra.org Subject: [dav-announce] Wikified WebDAV documentation site Hi, I have a create a Wiki site for creating some WebDAV documentation under "GNU Free Documentation License". Here is URL for the documentation site http://www.stonebeat.org Wiki will enable anyone to contribute to this site, but just clicking the "Edit" button at the bottom of any web page. The user can then modify the content of the document/webpage right from his/her browser. I would like to ask everyone to make contribution to the this documentation project - Add more content to existing document and/or create new documents. Again the URL for the WebDAV documentation site is: http://www.stonebeat.org Thanks Saqib Ali _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ dav-announce maillist - dav-announce@lyra.org http://dav.lyra.org/mailman/listinfo/dav-announce From w3c-dist-auth-request@w3.org Sat Jan 19 13:40:25 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21283 for ; Sat, 19 Jan 2002 13:40:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07058; Sat, 19 Jan 2002 13:36:34 -0500 (EST) Resent-Date: Sat, 19 Jan 2002 13:36:34 -0500 (EST) Resent-Message-Id: <200201191836.NAA07058@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA07038 for ; Sat, 19 Jan 2002 13:36:25 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA01490 for ; Sat, 19 Jan 2002 13:36:24 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA328890; Sat, 19 Jan 2002 13:32:16 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0JIZ6W212082; Sat, 19 Jan 2002 13:35:06 -0500 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sat, 19 Jan 2002 13:34:49 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 01/19/2002 01:35:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5816 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Sounds very clear Geoff. Can we explain why we need this? With the answer to that in mind, can we also say what elements we plan to standardize within DAV:lockowner? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat Jan 19 15:42:12 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22712 for ; Sat, 19 Jan 2002 15:42:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA11973; Sat, 19 Jan 2002 15:39:13 -0500 (EST) Resent-Date: Sat, 19 Jan 2002 15:39:13 -0500 (EST) Resent-Message-Id: <200201192039.PAA11973@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA11953 for ; Sat, 19 Jan 2002 15:39:06 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA10941 for ; Sat, 19 Jan 2002 15:39:05 -0500 Received: (qmail 3640 invoked by uid 0); 19 Jan 2002 20:38:33 -0000 Received: from pd9e51289.dip.t-dialin.net (HELO lisa) (217.229.18.137) by mail.gmx.net (mp001-rz3) with SMTP; 19 Jan 2002 20:38:33 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Sat, 19 Jan 2002 21:38:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AEC8@SUS-MA1IT01> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5817 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sounds good. I think we should also consider defining standard LOCK privileges. Here's a proposal for DAV:lockowner (I take the freedom to rename it): EMail Work Phone DTD fragment: > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, January 18, 2002 8:28 PM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > I would describe our conclusion as: > > We need to define a new field, say DAV:lockowner, that is specified > in a LOCK request, and that takes an XML value. We will define > some standard elements for that value. > > We should then deprecate the use of the DAV:owner field, as a field > that contains non-interoperable data about the lock owner. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Friday, January 18, 2002 1:35 PM > To: Daniel Brotsky; w3c-dist-auth@w3c.org; Lisa Dusseault > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > It sounds like we've concluded that we can't reuse the lockowner field > because we've already specified that it's free text. > > Do we still have the requirement mentioned at... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html > says... > > regarding identifying the owner of a lock? If so, now that we've had some > discussion on this topic, can someone provide an improved > definition of the > requirement? And a proposal? Dan? Lisa? Geoff? Julian? > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > From w3c-dist-auth-request@w3.org Mon Jan 21 15:02:10 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22177 for ; Mon, 21 Jan 2002 15:02:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA20729; Mon, 21 Jan 2002 14:59:40 -0500 (EST) Resent-Date: Mon, 21 Jan 2002 14:59:40 -0500 (EST) Resent-Message-Id: <200201211959.OAA20729@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA20694 for ; Mon, 21 Jan 2002 14:59:31 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA18746 for ; Mon, 21 Jan 2002 14:59:31 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA16320 for ; Mon, 21 Jan 2002 11:59:33 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 21 Jan 2002 11:58:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: Searching folders with WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5818 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caugh by the spam filter. - Jim -----Original Message----- From: Lisa Horton [mailto:lhorton@agtrax.com] Sent: Monday, January 21, 2002 8:37 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Searching folders with WebDAV I hope someone can help me with 2 problems I am having with WebDAV. I am developing a web page that shows public folder data from our Exchange Server such as calendar data and contact data. We access our Exchange Server through our web server using URLs. I have had much success using WebDAV, but have hit a "brick wall" on 2 items which are listed below with code. 1) I am trying to perform a SEARCH on a public folder using SQL/XML/WebDAV and I am receiving no response. CODE: dim objXML, strR, strURL, docXML, sReq Set objXML = CreateObject("Microsoft.XMLHTTP") strURL = "http://mail.agtrax.com/public/AgTrax/web%20Calendar/" objXML.open "SEARCH", strURL, False, webExchgUserName, webExchgPassword sReq="" sReq= sReq & "" sReq= sReq & "Select 'urn:schemas:calendar:dtstart', " sReq= sReq & "'urn:schemas:calendar:location', " sReq= sReq & "'urn:schemas:calendar:dtend', " sReq= sReq & "'urn:schemas:calendar:alldayevent'" sReq= sReq & " FROM Scope('SHALLOW TRAVERSAL OF '" & strURL & "'')" sReq= sReq & " WHERE NOT 'urn:schemas:calendar:instancetype' = 1" sReq= sReq & " AND 'DAV:contentclass' = 'urn:content-classes:appointment'" sReq= sReq & " AND 'urn:schemas:calendar:dtend' > '2002-02-01T01:00:00.000Z'" sReq= sReq & " AND 'urn:schemas:calendar:dtstart' < '2002-02-28T01:00:00.000Z'" sReq= sReq & " ORDER BY 'urn:schemas:calendar:dtstart' DESC" sReq= sReq & "" sReq= sReq & "" objXML.setrequestheader "Translate", "f" objXML.setRequestHeader "Content-type:", "text/xml" objXML.setRequestHeader "Host:", "mail.agtrax.com" objXML.setRequestHeader "Depth", "1" objXML.Send (sReq) Set docXML = objXML.responseXML Dim objNodeAppt, i dim objNode Set objNodeAppt = docXML.getElementsByTagName("*") For i = 0 TO (objNodeAppt.length -1) Set objNode = objNodeAppt.nextNode Response.Write("" & objNode.NamespaceURI & " " & objNode.NodeName & " - ") Response.Write(objNode.text & "
") Next 2) I am trying to create a contact folder (in Exchange)using MKCOL and I am receiving the Status Code 403 (Forbidden). Is this just an issue with permissions or am I using the wrong method to create a folder? The code is below: CODE: dim objXML, strR, docXML Set objXML = CreateObject("Microsoft.XMLHTTP") strURL = "http://mail.agtrax.com/public/Agtrax/Test Folder" objXML.open "MKCOL", strURL, False, webExchgUserName, webExchgPassword strR = "" strR = strR & "" strR = strR & "" strR = strR & "Test Folder" strR = strR & "" strR = strR & "" objXML.setRequestHeader "Content-type:", "text/xml" objXML.setRequestHeader "Host:", "mail.agtrax.com" objXML.Send (strR) Set docXML = objXML.responseXML Dim objNodeAppt, i dim objNode Set objNodeAppt = docXML.getElementsByTagName("*") For i = 0 TO (objNodeAppt.length -1) Set objNode = objNodeAppt.nextNode Response.Write("" & objNode.NamespaceURI & " " & objNode.NodeName & " - ") Response.Write(objNode.text & "
") Next Thanks for your help, Lisa Horton AgTrax Technologies lhorton@agtrax.com From w3c-dist-auth-request@w3.org Mon Jan 21 15:02:19 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22199 for ; Mon, 21 Jan 2002 15:02:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA20911; Mon, 21 Jan 2002 15:00:45 -0500 (EST) Resent-Date: Mon, 21 Jan 2002 15:00:45 -0500 (EST) Resent-Message-Id: <200201212000.PAA20911@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA20879 for ; Mon, 21 Jan 2002 15:00:36 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA18925 for ; Mon, 21 Jan 2002 15:00:35 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA16470; Mon, 21 Jan 2002 12:00:39 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Cc: Date: Mon, 21 Jan 2002 11:59:29 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: re: [dav-dev] re: ms ie/office/web folder behaviors with webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5819 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter on the w3c-dist-auth@w3.org list. I'm cc'ing dav-dev, since this message is in response to a message originally posted there. - Jim -----Original Message----- From: Mitchell Robertson [mailto:mitchell@markinson.com.au] Sent: Sunday, January 20, 2002 6:30 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] re: [dav-dev] re: ms ie/office/web folder behaviors with webdav Perhaps there is a *.ini file somewhere on the clients system that can be edited (using VBscript or AciveX controls) that stores these settings. If so, upon loading your page, the user's settings will be changed so that when he opens the *.doc file, Microsoft Word will launch independantly. I'm pretty sure that when the user changes settings in windows or any other program for that matter, *.exe files cannot be writen to. In other words, settings are probably stored in a non-compiled (text) file that can be opened and edited. Please let me know what you think. From w3c-dist-auth-request@w3.org Mon Jan 21 16:51:28 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26026 for ; Mon, 21 Jan 2002 16:51:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA27874; Mon, 21 Jan 2002 16:50:23 -0500 (EST) Resent-Date: Mon, 21 Jan 2002 16:50:23 -0500 (EST) Resent-Message-Id: <200201212150.QAA27874@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA27854 for ; Mon, 21 Jan 2002 16:50:18 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA02735 for ; Mon, 21 Jan 2002 16:50:18 -0500 Received: (qmail 1396 invoked by uid 0); 21 Jan 2002 21:49:46 -0000 Received: from p508250b6.dip.t-dialin.net (HELO lisa) (80.130.80.182) by mail.gmx.net (mp008-rz3) with SMTP; 21 Jan 2002 21:49:46 -0000 From: "Julian Reschke" To: "WebDAV" Date: Mon, 21 Jan 2002 22:49:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: Searching folders with WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5820 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Lisa Horton [mailto:lhorton@agtrax.com] > Sent: Monday, January 21, 2002 8:37 AM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] Searching folders with WebDAV > > > I hope someone can help me with 2 problems I am having with WebDAV. I am > developing a web page that shows public folder data from our > Exchange Server > such as calendar data and contact data. We access our Exchange Server > through our web server using URLs. I have had much success using WebDAV, > but have hit a "brick wall" on 2 items which are listed below with code. > > 1) I am trying to perform a SEARCH on a public folder using > SQL/XML/WebDAV > and I am receiving no response. > > CODE: > dim objXML, strR, strURL, docXML, sReq > Set objXML = CreateObject("Microsoft.XMLHTTP") > strURL = "http://mail.agtrax.com/public/AgTrax/web%20Calendar/" > objXML.open "SEARCH", strURL, False, webExchgUserName, > webExchgPassword > > sReq="" > sReq= sReq & "" > sReq= sReq & "Select 'urn:schemas:calendar:dtstart', " > sReq= sReq & "'urn:schemas:calendar:location', " > sReq= sReq & "'urn:schemas:calendar:dtend', " > sReq= sReq & "'urn:schemas:calendar:alldayevent'" > sReq= sReq & " FROM Scope('SHALLOW TRAVERSAL OF '" & strURL & "'')" > sReq= sReq & " WHERE NOT 'urn:schemas:calendar:instancetype' = 1" > sReq= sReq & " AND 'DAV:contentclass' = > 'urn:content-classes:appointment'" > sReq= sReq & " AND 'urn:schemas:calendar:dtend' > > '2002-02-01T01:00:00.000Z'" > sReq= sReq & " AND 'urn:schemas:calendar:dtstart' < > '2002-02-28T01:00:00.000Z'" > sReq= sReq & " ORDER BY 'urn:schemas:calendar:dtstart' DESC" > sReq= sReq & "" > sReq= sReq & "" > objXML.setrequestheader "Translate", "f" > objXML.setRequestHeader "Content-type:", "text/xml" > objXML.setRequestHeader "Host:", "mail.agtrax.com" > objXML.setRequestHeader "Depth", "1" > > objXML.Send (sReq) > Set docXML = objXML.responseXML > > Dim objNodeAppt, i > dim objNode > Set objNodeAppt = docXML.getElementsByTagName("*") > For i = 0 TO (objNodeAppt.length -1) > Set objNode = objNodeAppt.nextNode > Response.Write("" & objNode.NamespaceURI & " " & > objNode.NodeName > & " - ") > Response.Write(objNode.text & "
") > Next What is the response code you're getting. And what exactly do you get as reply? (BTW: the "SQL" search grammar is something proprietay to Microsoft). > 2) I am trying to create a contact folder (in Exchange)using > MKCOL and I am > receiving the Status Code 403 (Forbidden). Is this just an issue with > permissions or am I using the wrong method to create a folder? > The code is > below: You can't use MKCOL with a request body. Try again without. From w3c-dist-auth-request@w3.org Mon Jan 21 19:30:35 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28906 for ; Mon, 21 Jan 2002 19:30:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA07780; Mon, 21 Jan 2002 19:29:11 -0500 (EST) Resent-Date: Mon, 21 Jan 2002 19:29:11 -0500 (EST) Resent-Message-Id: <200201220029.TAA07780@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA07760 for ; Mon, 21 Jan 2002 19:29:06 -0500 (EST) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA20892 for ; Mon, 21 Jan 2002 19:29:07 -0500 Received: from [216.36.111.249] (HELO moose) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.2) with SMTP id 17356590; Mon, 21 Jan 2002 16:27:03 -0800 From: "Lisa Dusseault" To: "Julian Reschke" , "WebDAV" Date: Mon, 21 Jan 2002 16:26:53 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Searching folders with WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5821 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > 2) I am trying to create a contact folder (in Exchange)using > > MKCOL and I am > > receiving the Status Code 403 (Forbidden). Is this just an issue with > > permissions or am I using the wrong method to create a folder? > > The code is > > below: > > You can't use MKCOL with a request body. Try again without. > Actually, I believe some Microsoft servers do support MKCOL with a body. However, this is a non-standard extension of MKCOL, not described in RFC2518 or any other document submitted to the working group or the IETF as far as I know. Thus I suspect this working group can't be of much assistance in this matter. Lisa From w3c-dist-auth-request@w3.org Mon Jan 21 20:04:13 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29354 for ; Mon, 21 Jan 2002 20:04:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA10838; Mon, 21 Jan 2002 20:01:48 -0500 (EST) Resent-Date: Mon, 21 Jan 2002 20:01:48 -0500 (EST) Resent-Message-Id: <200201220101.UAA10838@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA10812 for ; Mon, 21 Jan 2002 20:01:41 -0500 (EST) Received: from gremlin.ics.uci.edu (mmdf@gremlin.ics.uci.edu [128.195.1.70]) by tux.w3.org (8.9.3/8.9.3) with SMTP id UAA24928 for ; Mon, 21 Jan 2002 20:01:41 -0500 Received: from localhost ( louvre.ics.uci.edu [128.195.20.97] ) by gremlin-relay.ics.uci.edu id aa27485 for ; 21 Jan 2002 17:01 PST Date: Mon, 21 Jan 2002 17:01:38 -0800 (PST) From: Joachim Feise To: w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Searching folders with WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5822 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, 21 Jan 2002, Lisa Dusseault wrote: > > > > 2) I am trying to create a contact folder (in Exchange)using > > > MKCOL and I am > > > receiving the Status Code 403 (Forbidden). Is this just an issue with > > > permissions or am I using the wrong method to create a folder? > > > The code is > > > below: > > > > You can't use MKCOL with a request body. Try again without. > > > > Actually, I believe some Microsoft servers do support MKCOL with a body. > However, this is a non-standard extension of MKCOL, not described in RFC2518 > or any other document submitted to the working group or the IETF as far as I > know. Thus I suspect this working group can't be of much assistance in this > matter. Hmm, to quote section 8.3.1 of http://www.ietf.org/rfc/rfc2518.txt: "A MKCOL request message may contain a message body. The behavior of a MKCOL request when the body is present is limited to creating collections, members of a collection, bodies of members and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand it MUST respond with a 415 (Unsupported Media Type) status code. The exact behavior of MKCOL for various request media types is undefined in this document, and will be specified in separate documents." -Joe From w3c-dist-auth-request@w3.org Tue Jan 22 00:26:20 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04071 for ; Tue, 22 Jan 2002 00:26:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA07789; Tue, 22 Jan 2002 00:23:47 -0500 (EST) Resent-Date: Tue, 22 Jan 2002 00:23:47 -0500 (EST) Resent-Message-Id: <200201220523.AAA07789@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA07768 for ; Tue, 22 Jan 2002 00:23:35 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA30402 for ; Tue, 22 Jan 2002 00:23:35 -0500 Received: from moose ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id g0M5Mjj70574; Mon, 21 Jan 2002 21:22:46 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Clemm, Geoff" , Date: Mon, 21 Jan 2002 21:21:09 -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.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AEC8@SUS-MA1IT01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5823 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit What I would find most useful would be a lock owner field with a value defined by the server. Since the server is likely to have authenticated the user, they presumably know how to identify the user. Existing support for the ACLs spec would mean that a Principal URL could be available. Allowing the server to set this value means that the information is more reliable. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, January 18, 2002 11:28 AM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > I would describe our conclusion as: > > We need to define a new field, say DAV:lockowner, that is specified > in a LOCK request, and that takes an XML value. We will define > some standard elements for that value. > > We should then deprecate the use of the DAV:owner field, as a field > that contains non-interoperable data about the lock owner. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Friday, January 18, 2002 1:35 PM > To: Daniel Brotsky; w3c-dist-auth@w3c.org; Lisa Dusseault > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > It sounds like we've concluded that we can't reuse the lockowner field > because we've already specified that it's free text. > > Do we still have the requirement mentioned at... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html > says... > > regarding identifying the owner of a lock? If so, now that we've had some > discussion on this topic, can someone provide an improved > definition of the > requirement? And a proposal? Dan? Lisa? Geoff? Julian? > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > From w3c-dist-auth-request@w3.org Tue Jan 22 08:13:54 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17292 for ; Tue, 22 Jan 2002 08:13:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA08941; Tue, 22 Jan 2002 08:10:32 -0500 (EST) Resent-Date: Tue, 22 Jan 2002 08:10:32 -0500 (EST) Resent-Message-Id: <200201221310.IAA08941@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA08906 for ; Tue, 22 Jan 2002 08:10:25 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-084155.rational.com [130.213.84.155]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA14934 for ; Tue, 22 Jan 2002 08:10:26 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Tue, 22 Jan 2002 08:09:24 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 08:09:24 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B10585E44F@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 22 Jan 2002 08:08:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5824 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The ACL spec does not associate a principal URL with an authenticated user, and therefore a principal URL is not in general available. The ACL spec only assumes that the server can "match" a users credentials against the principals identified in the ACL of a resource, but it does not assume that the server can pick one of these principals as "being" the user (several can match). In addition, it is a security hole to require a server to provide more identification about a user than that user's client wishes to provide. Because of these reasons, I strongly object to the introduction of a server defined principal field. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Tuesday, January 22, 2002 12:21 AM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER What I would find most useful would be a lock owner field with a value defined by the server. Since the server is likely to have authenticated the user, they presumably know how to identify the user. Existing support for the ACLs spec would mean that a Principal URL could be available. Allowing the server to set this value means that the information is more reliable. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, January 18, 2002 11:28 AM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > I would describe our conclusion as: > > We need to define a new field, say DAV:lockowner, that is specified > in a LOCK request, and that takes an XML value. We will define > some standard elements for that value. > > We should then deprecate the use of the DAV:owner field, as a field > that contains non-interoperable data about the lock owner. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Friday, January 18, 2002 1:35 PM > To: Daniel Brotsky; w3c-dist-auth@w3c.org; Lisa Dusseault > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > It sounds like we've concluded that we can't reuse the lockowner field > because we've already specified that it's free text. > > Do we still have the requirement mentioned at... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html > says... > > regarding identifying the owner of a lock? If so, now that we've had some > discussion on this topic, can someone provide an improved > definition of the > requirement? And a proposal? Dan? Lisa? Geoff? Julian? > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > From w3c-dist-auth-request@w3.org Tue Jan 22 08:14:02 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17305 for ; Tue, 22 Jan 2002 08:14:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA08969; Tue, 22 Jan 2002 08:10:39 -0500 (EST) Resent-Date: Tue, 22 Jan 2002 08:10:39 -0500 (EST) Resent-Message-Id: <200201221310.IAA08969@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA08908 for ; Tue, 22 Jan 2002 08:10:26 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-084155.rational.com [130.213.84.155]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA14935 for ; Tue, 22 Jan 2002 08:10:26 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Tue, 22 Jan 2002 08:09:24 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 08:09:24 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B10585E451@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 22 Jan 2002 08:08:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5825 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Yes, I believe there is also consensus that we should define standard LOCK privileges. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] I think we should also consider defining standard LOCK privileges. From w3c-dist-auth-request@w3.org Wed Jan 23 21:14:38 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01367 for ; Wed, 23 Jan 2002 21:14:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA26871; Wed, 23 Jan 2002 21:11:18 -0500 (EST) Resent-Date: Wed, 23 Jan 2002 21:11:18 -0500 (EST) Resent-Message-Id: <200201240211.VAA26871@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA26837 for ; Wed, 23 Jan 2002 21:11:08 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA07056 for ; Wed, 23 Jan 2002 21:11:08 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id SAA09330 for ; Wed, 23 Jan 2002 18:11:13 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 23 Jan 2002 18:09:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C1A439.2B26AA90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: WebDav question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5826 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1A439.2B26AA90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Jaqueline Gutierrez [mailto:jvgnica@yahoo.com] Sent: Wednesday, January 23, 2002 5:54 PM To: w3c-dist-auth@w3.org; csamson@ndirect.co.uk Subject: [Moderator Action] WebDav question Can You Help me with this. When attempting to use WebDav we have to include the port number in the URL. http://customer1.magnifi.com:7011/webfolder It will not work with http://customer1.magnifi.com/webfolder Apache is listening on port 80 and passing requests to Weblogic Application Server. WLS is listening on port 7017 The problem is that when we create a WebDav folder on the PC desktop the URL needs to include the WLS port number and thus exposes WLS to the outside world. We ! ! ! only expose port 80 to the outside world and therefore our users will not be able to use the WebDav feature Thanks. ---------------------------------------------------------------------------- ---- Do You Yahoo!? Yahoo! Auctions Great stuff seeing new owners! Bid now! ------=_NextPart_000_0000_01C1A439.2B26AA90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: Jaqueline Gutierrez=20 [mailto:jvgnica@yahoo.com]
Sent: Wednesday, January 23, 2002 = 5:54=20 PM
To: w3c-dist-auth@w3.org; = csamson@ndirect.co.uk
Subject:=20 [Moderator Action] WebDav question

Can You Help me = with=20 this.



When attempting to use WebDav we have to include = the port=20 number in the
URL.
http://customer1.magnifi.com:7011/webfolder
<http://customer1.magnifi.com:7011/webfolder> =     =20

It will not work with   http://customer1.magnifi.com/webfolder
<http://customer1.magnifi.com/webfolder> =

Apache is=20 listening on port 80 and passing requests to Weblogic=20
Application
Server.

WLS is listening on port 7017 =

The=20 problem is that when we create a WebDav folder on the PC desktop
the = URL
needs to include the WLS port number and thus exposes WLS to the=20
outside
world.

We ! ! ! only expose port 80 to the = outside world=20 and therefore our users
will not
be able to use the WebDav=20 feature

Thanks.


Do You Yahoo!?
Yahoo= !=20 Auctions Great stuff seeing new owners! Bid=20 now! ------=_NextPart_000_0000_01C1A439.2B26AA90-- From w3c-dist-auth-request@w3.org Wed Jan 23 22:21:06 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03141 for ; Wed, 23 Jan 2002 22:21:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA00713; Wed, 23 Jan 2002 22:18:51 -0500 (EST) Resent-Date: Wed, 23 Jan 2002 22:18:51 -0500 (EST) Resent-Message-Id: <200201240318.WAA00713@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA00692 for ; Wed, 23 Jan 2002 22:18:46 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA13406 for ; Wed, 23 Jan 2002 22:18:47 -0500 Received: from cse.ucsc.edu ([63.194.88.161]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQF00HYBAJ9X2@mta5.snfc21.pbi.net> for w3c-dist-auth@w3.org; Wed, 23 Jan 2002 19:18:46 -0800 (PST) Date: Wed, 23 Jan 2002 19:14:06 -0800 From: Elias Sinderson To: jvgnica@yahoo.com Cc: WebDAV Message-id: <3C4F7BFE.6050000@cse.ucsc.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 References: Subject: Re: WebDav question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5827 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Without knowing more of the details, I'd say that this sounds more like an IT policy issue than a WebDAV one. Elias > -----Original Message----- > From: Jaqueline Gutierrez [mailto:jvgnica@yahoo.com] > Sent: Wednesday, January 23, 2002 5:54 PM > To: w3c-dist-auth@w3.org; csamson@ndirect.co.uk > Subject: [Moderator Action] WebDav question > > Can You Help me with this. > > When attempting to use WebDav we have to include the port number in the > URL. > http://customer1.magnifi.com:7011/webfolder > < http://customer1.magnifi.com:7011/webfolder > > > It will not work with http://customer1.magnifi.com/webfolder > > > Apache is listening on port 80 and passing requests to Weblogic > Application Server. > > WLS is listening on port 7017 > > The problem is that when we create a WebDav folder on the PC desktop > the URL needs to include the WLS port number and thus exposes WLS to the > outside world. > > We ! ! ! only expose port 80 to the outside world and therefore our users > will not be able to use the WebDav feature > > Thanks. From w3c-dist-auth-request@w3.org Thu Jan 24 05:04:46 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18788 for ; Thu, 24 Jan 2002 05:04:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA02425; Thu, 24 Jan 2002 05:03:31 -0500 (EST) Resent-Date: Thu, 24 Jan 2002 05:03:31 -0500 (EST) Resent-Message-Id: <200201241003.FAA02425@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA02369 for ; Thu, 24 Jan 2002 05:03:16 -0500 (EST) Received: from stal-gate-out.merant.com ([62.189.101.235]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA26992 for ; Thu, 24 Jan 2002 05:03:16 -0500 Received: from stalmail.eu.merant.com (stalmail.eu.merant.com [10.130.13.220]) by stal-gate-out.merant.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id KAA00656; Thu, 24 Jan 2002 10:05:53 GMT Received: by stalmail.eu.merant.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 09:59:42 -0000 Message-ID: <20CF1CE11441D411919C0008C7C5A13B03BF629B@stalmail.eu.merant.com> From: Peter Raymond To: ietf-dav-versioning@w3.org Cc: w3c-dist-auth@w3c.org Date: Thu, 24 Jan 2002 09:59:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A4BD.D7615920" Subject: Missing elements from examples in the DeltaV specificati on Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5828 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A4BD.D7615920 Content-Type: text/plain; charset="ISO-8859-1" Hi, Section 12.9.1 of RFC2518 gives a DTD for the response element of multistatus: But in the examples in section 7.1.1 and 11.2.1 in the deltav specification we have multistatus responses with elements but no or elements. These are invalid given the above DTD. So, are the examples missing elements or is the DTD wrong and should we allow responses without status and assume 200 OK? Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com ------_=_NextPart_001_01C1A4BD.D7615920 Content-Type: text/html; charset="ISO-8859-1" Missing <status> elements from examples in the DeltaV specification

Hi,

Section 12.9.1 of RFC2518 gives a DTD for the response element of multistatus:

<!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?) >

But in the examples in section 7.1.1 and 11.2.1 in the deltav specification
we have multistatus responses with <href> elements but no <status> or <propstat>
elements.  These are invalid given the above DTD.

So, are the examples missing <status> elements or is the DTD wrong and should we
allow responses without status and assume 200 OK?

Regards,
--
Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com


------_=_NextPart_001_01C1A4BD.D7615920-- From w3c-dist-auth-request@w3.org Thu Jan 24 06:03:00 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19476 for ; Thu, 24 Jan 2002 06:03:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA05644; Thu, 24 Jan 2002 06:01:53 -0500 (EST) Resent-Date: Thu, 24 Jan 2002 06:01:53 -0500 (EST) Resent-Message-Id: <200201241101.GAA05644@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA05562 for ; Thu, 24 Jan 2002 06:01:30 -0500 (EST) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA00640 for ; Thu, 24 Jan 2002 06:01:30 -0500 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id KAA15252; Thu, 24 Jan 2002 10:38:49 GMT Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0OB0MI17268; Thu, 24 Jan 2002 11:00:22 GMT To: Peter Raymond Cc: ietf-dav-versioning@w3.org, ietf-dav-versioning-request@w3.org, w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Tim Ellison" Message-ID: Date: Thu, 24 Jan 2002 10:49:59 +0000 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.8 |June 18, 2001) at 24/01/2002 11:00:57, Serialize complete at 24/01/2002 11:00:57 Content-Type: text/plain; charset="us-ascii" Subject: Re: Missing elements from examples in the DeltaV specificati on Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5829 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The examples should be updated. There is no good reason to depart from that DTD. Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 Peter Raymond Sent by: ietf-dav-versioning-request@w3.org 2002-01-24 09:59 To: ietf-dav-versioning@w3.org cc: w3c-dist-auth@w3c.org Subject: Missing elements from examples in the DeltaV specificati on Hi, Section 12.9.1 of RFC2518 gives a DTD for the response element of multistatus: But in the examples in section 7.1.1 and 11.2.1 in the deltav specification we have multistatus responses with elements but no or elements. These are invalid given the above DTD. So, are the examples missing elements or is the DTD wrong and should we allow responses without status and assume 200 OK? Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com From w3c-dist-auth-request@w3.org Fri Jan 25 07:40:10 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00561 for ; Fri, 25 Jan 2002 07:40:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA07788; Fri, 25 Jan 2002 07:37:21 -0500 (EST) Resent-Date: Fri, 25 Jan 2002 07:37:21 -0500 (EST) Resent-Message-Id: <200201251237.HAA07788@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA07766 for ; Fri, 25 Jan 2002 07:37:13 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA06139 for ; Fri, 25 Jan 2002 07:37:13 -0500 Received: (qmail 22431 invoked by uid 0); 25 Jan 2002 12:36:42 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 25 Jan 2002 12:36:42 -0000 From: "Julian Reschke" To: "WebDAV" Date: Fri, 25 Jan 2002 13:36:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AEA9@SUS-MA1IT01> Subject: need clarification about COPY to locked resource response code Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5830 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, when running the Litmus test suite against our server, we came across the following problem for lock test 8 (COPY): In this test case, a non-locked resource is copied to a locked resource without giving the lock token in the If: header. Litmus expects the server to return 423 LOCKED (and this is what moddav does). Both our server and IIS however return a 207 MULTISTATUS, and have a response element for the *destination URI* with an 423 LOCKED status. I think the latter is correct, because the problem isn't with the request URI. In the section about COPY behaviour for *collections*, RFC2518 says [1]: "If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status)." I think this should apply to copying non-collections as well. Julian [1] From w3c-dist-auth-request@w3.org Fri Jan 25 08:20:45 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01512 for ; Fri, 25 Jan 2002 08:20:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA10685; Fri, 25 Jan 2002 08:19:24 -0500 (EST) Resent-Date: Fri, 25 Jan 2002 08:19:24 -0500 (EST) Resent-Message-Id: <200201251319.IAA10685@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA10630 for ; Fri, 25 Jan 2002 08:19:10 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-079218.rational.com [130.213.79.218]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA12854 for ; Fri, 25 Jan 2002 08:19:08 -0500 From: gclemm@rational.com Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Fri, 25 Jan 2002 08:18:06 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 08:18:06 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105A31608@SUS-MA1IT01> To: w3c-dist-auth@w3.org Date: Fri, 25 Jan 2002 08:18:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: need clarification about COPY to locked resource response cod e Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5831 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I believe a client should accept either behavior. Section 8.8.5 explicitly states that a 423 indicates that the destination resource was locked, so there is no ambiguity about whether the 423 refers to the source or the destination. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, January 25, 2002 7:37 AM To: WebDAV Subject: need clarification about COPY to locked resource response code Hi, when running the Litmus test suite against our server, we came across the following problem for lock test 8 (COPY): In this test case, a non-locked resource is copied to a locked resource without giving the lock token in the If: header. Litmus expects the server to return 423 LOCKED (and this is what moddav does). Both our server and IIS however return a 207 MULTISTATUS, and have a response element for the *destination URI* with an 423 LOCKED status. I think the latter is correct, because the problem isn't with the request URI. In the section about COPY behaviour for *collections*, RFC2518 says [1]: "If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status)." I think this should apply to copying non-collections as well. Julian [1] From w3c-dist-auth-request@w3.org Fri Jan 25 10:17:39 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04774 for ; Fri, 25 Jan 2002 10:17:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA26315; Fri, 25 Jan 2002 10:15:53 -0500 (EST) Resent-Date: Fri, 25 Jan 2002 10:15:53 -0500 (EST) Resent-Message-Id: <200201251515.KAA26315@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA26271 for ; Fri, 25 Jan 2002 10:15:42 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA07665 for ; Fri, 25 Jan 2002 10:15:42 -0500 Received: (qmail 29273 invoked by uid 0); 25 Jan 2002 15:15:10 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 25 Jan 2002 15:15:10 -0000 From: "Julian Reschke" To: , Date: Fri, 25 Jan 2002 16:15:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B105A31608@SUS-MA1IT01> Subject: RE: need clarification about COPY to locked resource response cod e Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5832 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Geoff. Makes sense. However, if we replace COPY by MOVE, we indeed get that ambiguity (and this is actually mentioned in the spec). So I'd say that clients always should be able to process multistatus response body. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of gclemm@rational.com > Sent: Friday, January 25, 2002 2:18 PM > To: w3c-dist-auth@w3.org > Subject: RE: need clarification about COPY to locked resource response > cod e > > > I believe a client should accept either behavior. Section 8.8.5 > explicitly > states that a 423 indicates that the destination resource was locked, > so there is no ambiguity about whether the 423 refers to the source > or the destination. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, January 25, 2002 7:37 AM > To: WebDAV > Subject: need clarification about COPY to locked resource response code > > > Hi, > > when running the Litmus test suite against our server, we came across the > following problem for lock test 8 (COPY): > > In this test case, a non-locked resource is copied to a locked resource > without giving the lock token in the If: header. > > Litmus expects the server to return 423 LOCKED (and this is what moddav > does). > > Both our server and IIS however return a 207 MULTISTATUS, and have a > response element for the *destination URI* with an 423 LOCKED status. > > I think the latter is correct, because the problem isn't with the request > URI. > > In the section about COPY behaviour for *collections*, RFC2518 says [1]: > > "If an error in executing the COPY method occurs with a resource > other than > the resource identified in the Request-URI then the response MUST be a 207 > (Multi-Status)." > > I think this should apply to copying non-collections as well. > > Julian > > > > > [1] > From w3c-dist-auth-request@w3.org Fri Jan 25 12:12:48 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07846 for ; Fri, 25 Jan 2002 12:12:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA09796; Fri, 25 Jan 2002 12:11:40 -0500 (EST) Resent-Date: Fri, 25 Jan 2002 12:11:40 -0500 (EST) Resent-Message-Id: <200201251711.MAA09796@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA09756 for ; Fri, 25 Jan 2002 12:11:28 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01845 for ; Fri, 25 Jan 2002 12:11:28 -0500 Received: from cse.ucsc.edu ([63.194.88.161]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQI00MJH7R31B@mta5.snfc21.pbi.net> for w3c-dist-auth@w3.org; Fri, 25 Jan 2002 09:11:27 -0800 (PST) Date: Fri, 25 Jan 2002 09:06:47 -0800 From: Elias Sinderson To: w3c-dist-auth@w3.org Message-id: <3C5190A7.7000208@cse.ucsc.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 Subject: WebDAV DB question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5833 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi, I'm working on developing a DB module for Apache 2.0, mod_dav_mysql, that can be used in lieu of mod_dav_fs. The idea is to use MySQL as the DAV repository instead of the filesystem/dbm approach in mod_dav_fs. The following question has been raised in our group: How many properties, on average, are generally associated with each resource? Clearly the answer will vary depending upon the specific uses, but what sort of range are we talking about? If anyone has any data from real applications/sites it would be a great help in trying to develop an efficient DB schema. I would imagine that the same question has been raised in other development groups as well... Thanks. Elias From w3c-dist-auth-request@w3.org Fri Jan 25 13:17:20 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09837 for ; Fri, 25 Jan 2002 13:17:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA18124; Fri, 25 Jan 2002 13:15:57 -0500 (EST) Resent-Date: Fri, 25 Jan 2002 13:15:57 -0500 (EST) Resent-Message-Id: <200201251815.NAA18124@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA18100 for ; Fri, 25 Jan 2002 13:15:48 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA13365 for ; Fri, 25 Jan 2002 13:15:49 -0500 Received: from Tycho (dhcp-60-113.cse.ucsc.edu [128.114.60.113]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA21465 for ; Fri, 25 Jan 2002 10:15:51 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 25 Jan 2002 10:14: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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: Multiple resourcetypes? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5834 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added to the accept2 list. - Jim -----Original Message----- From: Hermann, Eckehard [mailto:Eckehard.Hermann@softwareag.com] Sent: Friday, January 25, 2002 3:58 AM To: w3c-dist-auth@w3c.org Cc: Pill, Juergen Subject: [Moderator Action] Multiple resourcetypes? Hi, the Webdav Access Control Protocol standard says under "4 Principal Properties": Additionally, a principal MUST report the DAV:principal empty XML element in the value of the DAV:resourcetype property in addition to all other reported elements. For example, a collection principal would report DAV:collection and DAV:principal elements. Do I understand it right, that a resource can have more as one DAV:resourcetype? regards Eckehard From w3c-dist-auth-request@w3.org Fri Jan 25 13:39:32 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10494 for ; Fri, 25 Jan 2002 13:39:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA20692; Fri, 25 Jan 2002 13:36:50 -0500 (EST) Resent-Date: Fri, 25 Jan 2002 13:36:50 -0500 (EST) Resent-Message-Id: <200201251836.NAA20692@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA20646 for ; Fri, 25 Jan 2002 13:36:35 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA17404 for ; Fri, 25 Jan 2002 13:36:34 -0500 Received: (qmail 1675 invoked by uid 0); 25 Jan 2002 18:36:03 -0000 Received: from pd9e51bbc.dip.t-dialin.net (HELO lisa) (217.229.27.188) by mail.gmx.net (mp003-rz3) with SMTP; 25 Jan 2002 18:36:03 -0000 From: "Julian Reschke" To: "WebDAV" Date: Fri, 25 Jan 2002 19:36:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: Multiple resourcetypes? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5835 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Hermann, Eckehard [mailto:Eckehard.Hermann@softwareag.com] > Sent: Friday, January 25, 2002 3:58 AM > To: w3c-dist-auth@w3c.org > Cc: Pill, Juergen > Subject: [Moderator Action] Multiple resourcetypes? > > > Hi, > > the Webdav Access Control Protocol standard says under "4 Principal > Properties": > > Additionally, a principal MUST report the DAV:principal empty XML > element in > the value of the DAV:resourcetype property in addition to all > other reported > elements. For example, a collection principal would report DAV:collection > and DAV:principal elements. > > Do I understand it right, that a resource can have more as one > DAV:resourcetype? No, but the DAV:resourcetype property may contain more than one child element, such as: From w3c-dist-auth-request@w3.org Fri Jan 25 14:44:22 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12364 for ; Fri, 25 Jan 2002 14:44:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA27146; Fri, 25 Jan 2002 14:43:19 -0500 (EST) Resent-Date: Fri, 25 Jan 2002 14:43:19 -0500 (EST) Resent-Message-Id: <200201251943.OAA27146@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA26999 for ; Fri, 25 Jan 2002 14:43:06 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA27989 for ; Fri, 25 Jan 2002 14:43:05 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA87984; Fri, 25 Jan 2002 14:39:30 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0PJgW982820; Fri, 25 Jan 2002 14:42:32 -0500 To: "Julian Reschke" Cc: "WebDAV" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 25 Jan 2002 14:36:15 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 01/25/2002 02:42:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Multiple resourcetypes? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5836 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: If no one disagrees, I'll put it on our issues list that at least one example in 2518 should show a resourcetype property that contains more than one element ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Jan 25 19:52:14 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19094 for ; Fri, 25 Jan 2002 19:52:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA17038; Fri, 25 Jan 2002 19:47:24 -0500 (EST) Resent-Date: Fri, 25 Jan 2002 19:47:24 -0500 (EST) Resent-Message-Id: <200201260047.TAA17038@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA17018 for ; Fri, 25 Jan 2002 19:47:09 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA09385 for ; Fri, 25 Jan 2002 19:47:09 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g0Q0jJ718679 for ; Fri, 25 Jan 2002 16:45:20 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g0Q0kr704441 for ; Fri, 25 Jan 2002 16:46:53 -0800 (PST) Received: from [192.168.1.20] ([130.248.188.69]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GQISTK00.65H; Fri, 25 Jan 2002 16:46:32 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com (Unverified) Message-Id: In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AEC8@SUS-MA1IT01> References: <3906C56A7BD1F54593344C05BD1374B103F8AEC8@SUS-MA1IT01> Date: Fri, 25 Jan 2002 08:54:33 -0800 To: "Clemm, Geoff" From: Daniel Brotsky Cc: w3c-dist-auth@w3c.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5837 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: (Sorry for the delay in this reply; I've been away from mail for a week.) At 2:28 PM -0500 1/18/02, Clemm, Geoff wrote: >I would describe our conclusion as: Yow. Unfortunately I would describe it in almost opposite terms... > >We need to define a new field, say DAV:lockowner, that is specified >in a LOCK request, and that takes an XML value. We will define >some standard elements for that value. I would have said our conclusion was: We need to define a new XML-valued field, say DAV:lockowner, that is owned by the server and returned as part of lockdiscovery. We will define some standard elements for that value which the server can use to reveal as much or as little as it wants about: - the principal owning the lock (e.g., a "login name") - the relationship between the owning principal and the requesting principal (e.g., requestor is/is not the owner) - the capabilities of the requestor with respect to the lock (e.g., requestor has/has not the same capabilities as the owner; requestor has/has not the ability to use or unlock the lock). > >We should then deprecate the use of the DAV:owner field, as a field >that contains non-interoperable data about the lock owner. I would have said: We then need to explicitly reserve the use of the DAV:owner field to be for clients to use at lock request time (in order to provide for client-to-client conventional communication). We need to forbid servers from rewriting the client-specified value (other than clarifying that the DAV:owner field is XML-valued, and thus subject to parsing/regeneration by the server). We then need to resolve the issue about whether the client can rewrite the lock:owner field as part of a lock refresh request. (I believe this was an outstanding issue as to whether clients can change any aspect of a lock in a refresh request.) I would recommend that clients be able to do this. dan > >Cheers, >Geoff > >-----Original Message----- >From: Jason Crawford [mailto:ccjason@us.ibm.com] >Sent: Friday, January 18, 2002 1:35 PM >To: Daniel Brotsky; w3c-dist-auth@w3c.org; Lisa Dusseault >Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > >It sounds like we've concluded that we can't reuse the lockowner field >because we've already specified that it's free text. > >Do we still have the requirement mentioned at... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html >says... > >regarding identifying the owner of a lock? If so, now that we've had some >discussion on this topic, can someone provide an improved definition of the >requirement? And a proposal? Dan? Lisa? Geoff? Julian? > >J. > >------------------------------------------ >Phone: 914-784-7569, ccjason@us.ibm.com -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Sat Jan 26 06:02:05 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05189 for ; Sat, 26 Jan 2002 06:02:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA18385; Sat, 26 Jan 2002 05:57:45 -0500 (EST) Resent-Date: Sat, 26 Jan 2002 05:57:45 -0500 (EST) Resent-Message-Id: <200201261057.FAA18385@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA18345 for ; Sat, 26 Jan 2002 05:57:33 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA18932 for ; Sat, 26 Jan 2002 05:57:32 -0500 Received: (qmail 1663 invoked by uid 0); 26 Jan 2002 10:57:01 -0000 Received: from pd9535b8d.dip.t-dialin.net (HELO lisa) (217.83.91.141) by mail.gmx.net (mp013-rz3) with SMTP; 26 Jan 2002 10:57:01 -0000 From: "Julian Reschke" To: Cc: "Daniel Brotsky" Date: Sat, 26 Jan 2002 11:56:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5838 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Daniel, I think you need to go back again through the mails that were exchanged. My summary: a) We agree that server-supplied information (if at allI) should be handled by ACL locking privileges. I think we also have an agreement that locking privileges should become part of the ACL draft/spec. b) The current DAV:owner element is something that the client sets and MUST not be touched by the server. However, it's contents is undefined and thus can't be used for interoperability *between* clients. Q: do we want to deprecate it because of this? c) Because of b), we need a new client-supplied lock owner information element, in which it reveals whatever the user of the client software wants to reveal using a *standard* format (so that one client can actually *process* the information a different client has set). My initital proposal for this format is: EMail Work Phone DTD fragment: > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky > Sent: Friday, January 25, 2002 5:55 PM > To: Clemm, Geoff > Cc: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > (Sorry for the delay in this reply; I've been away from mail for a week.) > > At 2:28 PM -0500 1/18/02, Clemm, Geoff wrote: > >I would describe our conclusion as: > > Yow. Unfortunately I would describe it in almost opposite terms... > > > > >We need to define a new field, say DAV:lockowner, that is specified > >in a LOCK request, and that takes an XML value. We will define > >some standard elements for that value. > > I would have said our conclusion was: > > We need to define a new XML-valued field, say DAV:lockowner, that is > owned by the server and returned as part of lockdiscovery. We will > define some standard elements for that value which the server can use > to reveal as much or as little as it wants about: > > - the principal owning the lock (e.g., a "login name") > - the relationship between the owning principal and the requesting > principal (e.g., requestor is/is not the owner) > - the capabilities of the requestor with respect to the lock (e.g., > requestor has/has not the same capabilities as the owner; requestor > has/has not the ability to use or unlock the lock). > > > > >We should then deprecate the use of the DAV:owner field, as a field > >that contains non-interoperable data about the lock owner. > > I would have said: > > We then need to explicitly reserve the use of the DAV:owner field to > be for clients to use at lock request time (in order to provide for > client-to-client conventional communication). We need to forbid > servers from rewriting the client-specified value (other than > clarifying that the DAV:owner field is XML-valued, and thus subject > to parsing/regeneration by the server). > > We then need to resolve the issue about whether the client can > rewrite the lock:owner field as part of a lock refresh request. (I > believe this was an outstanding issue as to whether clients can > change any aspect of a lock in a refresh request.) I would recommend > that clients be able to do this. > > dan > > > > >Cheers, > >Geoff > > > >-----Original Message----- > >From: Jason Crawford [mailto:ccjason@us.ibm.com] > >Sent: Friday, January 18, 2002 1:35 PM > >To: Daniel Brotsky; w3c-dist-auth@w3c.org; Lisa Dusseault > >Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > > > > >It sounds like we've concluded that we can't reuse the lockowner field > >because we've already specified that it's free text. > > > >Do we still have the requirement mentioned at... > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html > >says... > > > >regarding identifying the owner of a lock? If so, now that > we've had some > >discussion on this topic, can someone provide an improved > definition of the > >requirement? And a proposal? Dan? Lisa? Geoff? Julian? > > > >J. > > > >------------------------------------------ > >Phone: 914-784-7569, ccjason@us.ibm.com > > > -- > Daniel Brotsky, Adobe Systems > tel 408-536-4150, pager 877-704-4062 > 2-way pager email: > From w3c-dist-auth-request@w3.org Sat Jan 26 11:08:00 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08361 for ; Sat, 26 Jan 2002 11:08:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA03291; Sat, 26 Jan 2002 11:01:41 -0500 (EST) Resent-Date: Sat, 26 Jan 2002 11:01:41 -0500 (EST) Resent-Message-Id: <200201261601.LAA03291@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA03263 for ; Sat, 26 Jan 2002 11:01:29 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA08085 for ; Sat, 26 Jan 2002 11:01:29 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA327442; Sat, 26 Jan 2002 10:57:54 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0QG0ql121344; Sat, 26 Jan 2002 11:00:56 -0500 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sat, 26 Jan 2002 10:59:36 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 01/26/2002 11:00:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5839 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << The ACL spec does not associate a principal URL with an authenticated user, and therefore a principal URL is not in general available. >> Geoff, could you explain what this sentence means? Are you saying a server can't necessarily map an authenticated user to a principal URL. But it can (and actually must be able to) check if a *given* principal URL includes a given authenticated user? Please elaborate. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sun Jan 27 09:47:11 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00102 for ; Sun, 27 Jan 2002 09:47:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA20486; Sun, 27 Jan 2002 09:40:05 -0500 (EST) Resent-Date: Sun, 27 Jan 2002 09:40:05 -0500 (EST) Resent-Message-Id: <200201271440.JAA20486@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA20452 for ; Sun, 27 Jan 2002 09:39:51 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-079218.rational.com [130.213.79.218]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA04857 for ; Sun, 27 Jan 2002 09:39:51 -0500 From: gclemm@rational.com Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Sun, 27 Jan 2002 09:38:50 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Jan 2002 09:38:50 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105A31903@SUS-MA1IT01> To: w3c-dist-auth@w3c.org Date: Sun, 27 Jan 2002 09:38:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5840 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Julian's expanded summary. In particular, although a "server generated lock principal property" has been proposed, this proposal has had strong opposition (for security and ACL related reasons that are detailed in this email thread), while the additional client-defined owner field with a standard format was acceptable to everyone (at least, nobody objected, and several people support it). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, January 26, 2002 5:57 AM To: w3c-dist-auth@w3c.org Cc: Daniel Brotsky Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Daniel, I think you need to go back again through the mails that were exchanged. My summary: a) We agree that server-supplied information (if at allI) should be handled by ACL locking privileges. I think we also have an agreement that locking privileges should become part of the ACL draft/spec. b) The current DAV:owner element is something that the client sets and MUST not be touched by the server. However, it's contents is undefined and thus can't be used for interoperability *between* clients. Q: do we want to deprecate it because of this? c) Because of b), we need a new client-supplied lock owner information element, in which it reveals whatever the user of the client software wants to reveal using a *standard* format (so that one client can actually *process* the information a different client has set). My initital proposal for this format is: EMail Work Phone DTD fragment: > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky > Sent: Friday, January 25, 2002 5:55 PM > To: Clemm, Geoff > Cc: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > (Sorry for the delay in this reply; I've been away from mail for a week.) > > At 2:28 PM -0500 1/18/02, Clemm, Geoff wrote: > >I would describe our conclusion as: > > Yow. Unfortunately I would describe it in almost opposite terms... > > > > >We need to define a new field, say DAV:lockowner, that is specified > >in a LOCK request, and that takes an XML value. We will define > >some standard elements for that value. > > I would have said our conclusion was: > > We need to define a new XML-valued field, say DAV:lockowner, that is > owned by the server and returned as part of lockdiscovery. We will > define some standard elements for that value which the server can use > to reveal as much or as little as it wants about: > > - the principal owning the lock (e.g., a "login name") > - the relationship between the owning principal and the requesting > principal (e.g., requestor is/is not the owner) > - the capabilities of the requestor with respect to the lock (e.g., > requestor has/has not the same capabilities as the owner; requestor > has/has not the ability to use or unlock the lock). > > > > >We should then deprecate the use of the DAV:owner field, as a field > >that contains non-interoperable data about the lock owner. > > I would have said: > > We then need to explicitly reserve the use of the DAV:owner field to > be for clients to use at lock request time (in order to provide for > client-to-client conventional communication). We need to forbid > servers from rewriting the client-specified value (other than > clarifying that the DAV:owner field is XML-valued, and thus subject > to parsing/regeneration by the server). > > We then need to resolve the issue about whether the client can > rewrite the lock:owner field as part of a lock refresh request. (I > believe this was an outstanding issue as to whether clients can > change any aspect of a lock in a refresh request.) I would recommend > that clients be able to do this. > > dan > > > > >Cheers, > >Geoff > > > >-----Original Message----- > >From: Jason Crawford [mailto:ccjason@us.ibm.com] > >Sent: Friday, January 18, 2002 1:35 PM > >To: Daniel Brotsky; w3c-dist-auth@w3c.org; Lisa Dusseault > >Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > > > > >It sounds like we've concluded that we can't reuse the lockowner field > >because we've already specified that it's free text. > > > >Do we still have the requirement mentioned at... > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0218.html > >says... > > > >regarding identifying the owner of a lock? If so, now that > we've had some > >discussion on this topic, can someone provide an improved > definition of the > >requirement? And a proposal? Dan? Lisa? Geoff? Julian? > > > >J. > > > >------------------------------------------ > >Phone: 914-784-7569, ccjason@us.ibm.com > > > -- > Daniel Brotsky, Adobe Systems > tel 408-536-4150, pager 877-704-4062 > 2-way pager email: > From w3c-dist-auth-request@w3.org Sun Jan 27 09:47:29 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00116 for ; Sun, 27 Jan 2002 09:47:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA20511; Sun, 27 Jan 2002 09:40:15 -0500 (EST) Resent-Date: Sun, 27 Jan 2002 09:40:15 -0500 (EST) Resent-Message-Id: <200201271440.JAA20511@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA20460 for ; Sun, 27 Jan 2002 09:39:53 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-079218.rational.com [130.213.79.218]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA04859 for ; Sun, 27 Jan 2002 09:39:53 -0500 From: gclemm@rational.com Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Sun, 27 Jan 2002 09:38:52 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Jan 2002 09:38:52 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105A31904@SUS-MA1IT01> To: w3c-dist-auth@w3c.org Date: Sun, 27 Jan 2002 09:38:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5841 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Yes. A server must be able to check if the current user "matches" a given principal URL, but this could be one of many principal URL's (from the same or different domains) that the current user matches, and there is no interoperable way for the client to ask the server "what principal am I", and then try to match that principal against the one stored with the lock. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Saturday, January 26, 2002 11:00 AM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER << The ACL spec does not associate a principal URL with an authenticated user, and therefore a principal URL is not in general available. >> Geoff, could you explain what this sentence means? Are you saying a server can't necessarily map an authenticated user to a principal URL. But it can (and actually must be able to) check if a *given* principal URL includes a given authenticated user? Please elaborate. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Jan 28 09:55:45 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28088 for ; Mon, 28 Jan 2002 09:55:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA22586; Mon, 28 Jan 2002 09:46:20 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 09:46:20 -0500 (EST) Resent-Message-Id: <200201281446.JAA22586@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA22538 for ; Mon, 28 Jan 2002 09:46:12 -0500 (EST) Received: from server8.software-ag.de (server8.software-ag.de [193.26.193.23]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA32227 for ; Mon, 28 Jan 2002 09:46:11 -0500 Received: from daehub01.software-ag.de by server8.software-ag.de; (8.9.3/8.9.3) id PAA19252; Mon, 28 Jan 2002 15:45:46 +0100 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Jan 2002 15:45:35 +0100 Message-ID: From: "Pill, Juergen" To: w3c-dist-auth@w3.org Date: Mon, 28 Jan 2002 15:45:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RFC2518: depth XML element: Infinite Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5842 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hello, The depth XML element is used throughout the examples in RFC2518 with a capital "i" (e.g. Infinity, page 36; 8.10.8.), but in the xml definition it is spelled with a small "i". What would be the preferred way for a server to deliver the infinite value within the XML document back? Best regards Juergen Pill From w3c-dist-auth-request@w3.org Mon Jan 28 10:12:23 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28641 for ; Mon, 28 Jan 2002 10:12:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA25361; Mon, 28 Jan 2002 10:08:21 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 10:08:21 -0500 (EST) Resent-Message-Id: <200201281508.KAA25361@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA25309 for ; Mon, 28 Jan 2002 10:08:06 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA08511 for ; Mon, 28 Jan 2002 10:08:06 -0500 Received: (qmail 20395 invoked by uid 0); 28 Jan 2002 15:07:35 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 28 Jan 2002 15:07:35 -0000 From: "Julian Reschke" To: Date: Mon, 28 Jan 2002 16:07:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: RFC2518: depth XML element: Infinite Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5843 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'd say the examples are wrong and need to be fixed (after checking current implementations). > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen > Sent: Monday, January 28, 2002 3:45 PM > To: w3c-dist-auth@w3.org > Subject: RFC2518: depth XML element: Infinite > > > Hello, > > The depth XML element is used throughout the examples in RFC2518 with a > capital "i" (e.g. Infinity, page 36; 8.10.8.), but in the xml > definition it > is spelled with a small "i". > > What would be the preferred way for a server to deliver > the infinite value within the XML document back? > > Best regards > > Juergen Pill > > From w3c-dist-auth-request@w3.org Mon Jan 28 10:13:15 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28686 for ; Mon, 28 Jan 2002 10:13:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA25431; Mon, 28 Jan 2002 10:08:35 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 10:08:35 -0500 (EST) Resent-Message-Id: <200201281508.KAA25431@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA25317 for ; Mon, 28 Jan 2002 10:08:08 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA08514 for ; Mon, 28 Jan 2002 10:08:08 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA123512; Mon, 28 Jan 2002 10:04:29 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0SF7MU120842; Mon, 28 Jan 2002 10:07:22 -0500 To: Daniel Brotsky Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org, "Julian Reschke" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 28 Jan 2002 10:07:04 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 01/28/2002 10:07:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5844 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Julian's XLink based proposal sounds fine to me. Dan, I assume you understand and sympathize with Geoff's hesitance to having the server try to reveal the creator of the lock. Is there any other info about a lock that ACL's don't provide that you feel needs to be provided? Geoff, Julian, are we sure we can't just define DAV:owner (rather than a new field) more restrictively to comply with your Julian's proposal? Lisa, Geoff, Julian, Can you think out the interoperability scenarios and issues of Julian's proposal? (I wasn't at the interops so I'm not familiar with the current uses of DAV:owner and how Julian's proposal affects the currently deployed systems and if there are transition issues.) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Jan 28 12:24:33 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03176 for ; Mon, 28 Jan 2002 12:24:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA23261; Mon, 28 Jan 2002 12:23:11 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 12:23:11 -0500 (EST) Resent-Message-Id: <200201281723.MAA23261@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA23239 for ; Mon, 28 Jan 2002 12:23:03 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA11908 for ; Mon, 28 Jan 2002 12:23:03 -0500 Received: (qmail 14257 invoked by uid 0); 28 Jan 2002 17:22:32 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 28 Jan 2002 17:22:32 -0000 From: "Julian Reschke" To: "Pill, Juergen" , Date: Mon, 28 Jan 2002 18:22:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: RFC2518: depth XML element: Infinite Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5846 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit BTW: this is already on the open issues list as [1]: INFINITY_USE_IN_XML [1] > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen > Sent: Monday, January 28, 2002 3:45 PM > To: w3c-dist-auth@w3.org > Subject: RFC2518: depth XML element: Infinite > > > Hello, > > The depth XML element is used throughout the examples in RFC2518 with a > capital "i" (e.g. Infinity, page 36; 8.10.8.), but in the xml > definition it > is spelled with a small "i". > > What would be the preferred way for a server to deliver > the infinite value within the XML document back? > > Best regards > > Juergen Pill > > From w3c-dist-auth-request@w3.org Mon Jan 28 12:47:36 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03821 for ; Mon, 28 Jan 2002 12:47:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA28931; Mon, 28 Jan 2002 12:46:39 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 12:46:39 -0500 (EST) Resent-Message-Id: <200201281746.MAA28931@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA28894 for ; Mon, 28 Jan 2002 12:46:25 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA17106 for ; Mon, 28 Jan 2002 12:46:25 -0500 Received: (qmail 30904 invoked by uid 0); 28 Jan 2002 17:45:54 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp013-rz3) with SMTP; 28 Jan 2002 17:45:54 -0000 From: "Julian Reschke" To: Date: Mon, 28 Jan 2002 18:45:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: new (well, old) issue to be added to issues list: keepalive Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5848 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi. Currently, RFC2518 says in 12.12.1 [1]: So individual properties are identified by "href" (which doesn't make sense in the general case). So (assuming that propertybehaviour/keepalive isn't dropped anyway), this will need to be changed to: where DAV:prop contains property elements. Julian [1] From w3c-dist-auth-request@w3.org Mon Jan 28 13:08:11 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04550 for ; Mon, 28 Jan 2002 13:08:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01560; Mon, 28 Jan 2002 13:07:10 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 13:07:10 -0500 (EST) Resent-Message-Id: <200201281807.NAA01560@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01540 for ; Mon, 28 Jan 2002 13:07:01 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-079218.rational.com [130.213.79.218]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA20959 for ; Mon, 28 Jan 2002 13:07:02 -0500 From: gclemm@rational.com Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Mon, 28 Jan 2002 13:06:00 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 13:06:00 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AF1E@SUS-MA1IT01> To: w3c-dist-auth@w3c.org Date: Mon, 28 Jan 2002 13:05:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5849 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It probably is worth looking a bit harder at what exactly would be the costs of simply recommending some standard elements to go into the value of the existing DAV:owner element. I assume that clients today are written to work really well when they encounter a lock written by clients from the same vendor (since they would have a detailed knowledge of the structure of the information in DAV:owner), but at least "blurt out" the information in DAV:owner when encountering a lock from some other vendor's client. If we were to recommend some specific sub-elements for DAV:owner, then existing clients would be unaffected when running against existing servers (of course), and new clients would exhibit the desired improved interoperability when running against new servers. It is only old clients from a given vendor running against new servers from the same vendor that would see a hit, if the new standardized DAV:owner fields can't be inserted without disrupting the ability of old clients extracting the old information. In particular, since it is the new *clients* that will be inserting these new fields, if we make sure that the location of the new standard fields is sufficiently flexible, then the new clients from a specific vendor might be able to append these new fields to the information they currently write in a way that won't disrupt the ability from old clients *from that vendor* being able to read the old information. So it might be worthwhile to first find out if there is some way we could define the location of the new fields such that new clients from a vendor could can add them in without disrupting the behavior of their old clients. If there really is no way to do this, then we could add a second DAV:formatted:owner field instead. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Monday, January 28, 2002 12:34 PM To: Jason Crawford; Daniel Brotsky Cc: Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > Geoff, Julian, are we sure we can't just define DAV:owner (rather than a > new field) more restrictively to comply with your Julian's proposal? We can't redefine DAV: owner. As you suggest, there are current deployed uses of DAV:owner and there would indeed be transition issues. > Lisa, Geoff, Julian, Can you think out the interoperability scenarios and > issues of Julian's proposal? (I wasn't at the interops so I'm > not familiar > with the current uses of DAV:owner and how Julian's proposal affects the > currently deployed systems and if there are transition issues.) Lisa From w3c-dist-auth-request@w3.org Mon Jan 28 13:31:35 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05235 for ; Mon, 28 Jan 2002 13:31:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA03231; Mon, 28 Jan 2002 13:30:16 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 13:30:16 -0500 (EST) Resent-Message-Id: <200201281830.NAA03231@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA03211 for ; Mon, 28 Jan 2002 13:30:11 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA24944 for ; Mon, 28 Jan 2002 13:30:11 -0500 Received: (qmail 2665 invoked by uid 0); 28 Jan 2002 18:29:40 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001-rz3) with SMTP; 28 Jan 2002 18:29:40 -0000 From: "Julian Reschke" To: Date: Mon, 28 Jan 2002 19:29:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AF1E@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5850 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Interesting idea. However: 1) Let's assume that we adopt something along the line the DAV:contact-URI-set I proposed earlier, but put it *into* the existing DAV:owner element. We would just define that if a DAV:owner contains DAV:contact-URI-set, it's format must adhere to our "DTD". 2) Existing clients which do not add DAV:contact-URI-set aren't affected at all. 3) When will existing clients use DAV:contact-URI-set? I'd say never, because I just thought of this property name :-), and they shouldn't anyway because it's an element in the DAV: namespace (which is reserved for official WebDAV stuff). 4) The main problem will be new (updated) clients that want to support the new feature, while maintaining compatibility with old versions. The cleanest way would be not to interfere with the old element. Old stuff stays in DAV:lockinfo/DAV:owner, new stuff is put into DAV:lockinfo/DAV:contact-URI-set. 5) To find out whether 4) is a problem, we would have to check all existing clients that have the problem of assuming some specific format. MS Office (I think) always displays the concatenated text content of all text nodes, so it would still display something useful, however it might not look pretty. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of gclemm@rational.com > Sent: Monday, January 28, 2002 7:06 PM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > It probably is worth looking a bit harder at what exactly would be > the costs of simply recommending some standard elements to go into > the value of the existing DAV:owner element. > > I assume that clients today are written to work really well when they > encounter a lock written by clients from the same vendor (since they > would have a detailed knowledge > of the structure of the information in DAV:owner), but at least > "blurt out" the information in DAV:owner when encountering a > lock from some other vendor's client. > > If we were to recommend some specific sub-elements for DAV:owner, > then existing clients would be unaffected when running against > existing servers (of course), and new clients would exhibit the > desired improved interoperability when running against new servers. > > It is only old clients from a given vendor running against new > servers from the same vendor that would see a hit, if the new > standardized DAV:owner fields can't be inserted without disrupting > the ability of old clients extracting the old information. > > In particular, since it is the new *clients* that will > be inserting these new fields, if we make sure that the > location of the new standard fields is sufficiently flexible, > then the new clients from a specific vendor > might be able to append these new fields to the > information they currently write in a way > that won't disrupt the ability from old clients *from that vendor* > being able to read the old information. > > So it might be worthwhile to first find out > if there is some way we could define the > location of the new fields such that new clients from a vendor could > can add them in without disrupting the behavior of their old clients. > > If there really is no way to do this, then we could add a second > DAV:formatted:owner field instead. > > Cheers, > Geoff > > > > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Monday, January 28, 2002 12:34 PM > To: Jason Crawford; Daniel Brotsky > Cc: Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > > Geoff, Julian, are we sure we can't just define DAV:owner (rather than a > > new field) more restrictively to comply with your Julian's proposal? > > We can't redefine DAV: owner. As you suggest, there are current deployed > uses of DAV:owner and there would indeed be transition issues. > > > Lisa, Geoff, Julian, Can you think out the interoperability > scenarios and > > issues of Julian's proposal? (I wasn't at the interops so I'm > > not familiar > > with the current uses of DAV:owner and how Julian's proposal affects the > > currently deployed systems and if there are transition issues.) > > Lisa > From w3c-dist-auth-request@w3.org Mon Jan 28 13:57:11 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05860 for ; Mon, 28 Jan 2002 13:57:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA04999; Mon, 28 Jan 2002 13:54:58 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 13:54:58 -0500 (EST) Resent-Message-Id: <200201281854.NAA04999@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA04979 for ; Mon, 28 Jan 2002 13:54:50 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-079218.rational.com [130.213.79.218]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA29086 for ; Mon, 28 Jan 2002 13:54:50 -0500 From: gclemm@rational.com Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Mon, 28 Jan 2002 13:53:49 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 13:53:49 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AF20@SUS-MA1IT01> To: w3c-dist-auth@w3c.org Date: Mon, 28 Jan 2002 13:53:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5851 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Actually, in retrospect, the cost of adding a new owner field to the DAV:lockowner property is so low, that it isn't even worth investigating whether or not the information can be wedged into the existing DAV:contact-uri-set (or whatever we want to call it) field. So sign me up as a supporter for just adding the new owner field with some standard elements defined for its value. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, January 28, 2002 1:30 PM To: w3c-dist-auth@w3c.org Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Interesting idea. However: 1) Let's assume that we adopt something along the line the DAV:contact-URI-set I proposed earlier, but put it *into* the existing DAV:owner element. We would just define that if a DAV:owner contains DAV:contact-URI-set, it's format must adhere to our "DTD". 2) Existing clients which do not add DAV:contact-URI-set aren't affected at all. 3) When will existing clients use DAV:contact-URI-set? I'd say never, because I just thought of this property name :-), and they shouldn't anyway because it's an element in the DAV: namespace (which is reserved for official WebDAV stuff). 4) The main problem will be new (updated) clients that want to support the new feature, while maintaining compatibility with old versions. The cleanest way would be not to interfere with the old element. Old stuff stays in DAV:lockinfo/DAV:owner, new stuff is put into DAV:lockinfo/DAV:contact-URI-set. 5) To find out whether 4) is a problem, we would have to check all existing clients that have the problem of assuming some specific format. MS Office (I think) always displays the concatenated text content of all text nodes, so it would still display something useful, however it might not look pretty. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of gclemm@rational.com > Sent: Monday, January 28, 2002 7:06 PM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > It probably is worth looking a bit harder at what exactly would be > the costs of simply recommending some standard elements to go into > the value of the existing DAV:owner element. > > I assume that clients today are written to work really well when they > encounter a lock written by clients from the same vendor (since they > would have a detailed knowledge > of the structure of the information in DAV:owner), but at least > "blurt out" the information in DAV:owner when encountering a > lock from some other vendor's client. > > If we were to recommend some specific sub-elements for DAV:owner, > then existing clients would be unaffected when running against > existing servers (of course), and new clients would exhibit the > desired improved interoperability when running against new servers. > > It is only old clients from a given vendor running against new > servers from the same vendor that would see a hit, if the new > standardized DAV:owner fields can't be inserted without disrupting > the ability of old clients extracting the old information. > > In particular, since it is the new *clients* that will > be inserting these new fields, if we make sure that the > location of the new standard fields is sufficiently flexible, > then the new clients from a specific vendor > might be able to append these new fields to the > information they currently write in a way > that won't disrupt the ability from old clients *from that vendor* > being able to read the old information. > > So it might be worthwhile to first find out > if there is some way we could define the > location of the new fields such that new clients from a vendor could > can add them in without disrupting the behavior of their old clients. > > If there really is no way to do this, then we could add a second > DAV:formatted:owner field instead. > > Cheers, > Geoff > > > > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Monday, January 28, 2002 12:34 PM > To: Jason Crawford; Daniel Brotsky > Cc: Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > > Geoff, Julian, are we sure we can't just define DAV:owner (rather than a > > new field) more restrictively to comply with your Julian's proposal? > > We can't redefine DAV: owner. As you suggest, there are current deployed > uses of DAV:owner and there would indeed be transition issues. > > > Lisa, Geoff, Julian, Can you think out the interoperability > scenarios and > > issues of Julian's proposal? (I wasn't at the interops so I'm > > not familiar > > with the current uses of DAV:owner and how Julian's proposal affects the > > currently deployed systems and if there are transition issues.) > > Lisa > From w3c-dist-auth-request@w3.org Mon Jan 28 14:34:00 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06696 for ; Mon, 28 Jan 2002 14:34:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA07976; Mon, 28 Jan 2002 14:32:19 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 14:32:19 -0500 (EST) Resent-Message-Id: <200201281932.OAA07976@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA07953 for ; Mon, 28 Jan 2002 14:32:14 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA02692 for ; Mon, 28 Jan 2002 14:32:13 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA471396; Mon, 28 Jan 2002 14:28:37 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0SJVNR102466; Mon, 28 Jan 2002 14:31:28 -0500 To: "Lisa Dusseault" Cc: "Daniel Brotsky" , "Clemm, Geoff" , "Julian Reschke" , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 28 Jan 2002 14:17:07 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 01/28/2002 02:31:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5852 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << We can't redefine DAV: owner. As you suggest, there are current deployed uses of DAV:owner and there would indeed be transition issues. >> If that's the case, let me take a stab at the transition situation of Julian's proposal. Julian proposes a second field for information called DAV:lockowner that is a child of DAV:lockinfo. The field is authored by the client and simply stored unmodifed by the server. Julian has defined it in such a way that it's clear what "unmodified" means. So... Old clients will write to DAV:owner only. Not to the new field. New clients presumably will write to both the old deprecated DAV:owner and the new DAV:lockowner. New servers will (attempt to) preserve both fields. What will old servers do if they receive a lock info with the new DAV:lockowner field but not the old DAV:owner field? What will old servers do if the client provides both? Do some of the interop folks know how current "old" servers are coded? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Jan 28 14:42:19 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06905 for ; Mon, 28 Jan 2002 14:42:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08500; Mon, 28 Jan 2002 14:41:24 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 14:41:24 -0500 (EST) Resent-Message-Id: <200201281941.OAA08500@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA08480 for ; Mon, 28 Jan 2002 14:41:16 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA04066 for ; Mon, 28 Jan 2002 14:41:15 -0500 Received: (qmail 7635 invoked by uid 0); 28 Jan 2002 19:40:42 -0000 Received: from p50824904.dip.t-dialin.net (HELO lisa) (80.130.73.4) by mail.gmx.net (mp007-rz3) with SMTP; 28 Jan 2002 19:40:42 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Lisa Dusseault" Cc: "Daniel Brotsky" , "Clemm, Geoff" , "Julian Reschke" , Date: Mon, 28 Jan 2002 20:40:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5853 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Monday, January 28, 2002 8:17 PM > To: Lisa Dusseault > Cc: Daniel Brotsky; Clemm, Geoff; Julian Reschke; w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > << > We can't redefine DAV: owner. As you suggest, there are current deployed > uses of DAV:owner and there would indeed be transition issues. > >> > If that's the case, let me take a stab at the transition situation of > Julian's proposal. > > Julian proposes a second field for information called > DAV:lockowner that is > a child of DAV:lockinfo. The field is authored by the client and simply > stored unmodifed by the server. Julian has defined it in such a way that > it's clear what "unmodified" means. > > So... > > Old clients will write to DAV:owner only. Not to the new field. > New clients presumably will write to both the old deprecated DAV:owner and > the new DAV:lockowner. > > New servers will (attempt to) preserve both fields. > > What will old servers do if they receive a lock info with the new > DAV:lockowner field but not the old DAV:owner field? What will > old servers > do if the client provides both? Do some of the interop folks know how > current "old" servers are coded? An old server that doesn't ignore the new element would be broken. Is anybody aware of a server that has this bug? From w3c-dist-auth-request@w3.org Mon Jan 28 14:44:18 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06978 for ; Mon, 28 Jan 2002 14:44:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08588; Mon, 28 Jan 2002 14:43:26 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 14:43:26 -0500 (EST) Resent-Message-Id: <200201281943.OAA08588@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA08560 for ; Mon, 28 Jan 2002 14:43:13 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-079218.rational.com [130.213.79.218]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA04242 for ; Mon, 28 Jan 2002 14:43:13 -0500 From: gclemm@rational.com Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Mon, 28 Jan 2002 14:42:11 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 14:42:11 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AF24@SUS-MA1IT01> To: w3c-dist-auth@w3c.org Date: Mon, 28 Jan 2002 14:42:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5854 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Jason Crawford [mailto:ccjason@us.ibm.com] Julian proposes a second field for information called DAV:lockowner that is a child of DAV:lockinfo. The field is authored by the client and simply stored unmodifed by the server. Julian has defined it in such a way that it's clear what "unmodified" means. Old clients will write to DAV:owner only. Not to the new field. New clients presumably will write to both the old deprecated DAV:owner and the new DAV:lockowner. Or if they don't care about old clients that depend on DAV:owner, they will just write to DAV:lockowner (DAV:owner was always optional, and so should be DAV:lockowner) New servers will (attempt to) preserve both fields. Yes. What will old servers do if they receive a lock info with the new DAV:lockowner field but not the old DAV:owner field? What will old servers do if the client provides both? In either case, they must ignore the DAV:lockowner field, since that is what WebDAV requires (ignore unknown elements). Do some of the interop folks know how current "old" servers are coded? Not me, but if they have a "bug" (i.e. they choke on unknown fields coming in from LOCK), that shouldn't stop us from evolving WebDAV in the way it was intended to be evolved. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Jan 28 17:20:27 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10072 for ; Mon, 28 Jan 2002 17:20:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA27008; Mon, 28 Jan 2002 12:40:32 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 12:40:32 -0500 (EST) Resent-Message-Id: <200201281740.MAA27008@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA26613 for ; Mon, 28 Jan 2002 12:40:02 -0500 (EST) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA15123 for ; Mon, 28 Jan 2002 12:36:33 -0500 Received: from [216.36.111.249] (HELO moose) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 17943535; Mon, 28 Jan 2002 09:33:55 -0800 From: "Lisa Dusseault" To: "Jason Crawford" , "Daniel Brotsky" Cc: "Clemm, Geoff" , , "Julian Reschke" Date: Mon, 28 Jan 2002 09:34:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5847 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Geoff, Julian, are we sure we can't just define DAV:owner (rather than a > new field) more restrictively to comply with your Julian's proposal? We can't redefine DAV: owner. As you suggest, there are current deployed uses of DAV:owner and there would indeed be transition issues. > Lisa, Geoff, Julian, Can you think out the interoperability scenarios and > issues of Julian's proposal? (I wasn't at the interops so I'm > not familiar > with the current uses of DAV:owner and how Julian's proposal affects the > currently deployed systems and if there are transition issues.) Lisa From w3c-dist-auth-request@w3.org Mon Jan 28 17:22:29 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10117 for ; Mon, 28 Jan 2002 17:22:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA00981; Mon, 28 Jan 2002 10:40:39 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 10:40:39 -0500 (EST) Resent-Message-Id: <200201281540.KAA00981@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA00561 for ; Mon, 28 Jan 2002 10:40:03 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA11785 for ; Mon, 28 Jan 2002 10:11:48 -0500 Received: (qmail 2369 invoked by uid 0); 28 Jan 2002 15:11:17 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 28 Jan 2002 15:11:17 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Daniel Brotsky" Cc: "Clemm, Geoff" , , "Julian Reschke" Date: Mon, 28 Jan 2002 16:11:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5845 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Monday, January 28, 2002 4:07 PM > To: Daniel Brotsky > Cc: Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > Julian's XLink based proposal sounds fine to me. > > Dan, I assume you understand and sympathize with Geoff's hesitance to > having the server try to reveal the creator of the lock. Is there > any other > info about a lock that ACL's don't provide that you feel needs to be > provided? > > Geoff, Julian, are we sure we can't just define DAV:owner (rather than a > new field) more restrictively to comply with your Julian's proposal? My understanding is that recent interoperability tests have shown that existing clients WILL break if the server doesn't round-trip whatever the client provided. So we can't restrict it. > Lisa, Geoff, Julian, Can you think out the interoperability scenarios and > issues of Julian's proposal? (I wasn't at the interops so I'm > not familiar > with the current uses of DAV:owner and how Julian's proposal affects the > currently deployed systems and if there are transition issues.) My proposal shouldn't affect interoperability because it's a new child element. From w3c-dist-auth-request@w3.org Mon Jan 28 19:12:54 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11757 for ; Mon, 28 Jan 2002 19:12:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA00735; Mon, 28 Jan 2002 19:07:42 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 19:07:42 -0500 (EST) Resent-Message-Id: <200201290007.TAA00735@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA00713 for ; Mon, 28 Jan 2002 19:07:29 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA22115 for ; Mon, 28 Jan 2002 19:07:25 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g0T08H108357 for ; Mon, 28 Jan 2002 16:08:17 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g0T05dY00325 for ; Mon, 28 Jan 2002 16:05:39 -0800 (PST) Received: from [153.32.159.62] ([153.32.159.62]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GQOAZC00.A4Y; Mon, 28 Jan 2002 16:06:48 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Mon, 28 Jan 2002 16:06:51 -0800 To: "Julian Reschke" From: Daniel Brotsky Cc: "Jason Crawford" , "Clemm, Geoff" , , "Julian Reschke" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5855 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: So I have followed Julian's advice and gone back and reviewed all the mail around this. Here's my interpretation: 1. There are only 5 people participating in this thread (Geoff, Julian, Lisa, Jason, and me). I note this only because it's worrisome to me to declare "consensus" based on such a small discussion. Also because it explains why the rest of this analysis actually names names, so to speak :^). 2. All 5 of us seem to feel that leaving DAV:owner alone and under the control of clients is the only thing that will allow existing clients to keep working. Conclusion: I think we have "consensus" that DAV:owner should be under client control and that the spec should state this. 3. Geoff and Julian seem to feel that we should "deprecate" DAV:owner, which I think means they want the spec to say that clients should not rely on the DAV:owner field. They argue that clients can not "interoperate" using this field because its value is unspecified. I strongly disagree with this, for reasons I've often stated but will reiterate briefly: I claim that having a "guaranteed dead" property writeable as part of a LOCK request is a very valuable feature of the protocol precisely because it allows clients to interoperate using conventions *outside* of the protocol. Conclusion: We don't have consensus about deprecating DAV:owner. 4. Lisa and I (more me than her, but maybe I convinced her :^) both seemed to feel that clients should have a way of asking about who owns a lock in order to figure out whether a discovered lock is owned by them. Geoff replied that, since we're leaving DAV:owner in the hands of the client, then presumably a client could use that field to determine whether he owned a lock. I take from Lisa's lack of response that she found that argument persuasive. I certainly did. (Geoff and maybe Julian also seemed to feel strongly that it's insecure for servers to give out this kind of information, but while I agree with this I don't think that argument is on point: we weren't talking about mandating it, just allowing it.) Conclusion: We have consensus that servers shouldn't have to tell clients who owns locks, and further that we don't need a standard way for clients to ask about this. 5. Geoff and Julian both seem to feel strongly that there should be some protocol-specified way for clients to communicate conventionally with each other about who owns a lock. They seem to feel that this was what DAV:owner was intended to be about in the first place, so I think they are both agreed about introducing DAV:lockowner as such a thing and deprecating DAV:owner. Jason seemed to find this proposal sensible given the conclusion of (2). Neither Lisa nor I have had anything to say about this. Conclusion: There's a proposal on the table to add DAV:lockowner that's probably linked to the proposal to deprecate DAV:owner. But there's been essentially no discussion of it, even by the 5 people who've been active so far. Bottom line: At this point, I think our two points of consensus are: 1. DAV:owner is owned by clients, and the spec should say this. 2. We are not going to add a way for clients to ask who owns a lock. I would suggest we close out this issue on that consensus. I have no objection to adding an issue about adding a DAV:lockowner field (based on Julian's proposal), but I have not seen any evidence that actual clients are asking for this; it seems to be more of a hygiene issue than anything else. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Mon Jan 28 19:45:26 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12279 for ; Mon, 28 Jan 2002 19:45:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA04008; Mon, 28 Jan 2002 19:43:47 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 19:43:47 -0500 (EST) Resent-Message-Id: <200201290043.TAA04008@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA03987 for ; Mon, 28 Jan 2002 19:43:42 -0500 (EST) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA26538 for ; Mon, 28 Jan 2002 19:43:41 -0500 Received: from [216.36.111.249] (HELO moose) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 18008242; Mon, 28 Jan 2002 16:41:07 -0800 From: "Lisa Dusseault" To: "Daniel Brotsky" , "Julian Reschke" Cc: "Jason Crawford" , "Clemm, Geoff" , , "Julian Reschke" Date: Mon, 28 Jan 2002 16:41:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5856 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Bottom line: At this point, I think our two points of consensus are: > > 1. DAV:owner is owned by clients, and the spec should say this. > > 2. We are not going to add a way for clients to ask who owns a lock. > > I would suggest we close out this issue on that consensus. I have no > objection to adding an issue about adding a DAV:lockowner field > (based on Julian's proposal), but I have not seen any evidence that > actual clients are asking for this; it seems to be more of a hygiene > issue than anything else. I should also make it clear that there are two possible ways to add a feature like DAV:lockowner: (a) Add it to the base DAV spec when we rewrite it to go to Draft Standard. Then we would be delayed getting an RFC number with Draft Standard until we prove interoperability with DAV:lockowner (b) Add it to a DAV extension. When it comes to adding features, I much prefer (b). We can delete and disambiguate features in RFC2518 and move toward Draft Standard status quickly, based on much existing proven interoperability. We cannot add features with the same speed because it requires us to wait for product implementors to get around to doing the new feature. So my position is pretty similar to Dan's: make it clear that DAV:owner is owned by clients, and don't add any way for servers to insert lock owner principal information. I prefer any other extensions to DAV to be done outside the base spec since they are clearly not needed for basic interoperability and would delay Draft Standard. Lisa From w3c-dist-auth-request@w3.org Mon Jan 28 23:13:15 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16751 for ; Mon, 28 Jan 2002 23:13:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA26573; Mon, 28 Jan 2002 23:12:13 -0500 (EST) Resent-Date: Mon, 28 Jan 2002 23:12:13 -0500 (EST) Resent-Message-Id: <200201290412.XAA26573@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA26494 for ; Mon, 28 Jan 2002 23:11:50 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-079218.rational.com [130.213.79.218]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA17331 for ; Mon, 28 Jan 2002 23:11:50 -0500 From: gclemm@rational.com Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Mon, 28 Jan 2002 23:10:48 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 23:10:48 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105A31CA3@SUS-MA1IT01> To: w3c-dist-auth@w3c.org Date: Mon, 28 Jan 2002 23:10:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5857 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: That is fine with me. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Monday, January 28, 2002 7:42 PM To: Daniel Brotsky; Julian Reschke Cc: Jason Crawford; Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > Bottom line: At this point, I think our two points of consensus are: > > 1. DAV:owner is owned by clients, and the spec should say this. > > 2. We are not going to add a way for clients to ask who owns a lock. > > I would suggest we close out this issue on that consensus. ... So my position is pretty similar to Dan's: make it clear that DAV:owner is owned by clients, and don't add any way for servers to insert lock owner principal information. I prefer any other extensions to DAV to be done outside the base spec since they are clearly not needed for basic interoperability and would delay Draft Standard. From w3c-dist-auth-request@w3.org Tue Jan 29 03:28:05 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28000 for ; Tue, 29 Jan 2002 03:28:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA21623; Tue, 29 Jan 2002 03:26:56 -0500 (EST) Resent-Date: Tue, 29 Jan 2002 03:26:56 -0500 (EST) Resent-Message-Id: <200201290826.DAA21623@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA21546 for ; Tue, 29 Jan 2002 03:26:30 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA18045 for ; Tue, 29 Jan 2002 03:26:30 -0500 Received: (qmail 14867 invoked by uid 0); 29 Jan 2002 08:26:26 -0000 Received: from p50825c88.dip.t-dialin.net (HELO lisa) (80.130.92.136) by mail.gmx.net (mp015-rz3) with SMTP; 29 Jan 2002 08:26:26 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Tue, 29 Jan 2002 09:26:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5858 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, January 29, 2002 1:42 AM > To: Daniel Brotsky; Julian Reschke > Cc: Jason Crawford; Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > ... > > So my position is pretty similar to Dan's: make it clear that DAV:owner is > owned by clients, and don't add any way for servers to insert lock owner > principal information. I prefer any other extensions to DAV to be done > outside the base spec since they are clearly not needed for basic > interoperability and would delay Draft Standard. One could also take the position that we're *fixing* an interoperability problem. The current RFC says [1]: "The owner XML element provides information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who owns a lock." Right now it doesn't, because it's format is unspecified (and examples in the draft are inconsistent). To understand the implications of adding a new field, it would be useful to have some idea about which timeframe we speak. Any guess how long it will take until a new edition could be submitted? If it's a matter of several months, I'd suggest adding the new element (it shouldn't hurt as long it's optional, well-defined, and we can demonstrate interoperability). [1] From w3c-dist-auth-request@w3.org Tue Jan 29 09:45:08 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04587 for ; Tue, 29 Jan 2002 09:45:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA05861; Tue, 29 Jan 2002 09:42:26 -0500 (EST) Resent-Date: Tue, 29 Jan 2002 09:42:26 -0500 (EST) Resent-Message-Id: <200201291442.JAA05861@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA05821 for ; Tue, 29 Jan 2002 09:42:12 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA10440 for ; Tue, 29 Jan 2002 09:42:12 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA459054; Tue, 29 Jan 2002 09:38:36 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0TEfdZ11588; Tue, 29 Jan 2002 09:41:39 -0500 To: "Lisa Dusseault" Cc: "Daniel Brotsky" , "Clemm, Geoff" , "Julian Reschke" , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 29 Jan 2002 09:36:14 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 01/29/2002 09:41:38 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5859 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > (b) Add it to a DAV extension. Given the current grammar, have we left a route to do this? Not as a child of DAV:lockinfo I believe. Perhaps as a child of DAV:owner? I believe one of the things we were going to do was define what it meant for the server to maintain DAV:owner. At least one person thought there was some ambiguity there. Do we still feel that this is an issue? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Jan 29 09:51:15 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04737 for ; Tue, 29 Jan 2002 09:51:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA06326; Tue, 29 Jan 2002 09:50:09 -0500 (EST) Resent-Date: Tue, 29 Jan 2002 09:50:09 -0500 (EST) Resent-Message-Id: <200201291450.JAA06326@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA06296 for ; Tue, 29 Jan 2002 09:49:55 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA12065 for ; Tue, 29 Jan 2002 09:49:55 -0500 Received: (qmail 14485 invoked by uid 0); 29 Jan 2002 14:49:23 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 29 Jan 2002 14:49:23 -0000 From: "Julian Reschke" To: "Jason Crawford" , Date: Tue, 29 Jan 2002 15:49:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5860 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Tuesday, January 29, 2002 3:36 PM > To: Lisa Dusseault > Cc: Daniel Brotsky; Clemm, Geoff; Julian Reschke; w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > > (b) Add it to a DAV extension. > > Given the current grammar, have we left a route to do this? Not as a > child of DAV:lockinfo I believe. Perhaps as a child of DAV:owner? Sure. WebDAV explicitly states that servers and clients MUST ignore unknown element. > I believe one of the things we were going to do was define what it meant > for the server to maintain DAV:owner. At least one person thought there > was some ambiguity there. Do we still feel that this is an issue? Yes. 1) The examples in RFC2518 do *not* preserve DAV:owner (watch out for whitespace!). 2) We currently don't have a clear definition about *what* needs to preserved as a property value (this is already on the issues list). Whatever applies to a property value should reply to the DAV:owner element as well. Julian From w3c-dist-auth-request@w3.org Tue Jan 29 14:26:10 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17655 for ; Tue, 29 Jan 2002 14:26:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA13509; Tue, 29 Jan 2002 14:24:57 -0500 (EST) Resent-Date: Tue, 29 Jan 2002 14:24:57 -0500 (EST) Resent-Message-Id: <200201291924.OAA13509@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA13450 for ; Tue, 29 Jan 2002 14:24:38 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA23665 for ; Tue, 29 Jan 2002 14:24:38 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g0TJMl314475 for ; Tue, 29 Jan 2002 11:22:47 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g0TJMpY20150 for ; Tue, 29 Jan 2002 11:22:51 -0800 (PST) Received: from [153.32.158.130] ([153.32.158.130]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GQPSK200.LE2; Tue, 29 Jan 2002 11:24:02 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 29 Jan 2002 11:12:32 -0800 To: "Julian Reschke" From: Daniel Brotsky Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5861 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 9:26 AM +0100 1/29/02, Julian Reschke wrote: > > From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault >> Sent: Tuesday, January 29, 2002 1:42 AM >> To: Daniel Brotsky; Julian Reschke >> Cc: Jason Crawford; Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke >> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER >> >> ... >> >> So my position is pretty similar to Dan's: make it clear that DAV:owner is >> owned by clients, and don't add any way for servers to insert lock owner >> principal information. I prefer any other extensions to DAV to be done >> outside the base spec since they are clearly not needed for basic >> interoperability and would delay Draft Standard. > >One could also take the position that we're *fixing* an interoperability >problem. The current RFC says [1]: > >"The owner XML element provides information sufficient for either directly >contacting a principal (such as a telephone number or Email URI), or for >discovering the principal (such as the URL of a homepage) who owns a lock." > >Right now it doesn't, because it's format is unspecified (and examples in >the draft are inconsistent). My intuition is that the quoted paragraph addresses an interoperability "problem" that doesn't exist: client programs needing to contact people. The actual interoperability problem faced by (at least) Adobe clients was for clients needing to contact clients, or more precisely: our clients use specific conventions about lock ownership that the spec doesn't provide for, and they need to keep this conventional information with the lock in a way that works against any server and can be discovered. Our solution was to interpret this paragraph more along the lines of: The owner XML element provides a way for clients to store owner-controlled conventional information with the lock that other clients can discover and make use of. I would propose that we further clarify this with language along the lines of: Since the possible client conventions around such information are beyond the scope of this specification, servers MUST NOT rewrite such information (i.e., the DAV:owner field must be treated as a dead property). In addition, clients who make conventional use of the DAV:owner field SHOULD document these conventions for use by other clients. >To understand the implications of adding a new field, it would be useful to >have some idea about which timeframe we speak. Any guess how long it will >take until a new edition could be submitted? If it's a matter of several >months, I'd suggest adding the new element (it shouldn't hurt as long it's >optional, well-defined, and we can demonstrate interoperability). > > >[1] My belief is that there are three real-life interoperability problems that are left unaddressed by this DAV:owner clarification and that would be worth adding a new element for: 1. a way for clients to specify a human-readable string that other clients should display in order to identify the lock owner. 2. a way for clients to specify contact addresses in known protocols (e.g., mailto:, http:) whereby human users can contact (or get information about) the lock owner (or lock purpose, etc.). I would not be averse to adding a DAV:ownercontact field in this spec go-round to address this problem. In general I'm in agreement with Julian that adding a new field to the lock discovery information would likely not be damaging to earlier clients. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Tue Jan 29 14:39:09 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18762 for ; Tue, 29 Jan 2002 14:39:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15340; Tue, 29 Jan 2002 14:37:41 -0500 (EST) Resent-Date: Tue, 29 Jan 2002 14:37:41 -0500 (EST) Resent-Message-Id: <200201291937.OAA15340@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA15311 for ; Tue, 29 Jan 2002 14:37:24 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA27077 for ; Tue, 29 Jan 2002 14:37:24 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g0TJcHm11809 for ; Tue, 29 Jan 2002 11:38:17 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g0TJZaY22553 for ; Tue, 29 Jan 2002 11:35:36 -0800 (PST) Received: from [153.32.158.130] ([153.32.158.130]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GQPT5B00.QAW; Tue, 29 Jan 2002 11:36:47 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 29 Jan 2002 11:36:26 -0800 To: "Julian Reschke" From: Daniel Brotsky Cc: "Jason Crawford" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5862 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 3:49 PM +0100 1/29/02, Julian Reschke wrote: > > From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford >> Sent: Tuesday, January 29, 2002 3:36 PM >> To: Lisa Dusseault >> Cc: Daniel Brotsky; Clemm, Geoff; Julian Reschke; w3c-dist-auth@w3c.org >> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER >> >> >> >> > (b) Add it to a DAV extension. >> >> Given the current grammar, have we left a route to do this? Not as a >> child of DAV:lockinfo I believe. Perhaps as a child of DAV:owner? > >Sure. WebDAV explicitly states that servers and clients MUST ignore unknown >element. What does this "Sure" apply to, Julian? Do you mean that new children of can still be introduced? Or do you mean of ? > >> I believe one of the things we were going to do was define what it meant >> for the server to maintain DAV:owner. At least one person thought there >> was some ambiguity there. Do we still feel that this is an issue? > >Yes. > >1) The examples in RFC2518 do *not* preserve DAV:owner (watch out for >whitespace!). > >2) We currently don't have a clear definition about *what* needs to >preserved as a property value (this is already on the issues list). Whatever >applies to a property value should reply to the DAV:owner element as well. That's why I used my language about "dead properties" in the earlier message: we need to make sure the resolution to that issue drives the DAV:owner issue. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Tue Jan 29 16:09:36 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21078 for ; Tue, 29 Jan 2002 16:09:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28047; Tue, 29 Jan 2002 16:08:34 -0500 (EST) Resent-Date: Tue, 29 Jan 2002 16:08:34 -0500 (EST) Resent-Message-Id: <200201292108.QAA28047@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA27939 for ; Tue, 29 Jan 2002 16:08:19 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA16924 for ; Tue, 29 Jan 2002 16:08:18 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA245224; Tue, 29 Jan 2002 16:04:42 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0TL7jZ134296; Tue, 29 Jan 2002 16:07:45 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 29 Jan 2002 15:53:55 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 01/29/2002 04:07:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5863 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << WebDAV explicitly states that servers and clients MUST ignore unknown element. >> FWIW.... By "ignore" I believe you are refering to section 14 and 23.3.2.2. Taken together these sections suggest that "ignore" means that if a client sends in an extra field in lockinfo, the field will be (and MUST be) thrown away and not stored... but the server will not choke. Simiarly... if for some reason a server passes back a new field, the client MUST ignore it (as if it wasn't there) and not choke on it. It's also worded in a way that a receiver is free to save/process a field that it is familiar with even if it's not defined in the spec. The pivotal word here in my explanation is "familiar". This provides elbow room for new designs using new fields. So... we know that all 2518 compliant servers will throw away any new field of DAV:lockinfo we submit. And that current 2518 compliant clients will not choke if the server sends the extra field. This means that a transition strategy for adding a new field of DAV:lockinfo should be straight forward and not cause old clients to break. I believe that a new element within DAV:owner is a little different. The DTD definition for it is "ALL" so I doubt the above rules apply. But after our clarification, we know that the server will store whatever we put there. We just haven't defined the details of that round trip behavior. Beyond that, we have to consider how current clients use what they find in that field. This might require some interop testing. << 1) The examples in RFC2518 do *not* preserve DAV:owner (watch out for whitespace!). 2) We currently don't have a clear definition about *what* needs to preserved as a property value (this is already on the issues list). Whatever applies to a property value should reply to the DAV:owner element as well. >> I've updated my local copy of the issues list to reflect these too items. I'll watch to see how discussion about contact-URL-list goes. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Jan 30 07:08:14 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15787 for ; Wed, 30 Jan 2002 07:08:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA03303; Tue, 29 Jan 2002 16:41:50 -0500 (EST) Resent-Date: Tue, 29 Jan 2002 16:41:50 -0500 (EST) Resent-Message-Id: <200201292141.QAA03303@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA02817 for ; Tue, 29 Jan 2002 16:40:36 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA28215 for ; Tue, 29 Jan 2002 14:41:30 -0500 Received: (qmail 25700 invoked by uid 0); 29 Jan 2002 19:40:59 -0000 Received: from p508252dd.dip.t-dialin.net (HELO lisa) (80.130.82.221) by mail.gmx.net (mp013-rz3) with SMTP; 29 Jan 2002 19:40:59 -0000 From: "Julian Reschke" To: "Daniel Brotsky" , "Julian Reschke" Cc: "Jason Crawford" , Date: Tue, 29 Jan 2002 20:40:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5864 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky > Sent: Tuesday, January 29, 2002 8:36 PM > To: Julian Reschke > Cc: Jason Crawford; w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > At 3:49 PM +0100 1/29/02, Julian Reschke wrote: > > > From: w3c-dist-auth-request@w3.org > >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > >> Sent: Tuesday, January 29, 2002 3:36 PM > >> To: Lisa Dusseault > >> Cc: Daniel Brotsky; Clemm, Geoff; Julian Reschke; > w3c-dist-auth@w3c.org > >> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > >> > >> > >> > >> > (b) Add it to a DAV extension. > >> > >> Given the current grammar, have we left a route to do this? Not as a > >> child of DAV:lockinfo I believe. Perhaps as a child of DAV:owner? > > > >Sure. WebDAV explicitly states that servers and clients MUST > ignore unknown > >element. > > What does this "Sure" apply to, Julian? Do you mean that new > children of can still be introduced? Or do you mean > of ? Sorry :-) Sure, we can extend DAV:lockinfo, because we *don't* want to introduce semantice for for DAV:owner. > >> I believe one of the things we were going to do was define > what it meant > >> for the server to maintain DAV:owner. At least one person > thought there > >> was some ambiguity there. Do we still feel that this is an issue? > > > >Yes. > > > >1) The examples in RFC2518 do *not* preserve DAV:owner (watch out for > >whitespace!). > > > >2) We currently don't have a clear definition about *what* needs to > >preserved as a property value (this is already on the issues > list). Whatever > >applies to a property value should reply to the DAV:owner > element as well. > > That's why I used my language about "dead properties" in the earlier > message: we need to make sure the resolution to that issue drives the > DAV:owner issue. Agreed. Good plan. From w3c-dist-auth-request@w3.org Thu Jan 31 10:23:31 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29349 for ; Thu, 31 Jan 2002 10:23:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA27693; Thu, 31 Jan 2002 10:18:49 -0500 (EST) Resent-Date: Thu, 31 Jan 2002 10:18:49 -0500 (EST) Resent-Message-Id: <200201311518.KAA27693@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA27636 for ; Thu, 31 Jan 2002 10:18:32 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA15411 for ; Thu, 31 Jan 2002 10:18:33 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA48868; Thu, 31 Jan 2002 10:14:56 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0VFHx1173118; Thu, 31 Jan 2002 10:18:00 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 30 Jan 2002 23:16:03 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 01/31/2002 10:17:59 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5865 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I've added this to my local copy of the issues list. Anyone want to comment on it? Support? Dissent? Julian alluded to the possibility of keepalive going away. FWIW... I don't see anything like that listed on the issues list. J. ------------------------------ Julian wrote... -------------------- Hi. Currently, RFC2518 says in 12.12.1 [1]: So individual properties are identified by "href" (which doesn't make sense in the general case). So (assuming that propertybehaviour/keepalive isn't dropped anyway), this will need to be changed to: where DAV:prop contains property elements. Julian [1] ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jan 31 10:23:31 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29352 for ; Thu, 31 Jan 2002 10:23:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA27741; Thu, 31 Jan 2002 10:18:59 -0500 (EST) Resent-Date: Thu, 31 Jan 2002 10:18:59 -0500 (EST) Resent-Message-Id: <200201311518.KAA27741@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA27640 for ; Thu, 31 Jan 2002 10:18:33 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA15417 for ; Thu, 31 Jan 2002 10:18:34 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA81012 for ; Thu, 31 Jan 2002 10:14:57 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0VFI11173122 for ; Thu, 31 Jan 2002 10:18:01 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 30 Jan 2002 23:41:46 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 01/31/2002 10:18:00 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5866 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'm closing out the issue of HOW_TO_IDENTIFY_LOCK_OWNER I've added the issue of the server maintaining the unaltered value of DAV:owner that the locking client provides. No further discussion neccessary. I've added an issue to note that the spec should make it clear that the roundtrip behavior of DAV:owner should match the round trip behavior of dead properties. The issue for that one is PROP_ROUNDTRIP and we still need to resolve it. I think we've resolved that we CAN add a more clearly defined property as a child of DAV:lockinfo, but I've not added an issue on this. If we still want to pursue a new field, I'll add an issue for it. From w3c-dist-auth-request@w3.org Thu Jan 31 10:30:04 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29636 for ; Thu, 31 Jan 2002 10:30:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA28992; Thu, 31 Jan 2002 10:25:25 -0500 (EST) Resent-Date: Thu, 31 Jan 2002 10:25:25 -0500 (EST) Resent-Message-Id: <200201311525.KAA28992@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA28916 for ; Thu, 31 Jan 2002 10:25:09 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA16658 for ; Thu, 31 Jan 2002 10:25:09 -0500 Received: (qmail 24981 invoked by uid 0); 31 Jan 2002 15:24:37 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 31 Jan 2002 15:24:37 -0000 From: "Julian Reschke" To: "Jason Crawford" , Date: Thu, 31 Jan 2002 16:24:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5867 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Thursday, January 31, 2002 5:42 AM > To: w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > I'm closing out the issue of HOW_TO_IDENTIFY_LOCK_OWNER > > I've added the issue of the server maintaining the unaltered value of > DAV:owner that the locking client provides. No further discussion > neccessary. > > I've added an issue to note that the spec should make it clear that the > roundtrip behavior of DAV:owner should match the round trip behavior of > dead properties. The issue for that one is PROP_ROUNDTRIP and we still > need to resolve it. Sounds good. > I think we've resolved that we CAN add a more clearly defined > property as a > child of DAV:lockinfo, but I've not added an issue on this. If we still > want to pursue a new field, I'll add an issue for it. I think we should to that. If the concern is that we can't add new features to the RFC revision, I'd like to propose that we collect all things that *extend* WebDAV (and for which we have a consensus) into a new, separate draft (which could be submitted as experimental protocol at the time the RFC2518 revision is done). From w3c-dist-auth-request@w3.org Thu Jan 31 10:54:38 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00555 for ; Thu, 31 Jan 2002 10:54:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA06781; Thu, 31 Jan 2002 10:50:27 -0500 (EST) Resent-Date: Thu, 31 Jan 2002 10:50:27 -0500 (EST) Resent-Message-Id: <200201311550.KAA06781@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA06659 for ; Thu, 31 Jan 2002 10:50:12 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA22968 for ; Thu, 31 Jan 2002 10:50:11 -0500 Received: from apu [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 31 Jan 2002 16:49:39 +0100 From: "Stefan Eissing" To: "Jason Crawford" , "Julian Reschke" Cc: Date: Thu, 31 Jan 2002 16:49:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5868 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > [...] > Julian alluded to the possibility of keepalive going away. FWIW... I > don't see anything like that listed on the issues list. The issue is not explicitly on the list, however it is related to COPY_LIVE_PROPS. The issues I have with keepAlive are a) how does the client know which property is live in the first place? b) deltaV copy semantics forbid using keepAlive on version properties c) If the destination is on another server, WebDAV has no means to fulfill keepAlive. It is not possible to know if the remote server knows the requested live props. d) Is there any server/client using it? (I have not seen any) I would propose to 1) remove keepalive, maybe allow omit 2) change default copy behaviour to _not_ copy live properties //Stefan > J. > > ------------------------------ Julian wrote... -------------------- > Hi. > > Currently, RFC2518 says in 12.12.1 [1]: > > > > So individual properties are identified by "href" (which doesn't > make sense > in the general case). > > So (assuming that propertybehaviour/keepalive isn't dropped anyway), this > will need to be changed to: > > > > where DAV:prop contains property elements. > > Julian > > > [1] > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > > From w3c-dist-auth-request@w3.org Thu Jan 31 12:49:47 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05317 for ; Thu, 31 Jan 2002 12:49:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA25977; Thu, 31 Jan 2002 12:45:14 -0500 (EST) Resent-Date: Thu, 31 Jan 2002 12:45:14 -0500 (EST) Resent-Message-Id: <200201311745.MAA25977@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA25943 for ; Thu, 31 Jan 2002 12:45:04 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-079218.rational.com [130.213.79.218]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA11546 for ; Thu, 31 Jan 2002 12:45:04 -0500 From: gclemm@rational.com Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Thu, 31 Jan 2002 12:44:02 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 12:44:02 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105B8100F@SUS-MA1IT01> To: w3c-dist-auth@w3.org Date: Thu, 31 Jan 2002 12:44:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5869 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I do remember a discussion of keepalive going away because it appears not to be implemented (and I certainly support it going away). That is my preferred solution to this issue. In any case "REMOVING_KEEPALIVE" (or some other appropriate name for it) should be on the issues list. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Wednesday, January 30, 2002 11:16 PM To: Julian Reschke Cc: w3c-dist-auth@w3.org Subject: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE I've added this to my local copy of the issues list. Anyone want to comment on it? Support? Dissent? Julian alluded to the possibility of keepalive going away. FWIW... I don't see anything like that listed on the issues list. J. ------------------------------ Julian wrote... -------------------- Hi. Currently, RFC2518 says in 12.12.1 [1]: So individual properties are identified by "href" (which doesn't make sense in the general case). So (assuming that propertybehaviour/keepalive isn't dropped anyway), this will need to be changed to: where DAV:prop contains property elements. Julian [1] ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jan 31 12:57:59 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05764 for ; Thu, 31 Jan 2002 12:57:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26938; Thu, 31 Jan 2002 12:50:46 -0500 (EST) Resent-Date: Thu, 31 Jan 2002 12:50:46 -0500 (EST) Resent-Message-Id: <200201311750.MAA26938@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA26906 for ; Thu, 31 Jan 2002 12:50:39 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-079218.rational.com [130.213.79.218]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA12533 for ; Thu, 31 Jan 2002 12:50:40 -0500 From: gclemm@rational.com Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it00.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Thu, 31 Jan 2002 12:49:38 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 12:49:38 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AF47@SUS-MA1IT01> To: w3c-dist-auth@w3.org Date: Thu, 31 Jan 2002 12:49:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5870 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Stefan's proposal. (I would get rid of "omit" as well). Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] The issues I have with keepAlive are a) how does the client know which property is live in the first place? b) deltaV copy semantics forbid using keepAlive on version properties c) If the destination is on another server, WebDAV has no means to fulfill keepAlive. It is not possible to know if the remote server knows the requested live props. d) Is there any server/client using it? (I have not seen any) I would propose to 1) remove keepalive, maybe allow omit 2) change default copy behaviour to _not_ copy live properties From w3c-dist-auth-request@w3.org Thu Jan 31 13:11:49 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06328 for ; Thu, 31 Jan 2002 13:11:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01322; Thu, 31 Jan 2002 13:07:35 -0500 (EST) Resent-Date: Thu, 31 Jan 2002 13:07:35 -0500 (EST) Resent-Message-Id: <200201311807.NAA01322@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01169 for ; Thu, 31 Jan 2002 13:07:17 -0500 (EST) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA15814 for ; Thu, 31 Jan 2002 13:07:17 -0500 Received: from [216.36.111.249] (HELO moose) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 18299763; Thu, 31 Jan 2002 10:04:29 -0800 From: "Lisa Dusseault" To: "Stefan Eissing" , "Jason Crawford" , "Julian Reschke" Cc: Date: Thu, 31 Jan 2002 10:05:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5871 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit There is a much deeper issue with keepalive, and that is that no client at the interop claimed to use the feature. Therefore interoperability has not been, and cannot easily be, demonstrated. Are there now clients out there that can demonstrate that keepalive works? Or is it one of those ideas that just isn't useful enough to clients for them to implement? If its not useful enough for clients to implement, then it should be removed from WebDAV so the protocol can go to the next phase of standardization. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Thursday, January 31, 2002 7:50 AM > To: Jason Crawford; Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > [...] > > Julian alluded to the possibility of keepalive going away. FWIW... I > > don't see anything like that listed on the issues list. > > The issue is not explicitly on the list, however it is related > to COPY_LIVE_PROPS. > The issues I have with keepAlive are > a) how does the client know which property is live in the first place? > b) deltaV copy semantics forbid using keepAlive on version properties > c) If the destination is on another server, WebDAV has no means to > fulfill keepAlive. It is not possible to know if the remote server > knows the requested live props. > d) Is there any server/client using it? (I have not seen any) > > I would propose to > 1) remove keepalive, maybe allow omit > 2) change default copy behaviour to _not_ copy live properties > > //Stefan > > > J. > > > > ------------------------------ Julian wrote... -------------------- > > Hi. > > > > Currently, RFC2518 says in 12.12.1 [1]: > > > > > > > > So individual properties are identified by "href" (which doesn't > > make sense > > in the general case). > > > > So (assuming that propertybehaviour/keepalive isn't dropped > anyway), this > > will need to be changed to: > > > > > > > > where DAV:prop contains property elements. > > > > Julian > > > > > > [1] > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > >