From w3c-dist-auth-request@w3.org Thu May 2 17:01: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 RAA07195 for ; Thu, 2 May 2002 17:00:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA07129; Thu, 2 May 2002 16:59:38 -0400 (EDT) Resent-Date: Thu, 2 May 2002 16:59:38 -0400 (EDT) Resent-Message-Id: <200205022059.QAA07129@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA07087 for ; Thu, 2 May 2002 16:59:28 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA01825 for ; Thu, 2 May 2002 16:59:28 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g42Kwq6r064626; Thu, 2 May 2002 16:58:52 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g42Kwnx109882; Thu, 2 May 2002 16:58:49 -0400 To: "Clemm, Geoff" Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 2 May 2002 16:40:34 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/02/2002 04:58:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6187 X-Loop: w3c-dist-auth@w3.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 recent thread entitled RE: need clarification about COPY to locked resource response cod e and RE: need clarification about COPY to locked resource response cod e recently died down with the following posting. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0043.html I just want to bring it to conclusion and get it on the ISSUES list. So we have a proposal on the table regarding error reporting for lock conflicts during COPY/MOVE. I'll try to describe it below. If a portion of the destination is locked and preventing a portion of the COPY/MOVE, then a 207 Multistatus MUST be returned by the server. That MultiStatus response should indicate (with 409 Conflict status) what source resource could not be copied/moved and optionally say something about the locked destination resource the locked that prevented the copy. /bla/source HTTP/1.1 409 CONFLICT /other/destref... That D:error tag is optional. And clearly we'd need the add definitions for the D:error tag and the descendent tags listed in the example above. We should work out if the dest URL listed is the root of the lock or the locked resource that was directly affecting the operation. We should possibly clarify "protected URL" status codes and what URL is depicted. If none of the COPY/MOVE could be done due to a locked destination, then it is acceptable, although obviously not optimal, to simply return a 409 CONFLICT rather than a 207 MULTISTATUS. As for *source* locks... Source lock error don't occur for COPY, just MOVE. And the 423 LOCKED status code will be used instead of 409 CONFLICT. More specifically... In the case of a MOVE operations where a portion of the source is locked, the server is to respond with 207 MULTISTATUS and the body of that will simply indicate the locked source resources with a 423 LOCKED status. /bla/... HTTP/1.1 423 LOCKED In the case that the request (source) URL is locked in a way that prevents any other MOVEs to occur, the server is free to simply reply with a 423 LOCKED rather than a 407 MULTISTATUS. In all cases, minimization rules apply. I will start a seperate thread for Minimization issues if necessary. So does this sound acceptable to everyone? J. From w3c-dist-auth-request@w3.org Thu May 2 17:40:21 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 RAA10967 for ; Thu, 2 May 2002 17:40:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA12683; Thu, 2 May 2002 17:39:36 -0400 (EDT) Resent-Date: Thu, 2 May 2002 17:39:36 -0400 (EDT) Resent-Message-Id: <200205022139.RAA12683@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA12658 for ; Thu, 2 May 2002 17:39:31 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA07641 for ; Thu, 2 May 2002 17:39:30 -0400 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 02 May 2002 17:35:01 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <26NBNTVY>; Thu, 2 May 2002 17:38:58 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B190@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Thu, 2 May 2002 17:38:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6188 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Fine by me. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, May 02, 2002 4:41 PM To: Clemm, Geoff Cc: WebDAV Subject: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION The recent thread entitled RE: need clarification about COPY to locked resource response cod e and RE: need clarification about COPY to locked resource response cod e recently died down with the following posting. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0043.html I just want to bring it to conclusion and get it on the ISSUES list. So we have a proposal on the table regarding error reporting for lock conflicts during COPY/MOVE. I'll try to describe it below. If a portion of the destination is locked and preventing a portion of the COPY/MOVE, then a 207 Multistatus MUST be returned by the server. That MultiStatus response should indicate (with 409 Conflict status) what source resource could not be copied/moved and optionally say something about the locked destination resource the locked that prevented the copy. /bla/source HTTP/1.1 409 CONFLICT /other/destref... That D:error tag is optional. And clearly we'd need the add definitions for the D:error tag and the descendent tags listed in the example above. We should work out if the dest URL listed is the root of the lock or the locked resource that was directly affecting the operation. We should possibly clarify "protected URL" status codes and what URL is depicted. If none of the COPY/MOVE could be done due to a locked destination, then it is acceptable, although obviously not optimal, to simply return a 409 CONFLICT rather than a 207 MULTISTATUS. As for *source* locks... Source lock error don't occur for COPY, just MOVE. And the 423 LOCKED status code will be used instead of 409 CONFLICT. More specifically... In the case of a MOVE operations where a portion of the source is locked, the server is to respond with 207 MULTISTATUS and the body of that will simply indicate the locked source resources with a 423 LOCKED status. /bla/... HTTP/1.1 423 LOCKED In the case that the request (source) URL is locked in a way that prevents any other MOVEs to occur, the server is free to simply reply with a 423 LOCKED rather than a 407 MULTISTATUS. In all cases, minimization rules apply. I will start a seperate thread for Minimization issues if necessary. So does this sound acceptable to everyone? J. From w3c-dist-auth-request@w3.org Sat May 4 17:03: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 RAA29254 for ; Sat, 4 May 2002 17:03:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA13664; Sat, 4 May 2002 17:01:20 -0400 (EDT) Resent-Date: Sat, 4 May 2002 17:01:20 -0400 (EDT) Resent-Message-Id: <200205042101.RAA13664@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA13636 for ; Sat, 4 May 2002 17:01:14 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA11915 for ; Sat, 4 May 2002 17:01:14 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g44L0Z6r104196; Sat, 4 May 2002 17:00:35 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g44L0Xc83850; Sat, 4 May 2002 17:00:33 -0400 To: WebDAV Cc: "Clemm, Geoff" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sat, 4 May 2002 16:49:31 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/04/2002 05:00:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6189 X-Loop: w3c-dist-auth@w3.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 could use a few more people speaking up... :-) http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0080.html ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat May 4 18:52: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 SAA00403 for ; Sat, 4 May 2002 18:52:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA18579; Sat, 4 May 2002 18:51:32 -0400 (EDT) Resent-Date: Sat, 4 May 2002 18:51:32 -0400 (EDT) Resent-Message-Id: <200205042251.SAA18579@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA18559 for ; Sat, 4 May 2002 18:51:27 -0400 (EDT) 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 SAA21423 for ; Sat, 4 May 2002 18:51:27 -0400 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 <0GVL00HQPZHQSH@mta5.snfc21.pbi.net> for w3c-dist-auth@w3.org; Sat, 04 May 2002 15:51:26 -0700 (PDT) Date: Sat, 04 May 2002 15:44:48 -0700 From: Elias Sinderson Cc: WebDAV Message-id: <3CD46460.1080005@cse.ucsc.edu> Organization: Amorphous Industries, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 References: Subject: Re: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6190 X-Loop: w3c-dist-auth@w3.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 It seems reasonable to me, although the details are still to be worked out for a few small things. Elias Jason Crawford wrote: > The recent thread entitled > RE: need clarification about COPY to locked resource response cod e > and > RE: need clarification about COPY to locked resource response cod e > recently died down with the following posting. > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0043.html > > I just want to bring it to conclusion and get it on the ISSUES list. > > > So we have a proposal on the table regarding error reporting for lock > conflicts > during COPY/MOVE. I'll try to describe it below. > > If a portion of the destination is locked and preventing a portion of the > COPY/MOVE, > then a 207 Multistatus MUST be returned by the server. That MultiStatus > response should > indicate (with 409 Conflict status) what source resource could not be > copied/moved and > optionally say something about the locked destination resource the locked > that prevented > the copy. > > > /bla/source > HTTP/1.1 409 CONFLICT > > > > /other/destref... > > > > > > That D:error tag is optional. And clearly we'd need the add definitions > for the > D:error tag and the descendent tags listed in the example above. > We should work out if the dest URL listed is the root of the lock or the > locked resource > that was directly affecting the operation. We should possibly clarify > "protected URL" > status codes and what URL is depicted. > > If none of the COPY/MOVE could be done due to a locked destination, then it > is acceptable, > although obviously not optimal, to simply return a 409 CONFLICT rather than > a > 207 MULTISTATUS. > > As for *source* locks... > > Source lock error don't occur for COPY, just MOVE. And the 423 LOCKED > status > code will be used instead of 409 CONFLICT. More specifically... > > In the case of a MOVE operations where a portion of the source is locked, > the server > is to respond with 207 MULTISTATUS and the body of that will simply > indicate the > locked source resources with a 423 LOCKED status. > > > /bla/... > HTTP/1.1 423 LOCKED > > > > In the case that the request (source) URL is locked in a way that prevents > any other > MOVEs to occur, the server is free to simply reply with a 423 LOCKED rather > than > a 407 MULTISTATUS. > > In all cases, minimization rules apply. I will start a seperate thread for > Minimization > issues if necessary. > > So does this sound acceptable to everyone? > > J. > > > > From w3c-dist-auth-request@w3.org Sun May 5 10:41: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 KAA19362 for ; Sun, 5 May 2002 10:41:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA10179; Sun, 5 May 2002 10:40:08 -0400 (EDT) Resent-Date: Sun, 5 May 2002 10:40:08 -0400 (EDT) Resent-Message-Id: <200205051440.KAA10179@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA10158 for ; Sun, 5 May 2002 10:40:01 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA29190 for ; Sun, 5 May 2002 10:40:00 -0400 Received: (qmail 11630 invoked by uid 0); 5 May 2002 14:39:26 -0000 Received: from p3ee2481f.dip.t-dialin.net (HELO lisa) (62.226.72.31) by mail.gmx.net (mp015-rz3) with SMTP; 5 May 2002 14:39:26 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Clemm, Geoff" Cc: "WebDAV" Date: Sun, 5 May 2002 16:39:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6191 X-Loop: w3c-dist-auth@w3.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, May 02, 2002 10:41 PM > To: Clemm, Geoff > Cc: WebDAV > Subject: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION > > > > The recent thread entitled > RE: need clarification about COPY to locked resource response cod e > and > RE: need clarification about COPY to locked resource response cod e > recently died down with the following posting. > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0043.html > > I just want to bring it to conclusion and get it on the ISSUES list. > > > So we have a proposal on the table regarding error reporting for lock > conflicts > during COPY/MOVE. I'll try to describe it below. > > If a portion of the destination is locked and preventing a portion of the > COPY/MOVE, > then a 207 Multistatus MUST be returned by the server. That MultiStatus > response should > indicate (with 409 Conflict status) what source resource could not be > copied/moved and > optionally say something about the locked destination resource the locked > that prevented > the copy. > > > /bla/source > HTTP/1.1 409 CONFLICT > > > > /other/destref... > > > > > > That D:error tag is optional. And clearly we'd need the add definitions > for the > D:error tag and the descendent tags listed in the example above. > We should work out if the dest URL listed is the root of the lock or the > locked resource > that was directly affecting the operation. We should possibly clarify > "protected URL" > status codes and what URL is depicted. How about a more generic version: /bla/source HTTP/1.1 409 CONFLICT ... complete DAV:response element for resource causing the conflict This would avoid having to define a whole new set of error conditions... > ... From w3c-dist-auth-request@w3.org Mon May 6 15:14: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 PAA03401 for ; Mon, 6 May 2002 15:14:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27652; Mon, 6 May 2002 15:12:57 -0400 (EDT) Resent-Date: Mon, 6 May 2002 15:12:57 -0400 (EDT) Resent-Message-Id: <200205061912.PAA27652@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA27628 for ; Mon, 6 May 2002 15:12:46 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA14977 for ; Mon, 6 May 2002 15:12:46 -0400 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 06 May 2002 15:07:08 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 15:11:15 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B1A3@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Mon, 6 May 2002 15:11:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6192 X-Loop: w3c-dist-auth@w3.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 don't think that it makes sense to try to re-use DAV:response in the "explanation" part of the error message, because you don't need another responsedescription, and it is not clear that the HTTP status codes are a useful way of characterizing what about the state of the other resource contributed to the error being described. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, May 05, 2002 10:39 AM To: Jason Crawford; Clemm, Geoff Cc: WebDAV Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Thursday, May 02, 2002 10:41 PM > To: Clemm, Geoff > Cc: WebDAV > Subject: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION > > > > The recent thread entitled > RE: need clarification about COPY to locked resource response cod e > and > RE: need clarification about COPY to locked resource response cod e > recently died down with the following posting. > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0043.html > > I just want to bring it to conclusion and get it on the ISSUES list. > > > So we have a proposal on the table regarding error reporting for lock > conflicts > during COPY/MOVE. I'll try to describe it below. > > If a portion of the destination is locked and preventing a portion of the > COPY/MOVE, > then a 207 Multistatus MUST be returned by the server. That MultiStatus > response should > indicate (with 409 Conflict status) what source resource could not be > copied/moved and > optionally say something about the locked destination resource the locked > that prevented > the copy. > > > /bla/source > HTTP/1.1 409 CONFLICT > > > > /other/destref... > > > > > > That D:error tag is optional. And clearly we'd need the add definitions > for the > D:error tag and the descendent tags listed in the example above. > We should work out if the dest URL listed is the root of the lock or the > locked resource > that was directly affecting the operation. We should possibly clarify > "protected URL" > status codes and what URL is depicted. How about a more generic version: /bla/source HTTP/1.1 409 CONFLICT ... complete DAV:response element for resource causing the conflict This would avoid having to define a whole new set of error conditions... > ... From w3c-dist-auth-request@w3.org Mon May 6 15:31: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 PAA03770 for ; Mon, 6 May 2002 15:31:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA28912; Mon, 6 May 2002 15:30:36 -0400 (EDT) Resent-Date: Mon, 6 May 2002 15:30:36 -0400 (EDT) Resent-Message-Id: <200205061930.PAA28912@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA28880 for ; Mon, 6 May 2002 15:30:26 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA20885 for ; Mon, 6 May 2002 15:30:25 -0400 Received: (qmail 6866 invoked by uid 0); 6 May 2002 19:29:54 -0000 Received: from pd950c392.dip.t-dialin.net (HELO lisa) (217.80.195.146) by mail.gmx.net (mp011-rz3) with SMTP; 6 May 2002 19:29:54 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Mon, 6 May 2002 21:29:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8B1A3@SUS-MA1IT01> Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6193 X-Loop: w3c-dist-auth@w3.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, May 06, 2002 9:11 PM > To: WebDAV > Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION > > > I don't think that it makes sense to try to re-use > DAV:response in the "explanation" part of the error message, > because you don't need another responsedescription, > and it is not clear that the HTTP status codes are a > useful way of characterizing what about the state of > the other resource contributed to the error being described. Well, we need - the URI and - error information (be it an HTTP status or a DAV:error element). DAV:response is a container that can hold both, so why not re-use it? From w3c-dist-auth-request@w3.org Mon May 6 15:56: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 PAA04588 for ; Mon, 6 May 2002 15:56:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA00971; Mon, 6 May 2002 15:55:34 -0400 (EDT) Resent-Date: Mon, 6 May 2002 15:55:34 -0400 (EDT) Resent-Message-Id: <200205061955.PAA00971@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA00946 for ; Mon, 6 May 2002 15:55:26 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA29178 for ; Mon, 6 May 2002 15:55:26 -0400 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 06 May 2002 15:48:06 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 15:52:13 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B1A5@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Mon, 6 May 2002 15:52:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6194 X-Loop: w3c-dist-auth@w3.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 reason not to reuse it is that this is not a "response" element, but rather an "explanation" element (i.e. the same reason you would not re-use a "point" element to represent a "vector" element, even though they both contained 2 integers). In particular, it is likely that you will want to extent a "response" in ways that are inappropriate for an "explanation", and vica versa. Of course, as with most questions of re-use, it is a value judgement as to "how close" two concepts are to each other, and how likely it is for them to evolve in divergent ways. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, May 06, 2002 3:30 PM To: Clemm, Geoff; WebDAV Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, May 06, 2002 9:11 PM > To: WebDAV > Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION > > > I don't think that it makes sense to try to re-use > DAV:response in the "explanation" part of the error message, > because you don't need another responsedescription, > and it is not clear that the HTTP status codes are a > useful way of characterizing what about the state of > the other resource contributed to the error being described. Well, we need - the URI and - error information (be it an HTTP status or a DAV:error element). DAV:response is a container that can hold both, so why not re-use it? From w3c-dist-auth-request@w3.org Tue May 7 11:21: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 LAA11998 for ; Tue, 7 May 2002 11:21:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA05973; Tue, 7 May 2002 11:20:29 -0400 (EDT) Resent-Date: Tue, 7 May 2002 11:20:29 -0400 (EDT) Resent-Message-Id: <200205071520.LAA05973@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA05953 for ; Tue, 7 May 2002 11:20:20 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA28769 for ; Tue, 7 May 2002 11:20:21 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g47FI4Tj095056; Tue, 7 May 2002 11:18:04 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g47FI1c74688; Tue, 7 May 2002 11:18:01 -0400 To: "Clemm, Geoff" Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 7 May 2002 09:23:23 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/07/2002 11:18:01 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6195 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << Of course, as with most questions of re-use, it is a value judgement as to "how close" two concepts are to each other, and how likely it is for them to evolve in divergent ways. >> Well let's go in to a few examples and see if that sways any opinions. To review... The basic concept of the proposal is that the body of the COPY/MOVE multistatus response will list source resources rather than destination resource. But additionally, it can list resouces that contributed to the status as an explanation of the source resource(s) error status. Often that will be a destination resource. Now for some examples... A depth lock above the destination that prevents a COPY/MOVE to the destination. How would you list this? (I'll let Geoff and Julian make the proposals.) A lock on the parent collection of the destination resource. A lock on the destination resource. A lock below the destination resource whose protected-lock-uri guarantees prevents the destination DELETE phase of the MOVE/COPY from occuring. A COPY/MOVE to a destination that doesn't have an immediate parent. A depth lock above the source URI that prevents a MOVE. A lock of the parent of the source URI prevents a MOVE. A lock on the source prevents a MOVE. A lock below the source prevents a MOVE due to protected-lock-uri guarantees. Same as the above LOCK situations but ACL's instead. Can the two approaches handle all of these well? Reminder, the issue is just for MOVE/COPY lock issues, but a check of these will let us know if the mechanism is flexible. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue May 7 15:36: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 PAA21765 for ; Tue, 7 May 2002 15:36:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA06010; Tue, 7 May 2002 15:34:26 -0400 (EDT) Resent-Date: Tue, 7 May 2002 15:34:26 -0400 (EDT) Resent-Message-Id: <200205071934.PAA06010@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA05933 for ; Tue, 7 May 2002 15:34:08 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA11376 for ; Tue, 7 May 2002 15:34:08 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g47JYTX20504; Tue, 7 May 2002 12:34:29 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Cc: Date: Tue, 7 May 2002 12:33:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: WG Last Call: Access Control Specification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6196 X-Loop: w3c-dist-auth@w3.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 ** WORKING GROUP LAST CALL FOR COMMENTS *** From November 11 to December 3, 2001, the WebDAV Working Group held a last call for comments period on the -07 version of the WebDAV Access Control Protocol. During the last call period, several working group members performed detailed reviews of the document. Their feedback has now been incorporated into the -08 version of the Access Control Protocol. Additionally, since the submission of the -07 version of the protocol specification, additional early implementation experience indicated the need for multiple improvements to the specification, including the addition of several privileges (DAV:write-properties, DAV:write-content, DAV:unlock), and the addition of many error conditions for the ACL method. From the abstract of the -08 specification: This document specifies a set of methods, headers, and message bodies that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HTTP method invocations) by a given principal. I am very hopeful that this is the absolutely final call for comments from the WebDAV Working Group on the WebDAV Access Control Protocol, draft-ietf-webdav-acl-08, prior to sending it along to the IESG for approval. This last call for comments period begins immediately, and ends Sunday, June 9, 2001, at midnight, US Pacific time. This allows over four weeks for review of the specification. The latest revision of the WebDAV Access Control Protocol was submitted as an Internet-Draft yesterday, and should appear in the Internet-Drafts directory in the next few days. In the meanwhile, it can be accessed at: Text (this is the normative version) http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.txt HTML: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.htm PDF: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.pdf Word: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.doc The -07 revision can be found in: http://www.webdav.org/acl/protocol/old/draft-ietf-webdav-acl-07.txt At the end of the last call review period, a new draft may be issued. Depending on the scope of changes introduced between the -08 and -09 versions, there will either be an immediate call for rough consensus (very few changes), or a second last call review period (significant changes). Once the document represents the rough consensus of the working group, I will submit this document to the Internet Engineering Steering Group (IESG) for their approval. IESG review involves a (minimum) two week public last call for comments period. This IESG-initiated last call period is in addition to the working group last call period. This document is intended to be a "Proposed Standard". Quoting from RFC 2026, "The Internet Standards Process -- Revision 3": The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. Many details on the procedures used to develop an IETF standard can be found in RFC 2026, available at: http://www.ietf.org/rfc/rfc2026.txt If there are any procedural questions or concerns, please do not hesitate to contact me, or raise an issue on the list. Notes: 1) Issues raised during the last call period will be resolved individually, rather than lumped together and dealt with as a whole. 2) If you've been waiting for a "stable" version of the specification before performing a review, wait no longer. This is it. Several parties have implemented this specification already. Please review the specification NOW in order to ensure your input gets included. - Jim Whitehead From w3c-dist-auth-request@w3.org Wed May 8 07:29: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 HAA01211 for ; Wed, 8 May 2002 07:29:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA12200; Wed, 8 May 2002 07:28:36 -0400 (EDT) Resent-Date: Wed, 8 May 2002 07:28:36 -0400 (EDT) Resent-Message-Id: <200205081128.HAA12200@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA12176 for ; Wed, 8 May 2002 07:28:29 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA13441 for ; Wed, 8 May 2002 07:28:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00949; Wed, 8 May 2002 07:28:20 -0400 (EDT) Message-Id: <200205081128.HAA00949@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 08 May 2002 07:28:20 -0400 Subject: I-D ACTION:draft-ietf-webdav-acl-08.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6197 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Access Control Protocol Author(s) : G. Clemm, A. Hopkins, E. Sedlar, J. Whitehead Filename : draft-ietf-webdav-acl-08.txt Pages : 65 Date : 07-May-02 This document specifies a set of methods, headers, and message bodies that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HTTP method invocations) by a given principal. This document is a product of the Web Distributed Authoring and Versioning (WebDAV) working group of the Internet Engineering Task Force. Comments on this draft are welcomed, and should be addressed to the acl@webdav.org mailing list. Other related documents can be found at http://www.webdav.org/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-08.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-ietf-webdav-acl-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-acl-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020507124403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507124403.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed May 8 10:40: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 KAA09567 for ; Wed, 8 May 2002 10:40:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA25383; Wed, 8 May 2002 10:38:37 -0400 (EDT) Resent-Date: Wed, 8 May 2002 10:38:37 -0400 (EDT) Resent-Message-Id: <200205081438.KAA25383@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA25335 for ; Wed, 8 May 2002 10:38:22 -0400 (EDT) Received: from ca.sandia.gov (california.sandia.gov [146.246.250.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA00369 for ; Wed, 8 May 2002 10:38:22 -0400 Received: (from smap@localhost) by ca.sandia.gov (8.8.8/1.15) id HAA18870; Wed, 8 May 2002 07:38:21 -0700 (PDT) Received: from carmen.ne.client2.attbi.com(65.96.141.209) by ca.sandia.gov via smap (V1.3) id sma024639; Wed May 8 07:38:08 2002 Message-ID: <3CD93887.7010205@ca.sandia.gov> Date: Wed, 08 May 2002 10:39:03 -0400 From: Carmen Pancerella User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: Carmen Pancerella Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Question about WebDAV and Dublin Core ... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6198 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello. I posted this question to the Dublin Core mailing list and didn't get any responses, so I'm trying this resource as well. I'm putting together a collection of datasets in WebDAV, and I want to use WebDAV properties to contain Dublin Core metadata. I searched the web archives and found a 1999 document about WebDAV and Dublin Core. Has anything else been done since this time? Has anybody done this? Any advice? In particular, I'm interested in how others have used qualified Dublin Core and have included encoding schemes in the WebDAV properties, and have searched for metadata in WebDAV repositories. (This isn't covered by the 1999 document.) Also, have people used XML or RDF or plain text to give the DC element values in the WebDAV properties? Any experiences are of interest to me. Thanks. Carmen carmen@ca.sandia.gov -- --------------------------------------------------------------------- Carmen Pancerella, PhD carmen@ca.sandia.gov Distributed Systems Research & Development Sandia National Laboratories Phone: (617) 630-0316 P.O. Box 969, Mailstop 9012 Voicemail: (925) 294-3538 Livermore, CA 94551-0969 Fax: (508) 300-8815 --------------------------------------------------------------------- From w3c-dist-auth-request@w3.org Wed May 8 10:40: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 KAA09566 for ; Wed, 8 May 2002 10:40:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA25406; Wed, 8 May 2002 10:38:48 -0400 (EDT) Resent-Date: Wed, 8 May 2002 10:38:48 -0400 (EDT) Resent-Message-Id: <200205081438.KAA25406@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA25333 for ; Wed, 8 May 2002 10:38:22 -0400 (EDT) Received: from ca.sandia.gov (california.sandia.gov [146.246.250.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA00368 for ; Wed, 8 May 2002 10:38:22 -0400 Received: (from smap@localhost) by ca.sandia.gov (8.8.8/1.15) id HAA09780 for ; Wed, 8 May 2002 07:38:21 -0700 (PDT) Received: from carmen.ne.client2.attbi.com(65.96.141.209) by ca.sandia.gov via smap (V1.3) id sma016628; Wed May 8 07:37:59 2002 Message-ID: <3CD9387F.6060000@ca.sandia.gov> Date: Wed, 08 May 2002 10:38:55 -0400 From: Carmen Pancerella User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Question about WebDAV and Dublin Core ... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6199 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello. I posted this question to the Dublin Core mailing list and didn't get any responses, so I'm trying this resource as well. I'm putting together a collection of datasets in WebDAV, and I want to use WebDAV properties to contain Dublin Core metadata. I searched the web archives and found a 1999 document about WebDAV and Dublin Core. Has anything else been done since this time? Has anybody done this? Any advice? In particular, I'm interested in how others have used qualified Dublin Core and have included encoding schemes in the WebDAV properties, and have searched for metadata in WebDAV repositories. (This isn't covered by the 1999 document.) Also, have people used XML or RDF or plain text to give the DC element values in the WebDAV properties? Any experiences are of interest to me. Thanks. Carmen carmen@ca.sandia.gov -- --------------------------------------------------------------------- Carmen Pancerella, PhD carmen@ca.sandia.gov Distributed Systems Research & Development Sandia National Laboratories Phone: (617) 630-0316 P.O. Box 969, Mailstop 9012 Voicemail: (925) 294-3538 Livermore, CA 94551-0969 Fax: (508) 300-8815 --------------------------------------------------------------------- From w3c-dist-auth-request@w3.org Wed May 8 20:39: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 UAA27317 for ; Wed, 8 May 2002 20:39:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA29631; Wed, 8 May 2002 20:38:41 -0400 (EDT) Resent-Date: Wed, 8 May 2002 20:38:41 -0400 (EDT) Resent-Message-Id: <200205090038.UAA29631@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA29603 for ; Wed, 8 May 2002 20:38:29 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA00588 for ; Wed, 8 May 2002 20:38:29 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id RAA19786 for ; Wed, 8 May 2002 17:55:28 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 8 May 2002 17:37:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: Microsoft WebFolders and resource type Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6200 X-Loop: w3c-dist-auth@w3.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. - Jim -----Original Message----- From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com] Sent: Wednesday, May 08, 2002 3:34 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Microsoft WebFolders and resource type Looks like, MS-Explorer treat each resource with not empty as collection. For example, if resource type is this version is displayed as folder. Does anybody knows how to solve the problem and make this version visible as normal file (not folder) in MS-Explorer? -- Thanks in advance, Konstantin mailto:KKnizhnik@togetherlab.com From w3c-dist-auth-request@w3.org Thu May 9 06:21: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 GAA15116 for ; Thu, 9 May 2002 06:21:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA08843; Thu, 9 May 2002 06:20:05 -0400 (EDT) Resent-Date: Thu, 9 May 2002 06:20:05 -0400 (EDT) Resent-Message-Id: <200205091020.GAA08843@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA08802 for ; Thu, 9 May 2002 06:19:48 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA08625 for ; Thu, 9 May 2002 06:19:48 -0400 Received: (qmail 25098 invoked by uid 0); 9 May 2002 10:19:17 -0000 Received: from pd950c3a9.dip.t-dialin.net (HELO lisa) (217.80.195.169) by mail.gmx.net (mp013-rz3) with SMTP; 9 May 2002 10:19:17 -0000 From: "Julian Reschke" To: "WebDAV" Date: Thu, 9 May 2002 12:19:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Microsoft WebFolders and resource type Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6201 X-Loop: w3c-dist-auth@w3.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: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com] > Sent: Wednesday, May 08, 2002 3:34 AM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] Microsoft WebFolders and resource type > > > Looks like, MS-Explorer treat each resource with not empty > as collection. For example, if resource type is > > > > > > this version is displayed as folder. > Does anybody knows how to solve the problem and make > this version visible as normal file (not folder) in MS-Explorer? a) AFAIK, there's no workaround for this particular problem in Microsoft's compliant. Keep complaing to them. b) But: why are you trying to specify a resourcetype of DAV:version at the first place? That's not in RFC3253... From w3c-dist-auth-request@w3.org Thu May 9 08:30: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 IAA17335 for ; Thu, 9 May 2002 08:30:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA17299; Thu, 9 May 2002 08:29:09 -0400 (EDT) Resent-Date: Thu, 9 May 2002 08:29:09 -0400 (EDT) Resent-Message-Id: <200205091229.IAA17299@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA17261 for ; Thu, 9 May 2002 08:28:56 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA20741 for ; Thu, 9 May 2002 08:28:57 -0400 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 09 May 2002 08:24:11 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 08:28:26 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B106C4A062@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Thu, 9 May 2002 08:28:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Microsoft WebFolders and resource type Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6202 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Not only is DAV:version as a resourcetype not in RFC-3253, it is explicitly forbidden in RFC-3253 (the DAV:resourcetype of a version must be the same as the DAV:resourcetype of the version-controlled resource that was checked in to create it). And also note that this one done to some extent with the WebFolders problem in mind ... In particular RFC-3253 only gives non-null DAV:resourcetype values to resources that have no content (which means that it should cause no problem to have them be treated as "folders" by WebFolders). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, May 09, 2002 6:19 AM To: WebDAV Subject: RE: Microsoft WebFolders and resource type > From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com] > Sent: Wednesday, May 08, 2002 3:34 AM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] Microsoft WebFolders and resource type > > > Looks like, MS-Explorer treat each resource with not empty > as collection. For example, if resource type is > > > > > > this version is displayed as folder. > Does anybody knows how to solve the problem and make > this version visible as normal file (not folder) in MS-Explorer? a) AFAIK, there's no workaround for this particular problem in Microsoft's compliant. Keep complaing to them. b) But: why are you trying to specify a resourcetype of DAV:version at the first place? That's not in RFC3253... From w3c-dist-auth-request@w3.org Thu May 9 12:50: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 MAA29251 for ; Thu, 9 May 2002 12:50:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA07435; Thu, 9 May 2002 12:48:33 -0400 (EDT) Resent-Date: Thu, 9 May 2002 12:48:33 -0400 (EDT) Resent-Message-Id: <200205091648.MAA07435@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA07415 for ; Thu, 9 May 2002 12:48:28 -0400 (EDT) Received: from poseidon.ssi.samsung.com (poseidon.ssi.samsung.com [204.189.37.231]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA19623 for ; Thu, 9 May 2002 12:48:28 -0400 Received: by POSEIDON with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 09:47:00 -0700 Message-ID: From: Hiren Shah-SSI To: "'Clemm, Geoff'" , WebDAV Date: Thu, 9 May 2002 09:45:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F778.E00F2670" Subject: RE: Microsoft WebFolders and resource type Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6203 X-Loop: w3c-dist-auth@w3.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_01C1F778.E00F2670 Content-Type: text/plain; charset="iso-8859-1" Hi, I am totally new to DAV. I am just trying to find my way out. We have to use DAV in our application so I am searching abt it on google and got few links but can anyone let me know more abt it or can you send me any other links which are good . Thanks alot, Aarti -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Thursday, May 09, 2002 5:28 AM To: WebDAV Subject: RE: Microsoft WebFolders and resource type Not only is DAV:version as a resourcetype not in RFC-3253, it is explicitly forbidden in RFC-3253 (the DAV:resourcetype of a version must be the same as the DAV:resourcetype of the version-controlled resource that was checked in to create it). And also note that this one done to some extent with the WebFolders problem in mind ... In particular RFC-3253 only gives non-null DAV:resourcetype values to resources that have no content (which means that it should cause no problem to have them be treated as "folders" by WebFolders). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, May 09, 2002 6:19 AM To: WebDAV Subject: RE: Microsoft WebFolders and resource type > From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com] > Sent: Wednesday, May 08, 2002 3:34 AM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] Microsoft WebFolders and resource type > > > Looks like, MS-Explorer treat each resource with not empty > as collection. For example, if resource type is > > > > > > this version is displayed as folder. > Does anybody knows how to solve the problem and make > this version visible as normal file (not folder) in MS-Explorer? a) AFAIK, there's no workaround for this particular problem in Microsoft's compliant. Keep complaing to them. b) But: why are you trying to specify a resourcetype of DAV:version at the first place? That's not in RFC3253... ------_=_NextPart_001_01C1F778.E00F2670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Microsoft WebFolders and resource type

Hi,

I am totally new to DAV. I am just trying to find my = way out. We have to use DAV in our application so I am searching abt it = on google and got few links but can anyone let me know more abt = it  or can you send me any other links which are good .

Thanks alot,
Aarti

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@Rational.Com]
Sent: Thursday, May 09, 2002 5:28 AM
To: WebDAV
Subject: RE: Microsoft WebFolders and resource = type


Not only is DAV:version as a resourcetype not in = RFC-3253,
it is explicitly forbidden in RFC-3253 (the = DAV:resourcetype
of a version must be the same as the = DAV:resourcetype of the
version-controlled resource that was checked in to = create it).

And also note that this one done to some extent with = the
WebFolders problem in mind ...  In particular = RFC-3253 only
gives non-null DAV:resourcetype values to resources = that have
no content (which means that it should cause no = problem to
have them be treated as "folders" by = WebFolders).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Thursday, May 09, 2002 6:19 AM
To: WebDAV
Subject: RE: Microsoft WebFolders and resource = type


> From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.c= om]
> Sent: Wednesday, May 08, 2002 3:34 AM
> To: w3c-dist-auth@w3.org
> Subject: [Moderator Action] Microsoft = WebFolders and resource type
>
>
> Looks like, MS-Explorer treat each resource = with not empty
> <DAV:resourcetype> as collection. For = example, if resource type is
>
> <DAV:resourcetype>
> <DAV:version/>
> </DAV:resourcetype>
>
> this version is displayed as folder.
> Does anybody knows how to solve the problem and = make
> this version visible as normal file (not = folder) in MS-Explorer?

a) AFAIK, there's no workaround for this particular = problem in Microsoft's
compliant. Keep complaing to them.

b) But: why are you trying to specify a resourcetype = of DAV:version at the
first place? That's not in RFC3253...

------_=_NextPart_001_01C1F778.E00F2670-- From w3c-dist-auth-request@w3.org Thu May 9 13:27:56 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 NAA01606 for ; Thu, 9 May 2002 13:27:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10657; Thu, 9 May 2002 13:27:01 -0400 (EDT) Resent-Date: Thu, 9 May 2002 13:27:01 -0400 (EDT) Resent-Message-Id: <200205091727.NAA10657@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA10624 for ; Thu, 9 May 2002 13:26:51 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA24285 for ; Thu, 9 May 2002 13:26:51 -0400 Received: from Tycho (dhcp-60-113.cse.ucsc.edu [128.114.60.113]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g49HQ7N25167; Thu, 9 May 2002 10:26:07 -0700 (PDT) From: "Jim Whitehead" To: "Hiren Shah-SSI" , "WebDAV" Date: Thu, 9 May 2002 10:26:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C1F743.EBCF1090" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: Microsoft WebFolders and resource type Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6204 X-Loop: w3c-dist-auth@w3.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_003A_01C1F743.EBCF1090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Microsoft WebFolders and resource typeThe WebDAV.org site is the best overall source of information about WebDAV. The WebDAV working group site also has a wealth of information: http://www.webdav.org/ http://www.ics.uci.edu/pub/ietf/webdav/ But, since you've done a Google search, you undoubtedly have already found these pages... - Jim -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hiren Shah-SSI Sent: Thursday, May 09, 2002 9:45 AM To: 'Clemm, Geoff'; WebDAV Subject: RE: Microsoft WebFolders and resource type Hi, I am totally new to DAV. I am just trying to find my way out. We have to use DAV in our application so I am searching abt it on google and got few links but can anyone let me know more abt it or can you send me any other links which are good . Thanks alot, Aarti -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Thursday, May 09, 2002 5:28 AM To: WebDAV Subject: RE: Microsoft WebFolders and resource type Not only is DAV:version as a resourcetype not in RFC-3253, it is explicitly forbidden in RFC-3253 (the DAV:resourcetype of a version must be the same as the DAV:resourcetype of the version-controlled resource that was checked in to create it). And also note that this one done to some extent with the WebFolders problem in mind ... In particular RFC-3253 only gives non-null DAV:resourcetype values to resources that have no content (which means that it should cause no problem to have them be treated as "folders" by WebFolders). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, May 09, 2002 6:19 AM To: WebDAV Subject: RE: Microsoft WebFolders and resource type > From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com] > Sent: Wednesday, May 08, 2002 3:34 AM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] Microsoft WebFolders and resource type > > > Looks like, MS-Explorer treat each resource with not empty > as collection. For example, if resource type is > > > > > > this version is displayed as folder. > Does anybody knows how to solve the problem and make > this version visible as normal file (not folder) in MS-Explorer? a) AFAIK, there's no workaround for this particular problem in Microsoft's compliant. Keep complaing to them. b) But: why are you trying to specify a resourcetype of DAV:version at the first place? That's not in RFC3253... ------=_NextPart_000_003A_01C1F743.EBCF1090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Microsoft WebFolders and resource type
The=20 WebDAV.org site is the best overall source of information about WebDAV. = The=20 WebDAV working group site also has a wealth of = information:
 
http://www.webdav.org/<= /DIV>
http://www.ics.uci.edu/p= ub/ietf/webdav/
 
But,=20 since you've done a Google search, you undoubtedly have already found = these=20 pages...
 
-=20 Jim
-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hiren=20 Shah-SSI
Sent: Thursday, May 09, 2002 9:45 AM
To: = 'Clemm,=20 Geoff'; WebDAV
Subject: RE: Microsoft WebFolders and = resource type=20


Hi,

I am totally new to DAV. I am just trying to find my = way out.=20 We have to use DAV in our application so I am searching abt it on = google and=20 got few links but can anyone let me know more abt it  or can you = send me=20 any other links which are good .

Thanks alot,
Aarti =

-----Original Message-----
From:=20 Clemm, Geoff [mailto:gclemm@Rational.Com]=20
Sent: Thursday, May 09, 2002 5:28 AM =
To: WebDAV
Subject: RE: Microsoft = WebFolders=20 and resource type


Not only is DAV:version as a resourcetype not in=20 RFC-3253,
it is explicitly forbidden in = RFC-3253 (the=20 DAV:resourcetype
of a version must be the = same as the=20 DAV:resourcetype of the
version-controlled = resource=20 that was checked in to create it).

And also note that this one done to some extent with = the
WebFolders problem in mind ...  In = particular=20 RFC-3253 only
gives non-null = DAV:resourcetype values=20 to resources that have
no content (which = means that it=20 should cause no problem to
have them be = treated as=20 "folders" by WebFolders).

Cheers,
Geoff

-----Original Message-----
From:=20 Julian Reschke [mailto:julian.reschke@gmx.de]=20
Sent: Thursday, May 09, 2002 6:19 AM =
To: WebDAV
Subject: RE: Microsoft = WebFolders=20 and resource type


> From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.co= m]=20
> Sent: Wednesday, May 08, 2002 3:34 AM =
> To: w3c-dist-auth@w3.org
> = Subject:=20 [Moderator Action] Microsoft WebFolders and resource type =
>
>
> Looks=20 like, MS-Explorer treat each resource with not empty
> <DAV:resourcetype> as collection. For example, if = resource=20 type is
>
>=20 <DAV:resourcetype>
>=20 <DAV:version/>
>=20 </DAV:resourcetype>
> =
> this version is displayed as folder.
>=20 Does anybody knows how to solve the problem and make
> this version visible as normal file (not folder) in=20 MS-Explorer?

a) AFAIK, there's no workaround for this particular = problem in=20 Microsoft's
compliant. Keep complaing to = them.=20

b) But: why are you trying to specify a resourcetype = of=20 DAV:version at the
first place? That's not = in=20 RFC3253...

------=_NextPart_000_003A_01C1F743.EBCF1090-- From w3c-dist-auth-request@w3.org Thu May 9 14:00: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 OAA02753 for ; Thu, 9 May 2002 14:00:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA12027; Thu, 9 May 2002 13:55:54 -0400 (EDT) Resent-Date: Thu, 9 May 2002 13:55:54 -0400 (EDT) Resent-Message-Id: <200205091755.NAA12027@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA12007 for ; Thu, 9 May 2002 13:55:41 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA28294 for ; Thu, 9 May 2002 13:55:41 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g49HsrN01166; Thu, 9 May 2002 10:54:54 -0700 (PDT) From: "Jim Whitehead" To: "Carmen Pancerella" , Date: Thu, 9 May 2002 10:54:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3CD9387F.6060000@ca.sandia.gov> Subject: RE: Question about WebDAV and Dublin Core ... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6205 X-Loop: w3c-dist-auth@w3.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 Carmen, There has not been any significant work on "Use of Dublin Core Metadata in WebDAV" since the 1999 document, draft-ietf-webdav-dublin-core-01, http://www-old.ics.uci.edu/pub/ietf/webdav/dc/draft-ietf-webdav-dublin-core- 01.txt In part, we have been waiting for the Dublin Core group to develop a normative specification of how to represent Dublin Core elements in XML/RDF, an effort that has been stalled for many years. Looking at the Dublin Core website, it appears they may release some documents this month. However, I no longer think it makes sense to tie the WebDAV property expression of Dublin Core elements exactly to a Dublin Core standard. The DC documents assume that you'll have all of the DC elements in one chunk of XML. With WebDAV, it makes sense to put each DC elements into a separate properties. Hence, the XML representation of DC elements in DAV will be somewhat different from the DC/XML and DC/RDF drafts I have seen: http://dublincore.org/documents/2001/11/28/dcmes-xml/ http://www.ukoln.ac.uk/metadata/dcmi/dc-xml-guidelines/ Also, I don't think it makes sense to use RDF for DC elements. It just adds extra bytes on the wire, without gaining much. It would be trivial to write a routine on top of an existing DAV client library to extract the DC properties, then return them in the DC-approved RDF format. Hence, an RDF-aware application could easily get DC elements stored as DAV properties, in RDF format. No need to send all the RDF data over the wire. > I'm putting together a collection of datasets in WebDAV, > and I want to use WebDAV properties to contain Dublin > Core metadata. I searched the web archives and found a > 1999 document about WebDAV and Dublin Core. Has anything > else been done since this time? Has anybody done this? > Any advice? My recommendations are: * one property per DC element - use standard DC namespace, and element names * use a standard convention for multiple items per property (such as multiple authors for a resource). Using
  • {auth 1)
  • (auth 2)...
makes some sense to me (similar to the existing draft). * use xml:lang as appropriate to represent elements in multiple languages > In particular, I'm interested in how others have used qualified > Dublin Core and have included encoding schemes in the WebDAV > properties, and have searched for metadata in WebDAV > repositories. (This isn't covered by the 1999 document.) I don't know of any efforts that use DC elements in WebDAV properties, but definitely encourage the development of same. - Jim From w3c-dist-auth-request@w3.org Thu May 9 18:16: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 SAA11907 for ; Thu, 9 May 2002 18:16:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA10988; Thu, 9 May 2002 18:15:02 -0400 (EDT) Resent-Date: Thu, 9 May 2002 18:15:02 -0400 (EDT) Resent-Message-Id: <200205092215.SAA10988@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA10963 for ; Thu, 9 May 2002 18:14:57 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA17949 for ; Thu, 9 May 2002 18:14:57 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g49MEIAH101764; Thu, 9 May 2002 18:14:18 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g49MEAv97814; Thu, 9 May 2002 18:14:11 -0400 To: "Jason Crawford" Cc: "Clemm, Geoff" , WebDAV X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 9 May 2002 17:54:05 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/09/2002 06:14:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6206 X-Loop: w3c-dist-auth@w3.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'll record it as resolved that the multistatus results will list the source URL not the destination. That will move to "Edit" status. I'll create an issue item for the proposals for how to document the nature of the errors beyond the status code. I'll mark that item as defered to next version of WebDAV unless someone picks up the torch on this one. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu May 9 18:56: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 SAA12733 for ; Thu, 9 May 2002 18:55:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA14006; Thu, 9 May 2002 18:55:23 -0400 (EDT) Resent-Date: Thu, 9 May 2002 18:55:23 -0400 (EDT) Resent-Message-Id: <200205092255.SAA14006@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA13977 for ; Thu, 9 May 2002 18:55:16 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA22690 for ; Thu, 9 May 2002 18:55:16 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g49MsdAH094246; Thu, 9 May 2002 18:54:39 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g49MsbG96184; Thu, 9 May 2002 18:54:37 -0400 To: "Lisa Dusseault" Cc: "Webdav WG (E-mail)" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 9 May 2002 18:51:38 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/09/2002 06:54:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6207 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: One of the issues Lisa brought up below was not covered in subsequent discussions. That issue was what to do about the source property. In fhe following recent post http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0351.html It was indicated that at the IETF meeting there was a proposal to drop the source property. Julian added that we can pick it up in the next version of WebDAV. I'd like to mark it resolved that we will remove the source property. I would leave it up to our memories to bring the topic up again in the next version of WebDAV if we value it. The thinking is... The source property is good. But it's under specified and needs work, no interoperability has been determined, and no one has been yelling for it. If we remove it from the spec now, the few implementations that support it can remove that support and thus provide us a clean slate to work from when we take another stab at the source property. Please speak up if you disagree with this or would like to add to what I've said. Thanks :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Lisa Dusseault" s.com> cc: Sent by: Subject: 54th IETF Meeting Information, and RFC2518 open issues w3c-dist-auth-req uest@w3.org 04/22/2002 12:36 PM If you're not on the IETF-Announce list, you might not have seen this announcement about the upcoming meeting in Yokohama. To bring our "agenda" up-to-date, here's what I think the largest and hardest issues are for RFC2518 bis: - Whether/how to change the If header rules and syntax - Whether/how to change the source property definition Although the If header has been shown to be interoperable in its simplest form with locktokens, it hasn't been shown to be interoperable in its more advanced forms or with ETags. The source property has not had any demonstrated interoperability to my knowledge. I'd like to encourage anybody with ideas on what to do with either of these two features to make concrete proposals to the list. If your proposal is "leave things the way they are", I'd like to see some discussion on how to meet the requirements for going to proposed standard (how to demonstrate interoperability, and how much interoperability is enough). Another ACL draft is expected before the Yokohama cut-off, therefore ACLs will probably also be discussed in Yokohama. I'll be asking for a meeting slot. Lisa -----Original Message----- From: dinaras@cnri.reston.va.us [mailto:dinaras@cnri.reston.va.us]On Behalf Of ietf-secretariat@ietf.org Sent: Thursday, April 18, 2002 8:42 AM To: IETF-Announce: Subject: 54th IETF Meeting Information Registration for the 54th IETF is now open. Information can be found on the IETF web site at: http://www.ietf.org/meetings/IETF-54.html MEETING SITE: Pacifico Yokohama Convention Center 1-1-1 Minato Mirai, Nishi-ku, Yokohama 220-0012 Japan Tel: + 81 (45) 221-2112 Fax: + 81 (45) 221-2136 HOTEL ACCOMMODATIONS: Information is available on http://www.e-side.co.jp/ietf54/accommodation.html. Please be advised that ONLINE RESERVATIONS will be available after April 22nd. From w3c-dist-auth-request@w3.org Thu May 9 21:03: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 VAA17324 for ; Thu, 9 May 2002 21:03:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA22552; Thu, 9 May 2002 21:02:53 -0400 (EDT) Resent-Date: Thu, 9 May 2002 21:02:53 -0400 (EDT) Resent-Message-Id: <200205100102.VAA22552@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA22517 for ; Thu, 9 May 2002 21:02:36 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA10121 for ; Thu, 9 May 2002 21:02:36 -0400 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 09 May 2002 20:57:49 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 21:02:05 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B106C4A259@SUS-MA1IT01> From: "Clemm, Geoff" To: "Webdav WG (E-mail)" Date: Thu, 9 May 2002 21:01:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6208 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: OK with me. I'd keep it if we uncovered some interoperable implementations, but without that that, deferring it seems like the right choice. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, May 09, 2002 6:52 PM To: Lisa Dusseault Cc: Webdav WG (E-mail) Subject: Issue: SOURCE_PROPERTY_UNDERSPECIFIED One of the issues Lisa brought up below was not covered in subsequent discussions. That issue was what to do about the source property. In fhe following recent post http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0351.html It was indicated that at the IETF meeting there was a proposal to drop the source property. Julian added that we can pick it up in the next version of WebDAV. I'd like to mark it resolved that we will remove the source property. I would leave it up to our memories to bring the topic up again in the next version of WebDAV if we value it. The thinking is... The source property is good. But it's under specified and needs work, no interoperability has been determined, and no one has been yelling for it. If we remove it from the spec now, the few implementations that support it can remove that support and thus provide us a clean slate to work from when we take another stab at the source property. Please speak up if you disagree with this or would like to add to what I've said. Thanks :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Lisa Dusseault" s.com> cc: Sent by: Subject: 54th IETF Meeting Information, and RFC2518 open issues w3c-dist-auth-req uest@w3.org 04/22/2002 12:36 PM If you're not on the IETF-Announce list, you might not have seen this announcement about the upcoming meeting in Yokohama. To bring our "agenda" up-to-date, here's what I think the largest and hardest issues are for RFC2518 bis: - Whether/how to change the If header rules and syntax - Whether/how to change the source property definition Although the If header has been shown to be interoperable in its simplest form with locktokens, it hasn't been shown to be interoperable in its more advanced forms or with ETags. The source property has not had any demonstrated interoperability to my knowledge. I'd like to encourage anybody with ideas on what to do with either of these two features to make concrete proposals to the list. If your proposal is "leave things the way they are", I'd like to see some discussion on how to meet the requirements for going to proposed standard (how to demonstrate interoperability, and how much interoperability is enough). Another ACL draft is expected before the Yokohama cut-off, therefore ACLs will probably also be discussed in Yokohama. I'll be asking for a meeting slot. Lisa -----Original Message----- From: dinaras@cnri.reston.va.us [mailto:dinaras@cnri.reston.va.us]On Behalf Of ietf-secretariat@ietf.org Sent: Thursday, April 18, 2002 8:42 AM To: IETF-Announce: Subject: 54th IETF Meeting Information Registration for the 54th IETF is now open. Information can be found on the IETF web site at: http://www.ietf.org/meetings/IETF-54.html MEETING SITE: Pacifico Yokohama Convention Center 1-1-1 Minato Mirai, Nishi-ku, Yokohama 220-0012 Japan Tel: + 81 (45) 221-2112 Fax: + 81 (45) 221-2136 HOTEL ACCOMMODATIONS: Information is available on http://www.e-side.co.jp/ietf54/accommodation.html. Please be advised that ONLINE RESERVATIONS will be available after April 22nd. From w3c-dist-auth-request@w3.org Fri May 10 22: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 WAA00643 for ; Fri, 10 May 2002 22:23:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA04514; Fri, 10 May 2002 22:22:54 -0400 (EDT) Resent-Date: Fri, 10 May 2002 22:22:54 -0400 (EDT) Resent-Message-Id: <200205110222.WAA04514@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA04453 for ; Fri, 10 May 2002 22:22:26 -0400 (EDT) Received: from localhost.wakasoft.com (ip68-5-0-22.oc.oc.cox.net [68.5.0.22]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA01509 for ; Fri, 10 May 2002 22:22:26 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.wakasoft.com (8.10.2/8.10.2) with ESMTP id g4B2HMG00570; Fri, 10 May 2002 19:17:22 -0700 (PDT) Date: Fri, 10 May 2002 19:17:22 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Lisa Dusseault" , "Webdav WG (E-mail)" To: "Jason Crawford" From: "Roy T. Fielding" In-Reply-To: Message-Id: <3A416F44-6485-11D6-8D16-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6210 X-Loop: w3c-dist-auth@w3.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 like to mark it resolved that we will remove the source property. I > would leave it up to our memories to bring the topic up again in the next > version of WebDAV if we value it. > > The thinking is... > > The source property is good. > But it's under specified and needs work, no interoperability has been > determined, and no one has been yelling for it. If we remove it from the > spec now, the few implementations that support it can remove that support > and thus provide us a clean slate to work from when we take another stab > at > the source property. If the source property is removed, then how will the server respond to a client that attempts to use DAV on a resource that is not DAV authorable but is derived from other sources? What is the interoperability mechanism? I would prefer a source Link solution, myself, since that can be supplied in a normal HTTP error response. In my opinion, WebDAV needs to solve this issue before progressing on the standards track. It cannot simply remove it without abandoning the pretense that it handles Web authoring. Cheers, Roy T. Fielding, Chairman, The Apache Software Foundation (fielding@apache.org) Chief Scientist, Day Software 2 Corporate Plaza, Suite 150 Newport Beach, CA 92660-7929 fax:+1.949.644.5064 (roy.fielding@day.com) From w3c-dist-auth-request@w3.org Sat May 11 11:53: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 LAA03864 for ; Sat, 11 May 2002 11:53:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA21098; Sat, 11 May 2002 11:49:40 -0400 (EDT) Resent-Date: Sat, 11 May 2002 11:49:40 -0400 (EDT) Resent-Message-Id: <200205111549.LAA21098@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA21049 for ; Sat, 11 May 2002 11:49:04 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA14262 for ; Sat, 11 May 2002 11:49:03 -0400 Received: (qmail 27603 invoked by uid 0); 11 May 2002 15:48:32 -0000 Received: from pd950c3e3.dip.t-dialin.net (HELO lisa) (217.80.195.227) by mail.gmx.net (mp015-rz3) with SMTP; 11 May 2002 15:48:32 -0000 From: "Julian Reschke" To: "Roy T. Fielding" , "Jason Crawford" Cc: "Lisa Dusseault" , "Webdav WG \(E-mail\)" Date: Sat, 11 May 2002 17:48:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3A416F44-6485-11D6-8D16-000393753936@apache.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6211 X-Loop: w3c-dist-auth@w3.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 Roy T. Fielding > Sent: Saturday, May 11, 2002 4:17 AM > To: Jason Crawford > Cc: Lisa Dusseault; Webdav WG (E-mail) > Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > > I'd like to mark it resolved that we will remove the source property. I > > would leave it up to our memories to bring the topic up again > in the next > > version of WebDAV if we value it. > > > > The thinking is... > > > > The source property is good. > > But it's under specified and needs work, no interoperability has been > > determined, and no one has been yelling for it. If we remove > it from the > > spec now, the few implementations that support it can remove > that support > > and thus provide us a clean slate to work from when we take > another stab > > at > > the source property. > > If the source property is removed, then how will the server respond to a > client that attempts to use DAV on a resource that is not DAV authorable > but is derived from other sources? What is the interoperability > mechanism? I would assume that all authoring-type requests (PUT, PROPPATCH) will fail (403?). The issue that we have to resolve is that RFC2518 *does* specify a property that signals source resources, however the mechanism is underspecified, and because of that (and other reasons) we don't have interoperable implementations of it. For RFC2518 to move forward, it will either prove interoperability, or drop the feature. My suggestion is to drop {DAV:}source in RFC2518, then to define a new live property in a separate RFC (this wouldn't block RFC2518's progress). > I would prefer a source Link solution, myself, since that can be supplied > in a normal HTTP error response. So you'd prefer it to my an HTTP response header? We'd still need a PROPFIND compatible live property that a user agent can use to discover the source directly (without having to try to modify the resource). > In my opinion, WebDAV needs to solve this issue before progressing on > the standards track. It cannot simply remove it without abandoning the > pretense that it handles Web authoring. I don't think I can agree here. RFC2518 has proven useful without anybody supporting this property, so it's current state shouldn't block any progress on RFC2518. From w3c-dist-auth-request@w3.org Sat May 11 12:07: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 MAA04223 for ; Sat, 11 May 2002 12:07:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA22683; Sat, 11 May 2002 12:07:03 -0400 (EDT) Resent-Date: Sat, 11 May 2002 12:07:03 -0400 (EDT) Resent-Message-Id: <200205111607.MAA22683@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA22633 for ; Sat, 11 May 2002 12:06:29 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA15541 for ; Sat, 11 May 2002 12:06:29 -0400 Received: (qmail 24078 invoked by uid 0); 11 May 2002 16:05:58 -0000 Received: from pd950c3e3.dip.t-dialin.net (HELO lisa) (217.80.195.227) by mail.gmx.net (mp010-rz3) with SMTP; 11 May 2002 16:05:58 -0000 From: "Julian Reschke" To: "Webdav WG \(E-mail\)" Date: Sat, 11 May 2002 18:05:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: Preconditions/postconditions for RFC2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6212 X-Loop: w3c-dist-auth@w3.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 tempted to start a document that defines RFC3253-style QNames for the preconditions/postcondtions that can cause a 403 or 409 to be returned in RFC2518. Is anybody interested to collaborate on this? Julian From w3c-dist-auth-request@w3.org Sat May 11 13:36: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 NAA05464 for ; Sat, 11 May 2002 13:36:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA03082; Sat, 11 May 2002 13:35:37 -0400 (EDT) Resent-Date: Sat, 11 May 2002 13:35:37 -0400 (EDT) Resent-Message-Id: <200205111735.NAA03082@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA03055 for ; Sat, 11 May 2002 13:35:17 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA25003 for ; Sat, 11 May 2002 13:35:17 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4BHYjAH097066; Sat, 11 May 2002 13:34:45 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4BHYhi112818; Sat, 11 May 2002 13:34:43 -0400 To: "Roy T. Fielding" Cc: "Webdav WG (E-mail)" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sat, 11 May 2002 13:11:07 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/11/2002 01:34:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6213 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << What is the interoperability mechanism? I would prefer a source Link solution, myself, since that can be supplied in a normal HTTP error response. >> I like the source link solution also, but we have to demonstrate interoperability. People haven't been breaking down the doors for this and no interoperability has been determined. An additional proposal would have to be made, and then implementations of that would be needed, and then interoperability tested. In the mean time the spec could not move forward to the next stage. But we have real important changes in store that are already approved and time we spend on defining the DAV:source property, which people haven't been requesting heavily, is time folks are implementing 2518 with all it's warts instead of all the improvements we've already approved. << In my opinion, WebDAV needs to solve this issue before progressing on the standards track. It cannot simply remove it without abandoning the pretense that it handles Web authoring. >> My thinking is, we need to move the spec forward and dav:source isn't something people have been requesting heavily. I suspect the reason they haven't is because it's not heavily needed. Before WebDAV we've had file system access and FTP access. These were used pretty easily for authoring without a source property. Folks just knew what part of the FTP or file system namespace needed to be accessed to do their editing. It's not a terrible burden to expect the same to happen with WebDAV. Servers will often provide a WebDAV enabled URI space to access underlying resources (much like what is accessed in the file system or via FTP). Down the road, if there is a demand, we'll spec a new DAV:source property that points to the source URL tree that many folks have already been using. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat May 11 18:21: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 SAA14952 for ; Sat, 11 May 2002 18:21:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA11707; Fri, 10 May 2002 05:42:16 -0400 (EDT) Resent-Date: Fri, 10 May 2002 05:42:16 -0400 (EDT) Resent-Message-Id: <200205100942.FAA11707@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA11535 for ; Fri, 10 May 2002 05:41:01 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA14359 for ; Fri, 10 May 2002 05:33:04 -0400 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 10 May 2002 11:31:59 +0200 Date: Fri, 10 May 2002 11:31:58 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Stefan Eissing To: "Webdav WG (E-mail)" Content-Transfer-Encoding: 7bit In-Reply-To: <3906C56A7BD1F54593344C05BD1374B106C4A259@SUS-MA1IT01> Message-Id: X-Mailer: Apple Mail (2.481) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6209 X-Loop: w3c-dist-auth@w3.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. //Stefan Am Freitag den, 10. Mai 2002, um 03:01, schrieb Clemm, Geoff: > OK with me. I'd keep it if we uncovered some interoperable > implementations, > but without that that, deferring it seems like the right choice. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Thursday, May 09, 2002 6:52 PM > To: Lisa Dusseault > Cc: Webdav WG (E-mail) > Subject: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > > One of the issues Lisa brought up below was not covered in subsequent > discussions. That issue was what to do about the source property. > > In fhe following recent post > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0351.html > > It was indicated that at the IETF meeting there was a proposal to > drop the > source property. Julian added that we can pick it up in the next > version > of WebDAV. > > I'd like to mark it resolved that we will remove the source > property. I > would leave it up to our memories to bring the topic up again in > the next > version of WebDAV if we value it. > > The thinking is... > > The source property is good. > But it's under specified and needs work, no interoperability has been > determined, and no one has been yelling for it. If we remove it > from the > spec now, the few implementations that support it can remove that > support > and thus provide us a clean slate to work from when we take > another stab at > the source property. > > Please speak up if you disagree with this or would like to add to > what I've > said. > > Thanks :-) > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > > > > "Lisa Dusseault" > > (E-mail)" > s.com> cc: > > Sent by: Subject: 54th IETF > Meeting > Information, and RFC2518 open issues > w3c-dist-auth-req > > uest@w3.org > > > > > > 04/22/2002 12:36 > > PM > > > > > > > > > If you're not on the IETF-Announce list, you might not have seen this > announcement about the upcoming meeting in Yokohama. > > To bring our "agenda" up-to-date, here's what I think the largest and > hardest issues are for RFC2518 bis: > - Whether/how to change the If header rules and syntax > - Whether/how to change the source property definition > > Although the If header has been shown to be interoperable in its > simplest > form with locktokens, it hasn't been shown to be interoperable in > its more > advanced forms or with ETags. The source property has not had any > demonstrated interoperability to my knowledge. > > I'd like to encourage anybody with ideas on what to do with either > of these > two features to make concrete proposals to the list. If your > proposal is > "leave things the way they are", I'd like to see some discussion > on how to > meet the requirements for going to proposed standard (how to > demonstrate > interoperability, and how much interoperability is enough). > > Another ACL draft is expected before the Yokohama cut-off, > therefore ACLs > will probably also be discussed in Yokohama. I'll be asking for a > meeting > slot. > > Lisa > > -----Original Message----- > From: dinaras@cnri.reston.va.us [mailto:dinaras@cnri.reston.va.us]On > Behalf Of ietf-secretariat@ietf.org > Sent: Thursday, April 18, 2002 8:42 AM > To: IETF-Announce: > Subject: 54th IETF Meeting Information > > > Registration for the 54th IETF is now open. > Information can be found on the IETF web site at: > http://www.ietf.org/meetings/IETF-54.html > > MEETING SITE: > Pacifico Yokohama Convention Center > 1-1-1 Minato Mirai, Nishi-ku, Yokohama 220-0012 Japan > Tel: + 81 (45) 221-2112 > Fax: + 81 (45) 221-2136 > > HOTEL ACCOMMODATIONS: > Information is available on > http://www.e-side.co.jp/ietf54/accommodation.html. > Please be advised that ONLINE RESERVATIONS will be available after > April > 22nd. > > > > > > From w3c-dist-auth-request@w3.org Mon May 13 12:34: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 MAA18892 for ; Mon, 13 May 2002 12:34:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA14597; Mon, 13 May 2002 12:32:30 -0400 (EDT) Resent-Date: Mon, 13 May 2002 12:32:30 -0400 (EDT) Resent-Message-Id: <200205131632.MAA14597@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA14565 for ; Mon, 13 May 2002 12:32:22 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA27589 for ; Mon, 13 May 2002 12:32:22 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g4DGVgN03473; Mon, 13 May 2002 09:31:42 -0700 (PDT) From: "Jim Whitehead" To: "Roy T. Fielding" Cc: "Webdav WG \(E-mail\)" Date: Mon, 13 May 2002 09:31:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3A416F44-6485-11D6-8D16-000393753936@apache.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6214 X-Loop: w3c-dist-auth@w3.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 Roy Fielding writes: > In my opinion, WebDAV needs to solve this issue before progressing > on the standards track. I agree. Authoring access to an unprocessed source representation of a resource has been a WebDAV goal from the very beginning (see Section 5.5 of RFC 2291). Removing RFC 2518's mechanism for accomplishing this doesn't help reach the goal -- it's just a punt. Jason Crawford writes: > But it's under specified and needs work, no interoperability > has been determined, and no one has been yelling for it. Julian Reschke writes: > The issue that we have to resolve is that RFC2518 *does* specify > a property that signals source resources, however the mechanism > is underspecified, and because of that (and other reasons) we > don't have interoperable implementations of it. In what way(s) is this mechanism underspecified? From my perspective, it provides sufficient information for an authoring client to discover a URL where authoring can take place. I assert that, given a few weeks of coding, we could easily demonstrate at least two clients and two servers interoperating on this feature as currently specified. There are no obvious technical impediments to doing so. - Jim From w3c-dist-auth-request@w3.org Mon May 13 13:50: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 NAA22152 for ; Mon, 13 May 2002 13:50:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA16556; Mon, 13 May 2002 12:48:26 -0400 (EDT) Resent-Date: Mon, 13 May 2002 12:48:26 -0400 (EDT) Resent-Message-Id: <200205131648.MAA16556@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA16384 for ; Mon, 13 May 2002 12:47:48 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA31864 for ; Mon, 13 May 2002 12:47:47 -0400 Received: (qmail 12171 invoked by uid 0); 13 May 2002 16:47:07 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp016-rz3) with SMTP; 13 May 2002 16:47:07 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "Roy T. Fielding" Cc: "Webdav WG \(E-mail\)" Date: Mon, 13 May 2002 18:46:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-reply-to: Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6215 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Monday, May 13, 2002 6:32 PM > To: Roy T. Fielding > Cc: Webdav WG (E-mail) > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > Roy Fielding writes: > > In my opinion, WebDAV needs to solve this issue before progressing > > on the standards track. > > I agree. Authoring access to an unprocessed source representation of a > resource has been a WebDAV goal from the very beginning (see > Section 5.5 of > RFC 2291). Removing RFC 2518's mechanism for accomplishing this > doesn't help > reach the goal -- it's just a punt. > > Jason Crawford writes: > > But it's under specified and needs work, no interoperability > > has been determined, and no one has been yelling for it. > > Julian Reschke writes: > > The issue that we have to resolve is that RFC2518 *does* specify > > a property that signals source resources, however the mechanism > > is underspecified, and because of that (and other reasons) we > > don't have interoperable implementations of it. > > In what way(s) is this mechanism underspecified? From my perspective, it > provides sufficient information for an authoring client to discover a URL > where authoring can take place. The main issues are that - the text and examples in the RFC just do not make sense to me (see [1]) - the source property doesn't offer enough information to display information about the *types* of link relations [1] > I assert that, given a few weeks of coding, we could easily demonstrate at > least two clients and two servers interoperating on this feature as > currently specified. There are no obvious technical impediments > to doing so. Do you have specific servers and clients in mind? From w3c-dist-auth-request@w3.org Mon May 13 15:54: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 PAA29486 for ; Mon, 13 May 2002 15:54:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA01940; Mon, 13 May 2002 15:53:15 -0400 (EDT) Resent-Date: Mon, 13 May 2002 15:53:15 -0400 (EDT) Resent-Message-Id: <200205131953.PAA01940@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA01897 for ; Mon, 13 May 2002 15:53:05 -0400 (EDT) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA28923 for ; Mon, 13 May 2002 15:53:05 -0400 Received: from manyfish.co.uk ([62.253.142.7]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020513195304.ZSBG295.mta03-svc.ntlworld.com@manyfish.co.uk> for ; Mon, 13 May 2002 20:53:04 +0100 Received: (from joe@localhost) by manyfish.co.uk (8.11.6/8.11.6) id g4DJom302451 for w3c-dist-auth@w3c.org; Mon, 13 May 2002 20:50:48 +0100 Date: Mon, 13 May 2002 20:50:48 +0100 From: Joe Orton To: "Webdav WG (E-mail)" Message-ID: <20020513205048.A2357@light.plus.com> Mail-Followup-To: "Webdav WG (E-mail)" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian.reschke@gmx.de on Mon, May 13, 2002 at 06:46:49PM +0200 Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6216 X-Loop: w3c-dist-auth@w3.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, May 13, 2002 at 06:46:49PM +0200, Julian Reschke wrote: > The main issues are that > > - the text and examples in the RFC just do not make sense to me (see [1]) > > - the source property doesn't offer enough information to display > information about the *types* of link relations > > [1] If you drop the XLink stuff I support the "source-set" property described in that message as a replacement for the source property; I implemented it a while ago for mod_dav and cadaver and it very works nicely. (I started off implementing {DAV:}source but it suffers greatly because of the two issues given above) An alternative would be to retain the "source" property but drop the redundant "src" element and replace it with a "description" element giving a human-readable description of the link as the cdata content. joe From w3c-dist-auth-request@w3.org Mon May 13 18:17: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 SAA06873 for ; Mon, 13 May 2002 18:16:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA17304; Mon, 13 May 2002 18:16:06 -0400 (EDT) Resent-Date: Mon, 13 May 2002 18:16:06 -0400 (EDT) Resent-Message-Id: <200205132216.SAA17304@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA17277 for ; Mon, 13 May 2002 18:15:56 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA15111 for ; Mon, 13 May 2002 18:15:56 -0400 Received: (qmail 6205 invoked by uid 0); 13 May 2002 22:15:25 -0000 Received: from p3ee2482d.dip.t-dialin.net (HELO lisa) (62.226.72.45) by mail.gmx.net (mp002-rz3) with SMTP; 13 May 2002 22:15:25 -0000 From: "Julian Reschke" To: "Joe Orton" , "Webdav WG \(E-mail\)" Date: Tue, 14 May 2002 00:15:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020513205048.A2357@light.plus.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6217 X-Loop: w3c-dist-auth@w3.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 Joe Orton > Sent: Monday, May 13, 2002 9:51 PM > To: Webdav WG (E-mail) > Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > On Mon, May 13, 2002 at 06:46:49PM +0200, Julian Reschke wrote: > > The main issues are that > > > > - the text and examples in the RFC just do not make sense to me > (see [1]) > > > > - the source property doesn't offer enough information to display > > information about the *types* of link relations > > > > [1] > > > If you drop the XLink stuff I support the "source-set" property > described in that message as a replacement for the source property; I > implemented it a while ago for mod_dav and cadaver and it very works > nicely. (I started off implementing {DAV:}source but it suffers greatly > because of the two issues given above) > > An alternative would be to retain the "source" property but drop the > redundant "src" element and replace it with a "description" element > giving a human-readable description of the link as the cdata content. Joe, I'm happy to have a different format (I've got enough flak promoting XLink-compatible syntax :-). My requirements are - must support multiple links - there must be a machine-readable description for the link type - the should be a human-readable description for the link type Please post what you're using right now -- we'll probably able to extend if necessary. Julian From w3c-dist-auth-request@w3.org Mon May 13 18:49: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 SAA08140 for ; Mon, 13 May 2002 18:49:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA21502; Mon, 13 May 2002 18:49:25 -0400 (EDT) Resent-Date: Mon, 13 May 2002 18:49:25 -0400 (EDT) Resent-Message-Id: <200205132249.SAA21502@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA21438 for ; Mon, 13 May 2002 18:49:06 -0400 (EDT) Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA18738 for ; Mon, 13 May 2002 18:49:06 -0400 Received: from manyfish.co.uk ([62.253.142.7]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020513224906.ZNQH29981.mta07-svc.ntlworld.com@manyfish.co.uk> for ; Mon, 13 May 2002 23:49:06 +0100 Received: (from joe@localhost) by manyfish.co.uk (8.11.6/8.11.6) id g4DMkou05569 for w3c-dist-auth@w3c.org; Mon, 13 May 2002 23:46:50 +0100 Date: Mon, 13 May 2002 23:46:50 +0100 From: Joe Orton To: "Webdav WG (E-mail)" Message-ID: <20020513234650.A5389@light.plus.com> Mail-Followup-To: "Webdav WG (E-mail)" References: <20020513205048.A2357@light.plus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian.reschke@gmx.de on Tue, May 14, 2002 at 12:15:24AM +0200 Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6218 X-Loop: w3c-dist-auth@w3.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 Tue, May 14, 2002 at 12:15:24AM +0200, Julian Reschke wrote: > I'm happy to have a different format (I've got enough flak promoting > XLink-compatible syntax :-). My requirements are > > - must support multiple links > - there must be a machine-readable description for the link type > - the should be a human-readable description for the link type > > Please post what you're using right now -- we'll probably able to extend if > necessary. I just dropped the xlink: from the href attribute, and got rid of the xlink:role attribute entirely, giving e.g.: Source Stylesheet which should satisfy your first and third requirements; I'm not sure about "machine-readable" link descriptions being mandatory. My client doesn't need to understand anything about the link, I just want it to be able to display a menu of "URI: description" choices when there is >1 source available, so that the user can decide. (Similarly, the minimum amount of server configuration I'd like to require is saying e.g. "/dav/render.xsl is a source of /dav/*.xml") Regards, joe From w3c-dist-auth-request@w3.org Mon May 13 19:00: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 TAA08499 for ; Mon, 13 May 2002 19:00:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA22075; Mon, 13 May 2002 18:59:51 -0400 (EDT) Resent-Date: Mon, 13 May 2002 18:59:51 -0400 (EDT) Resent-Message-Id: <200205132259.SAA22075@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA22041 for ; Mon, 13 May 2002 18:59:46 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA19833 for ; Mon, 13 May 2002 18:59:46 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id g4DMxTg03676 for ; Mon, 13 May 2002 15:59:31 -0700 (PDT) Message-ID: <3CE04551.1F79D581@cse.ucsc.edu> Date: Mon, 13 May 2002 15:59:29 -0700 From: Elias Sinderson Organization: NASA Ames Research Center X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Webdav WG (E-mail)" References: <20020513205048.A2357@light.plus.com> <20020513234650.A5389@light.plus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6219 X-Loop: w3c-dist-auth@w3.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 should think that what you have is machine readable as well, or am I missing some critical bit here? If the specification says to provide a RFC XXXX compliant URI for the source link, as below, I will bet that my machine (read client software) can read it with little extra effort. Elias Joe Orton wrote: > I just dropped the xlink: from the href attribute, and got rid of the > xlink:role attribute entirely, giving e.g.: > > > > Source > Stylesheet > > > > > which should satisfy your first and third requirements; I'm not sure > about "machine-readable" link descriptions being mandatory. My client > doesn't need to understand anything about the link, I just want it to be > able to display a menu of "URI: description" choices when there is >1 > source available, so that the user can decide. > > (Similarly, the minimum amount of server configuration I'd like to > require is saying e.g. "/dav/render.xsl is a source of /dav/*.xml") > > Regards, > > joe From w3c-dist-auth-request@w3.org Mon May 13 19:09: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 TAA08830 for ; Mon, 13 May 2002 19:09:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA23216; Mon, 13 May 2002 19:08:45 -0400 (EDT) Resent-Date: Mon, 13 May 2002 19:08:45 -0400 (EDT) Resent-Message-Id: <200205132308.TAA23216@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA23189 for ; Mon, 13 May 2002 19:08:36 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA20992 for ; Mon, 13 May 2002 19:08:36 -0400 Received: (qmail 8644 invoked by uid 0); 13 May 2002 23:08:05 -0000 Received: from p3ee2482d.dip.t-dialin.net (HELO lisa) (62.226.72.45) by mail.gmx.net (mp001-rz3) with SMTP; 13 May 2002 23:08:05 -0000 From: "Julian Reschke" To: "Elias Sinderson" , "Webdav WG \(E-mail\)" Date: Tue, 14 May 2002 01:08:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3CE04551.1F79D581@cse.ucsc.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6221 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The point is that is should be possible for the client to display the *type* of the link without having to look at the human-readable description. It's fine if this is optional. IMHO it's not ok if there's no standard way to do this. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias Sinderson > Sent: Tuesday, May 14, 2002 12:59 AM > To: Webdav WG (E-mail) > Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > I should think that what you have is machine readable as well, or > am I missing > some critical bit here? If the specification says to provide a > RFC XXXX compliant URI for the source link, as below, I will bet > that my machine > (read client software) can read it with little extra effort. > > Elias > > > Joe Orton wrote: > > > I just dropped the xlink: from the href attribute, and got rid of the > > xlink:role attribute entirely, giving e.g.: > > > > > > > > Source > > href="http://example.com/dav/render.xsl">Stylesheet > > > > > > > > > > which should satisfy your first and third requirements; I'm not sure > > about "machine-readable" link descriptions being mandatory. My client > > doesn't need to understand anything about the link, I just want it to be > > able to display a menu of "URI: description" choices when there is >1 > > source available, so that the user can decide. > > > > (Similarly, the minimum amount of server configuration I'd like to > > require is saying e.g. "/dav/render.xsl is a source of /dav/*.xml") > > > > Regards, > > > > joe > From w3c-dist-auth-request@w3.org Mon May 13 19:58: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 TAA10004 for ; Mon, 13 May 2002 19:58:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA27787; Mon, 13 May 2002 19:56:34 -0400 (EDT) Resent-Date: Mon, 13 May 2002 19:56:34 -0400 (EDT) Resent-Message-Id: <200205132356.TAA27787@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA27762 for ; Mon, 13 May 2002 19:56:25 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA25774 for ; Mon, 13 May 2002 19:56:25 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g4DNtiN11627 for ; Mon, 13 May 2002 16:55:44 -0700 (PDT) From: "Jim Whitehead" To: "Webdav WG \(E-mail\)" Date: Mon, 13 May 2002 16:55:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020513234650.A5389@light.plus.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6222 X-Loop: w3c-dist-auth@w3.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 Joe Orton writes: > I just dropped the xlink: from the href attribute, and got rid of the > xlink:role attribute entirely, giving e.g.: > > > > Source > Stylesheet > > > > I like this, except for the "Source" and "Stylesheet" not being individual elements or attributes. The i18n characteristics of the approach above are not great -- I can just see a Kanji UI popping up a pick list of English words, ugh. What was the perceived problem with using the xlink:role attribute (and Xlink syntax in general?) - Jim From w3c-dist-auth-request@w3.org Tue May 14 16:44: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 QAA06055 for ; Tue, 14 May 2002 16:44:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA22355; Tue, 14 May 2002 16:43:32 -0400 (EDT) Resent-Date: Tue, 14 May 2002 16:43:32 -0400 (EDT) Resent-Message-Id: <200205142043.QAA22355@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA22330 for ; Tue, 14 May 2002 16:43:21 -0400 (EDT) Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA24147 for ; Tue, 14 May 2002 16:43:19 -0400 Received: from manyfish.co.uk ([62.253.142.7]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020514204319.HQP2755.mta05-svc.ntlworld.com@manyfish.co.uk> for ; Tue, 14 May 2002 21:43:19 +0100 Received: (from joe@localhost) by manyfish.co.uk (8.11.6/8.11.6) id g4EKf3002049 for w3c-dist-auth@w3c.org; Tue, 14 May 2002 21:41:03 +0100 Date: Tue, 14 May 2002 21:41:02 +0100 From: Joe Orton To: "Webdav WG (E-mail)" Message-ID: <20020514214102.A1998@light.plus.com> Mail-Followup-To: "Webdav WG (E-mail)" References: <20020513234650.A5389@light.plus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ejw@cse.ucsc.edu on Mon, May 13, 2002 at 04:55:38PM -0700 Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6225 X-Loop: w3c-dist-auth@w3.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, May 13, 2002 at 04:55:38PM -0700, Jim Whitehead wrote: > > Joe Orton writes: > > I just dropped the xlink: from the href attribute, and got rid of the > > xlink:role attribute entirely, giving e.g.: > > > > > > > > Source > > Stylesheet > > > > > > > > > > I like this, except for the "Source" and "Stylesheet" not being individual > elements or attributes. The i18n characteristics of the approach above are > not great -- I can just see a Kanji UI popping up a pick list of English > words, ugh. What was the perceived problem with using the xlink:role > attribute (and Xlink syntax in general?) I just thought it was unnecessary to have to depend on yet another specification for something this simple. An alternative proposal: http://example.com/dav/source.xml Source http://example.com/dav/render.xsl Stylesheet where the href is mandatory, description is optional; this is i18n friendly... any problems with this approach? joe From w3c-dist-auth-request@w3.org Tue May 14 19:24: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 TAA11731 for ; Tue, 14 May 2002 19:24:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA02892; Tue, 14 May 2002 19:19:49 -0400 (EDT) Resent-Date: Tue, 14 May 2002 19:19:49 -0400 (EDT) Resent-Message-Id: <200205142319.TAA02892@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA02870 for ; Tue, 14 May 2002 19:19:33 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA11058 for ; Tue, 14 May 2002 19:19:33 -0400 Received: (qmail 27193 invoked by uid 0); 14 May 2002 23:19:01 -0000 Received: from p3ee24768.dip.t-dialin.net (HELO lisa) (62.226.71.104) by mail.gmx.net (mp013-rz3) with SMTP; 14 May 2002 23:19:01 -0000 From: "Julian Reschke" To: "Joe Orton" , "Webdav WG \(E-mail\)" Date: Wed, 15 May 2002 01:19:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20020514214102.A1998@light.plus.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6226 X-Loop: w3c-dist-auth@w3.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 Joe Orton > Sent: Tuesday, May 14, 2002 10:41 PM > To: Webdav WG (E-mail) > Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > On Mon, May 13, 2002 at 04:55:38PM -0700, Jim Whitehead wrote: > > > > Joe Orton writes: > > > I just dropped the xlink: from the href attribute, and got rid of the > > > xlink:role attribute entirely, giving e.g.: > > > > > > > > > > > > Source > > > href="http://example.com/dav/render.xsl">Stylesheet > > > > > > > > > > > > > > > > I like this, except for the "Source" and "Stylesheet" not being > individual > > elements or attributes. The i18n characteristics of the > approach above are > > not great -- I can just see a Kanji UI popping up a pick list of English > > words, ugh. What was the perceived problem with using the xlink:role > > attribute (and Xlink syntax in general?) > > I just thought it was unnecessary to have to depend on yet another > specification for something this simple. What do you mean by "depend"? We just reuse two standard attribute names (xlink:href and xlink:role). That's what XLink is for -- if every spec/document/protocol designer would take this position, it wouldn't make any sense to try to come up with common vocabularies for this. > An alternative proposal: > > > > > http://example.com/dav/source.xml > Source > > > http://example.com/dav/render.xsl > Stylesheet > > > > > where the href is mandatory, description is optional; this is i18n > friendly... any problems with this approach? It's as i18n friendly as all the other proposals, and still lacks a machine-readable way to represent the type of a link. So again, why not just use the Xlink [1] compatible syntax that I proposed back in October [2]: source file library file makefile What's wrong with it? It fulfills all requirements and uses W3C specs where applicable. (Note that xlink:role would be optional, and xml:lang would just need to be in scope somewhere, just as everywhere else in WebDAV land). [1] [2] From w3c-dist-auth-request@w3.org Wed May 15 06:35: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 GAA24598 for ; Wed, 15 May 2002 06:35:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA29607; Wed, 15 May 2002 06:34:30 -0400 (EDT) Resent-Date: Wed, 15 May 2002 06:34:30 -0400 (EDT) Resent-Message-Id: <200205151034.GAA29607@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA29565 for ; Wed, 15 May 2002 06:33:52 -0400 (EDT) Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA18114 for ; Wed, 15 May 2002 06:33:51 -0400 Received: from manyfish.co.uk ([62.253.142.7]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020515103350.VBB2755.mta05-svc.ntlworld.com@manyfish.co.uk> for ; Wed, 15 May 2002 11:33:50 +0100 Received: (from joe@localhost) by manyfish.co.uk (8.11.6/8.11.6) id g4FAVW607158 for w3c-dist-auth@w3c.org; Wed, 15 May 2002 11:31:32 +0100 Date: Wed, 15 May 2002 11:31:32 +0100 From: Joe Orton To: "Webdav WG (E-mail)" Message-ID: <20020515113132.A7136@light.plus.com> Mail-Followup-To: "Webdav WG (E-mail)" References: <20020514214102.A1998@light.plus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian.reschke@gmx.de on Wed, May 15, 2002 at 01:19:00AM +0200 Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6227 X-Loop: w3c-dist-auth@w3.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 Wed, May 15, 2002 at 01:19:00AM +0200, Julian Reschke wrote: > > I just thought it was unnecessary to have to depend on yet another > > specification for something this simple. > > What do you mean by "depend"? We just reuse two standard attribute names > (xlink:href and xlink:role). That's what XLink is for -- if every > spec/document/protocol designer would take this position, it wouldn't make > any sense to try to come up with common vocabularies for this. I just mean it's annoying to have to go and read Yet Another XSpec to find out how to implement WebDAV. If the DAV spec can explain that the xlink:href attribute must contain a URI-reference, and that xlink:role is entirely optional, then it's not really a problem. ... > So again, why not just use the Xlink [1] compatible syntax that I proposed > back in October [2]: > > > > xlink:role="UriDescribingTheRole" xml:lang="en">source file > xlink:role="UriDescribingTheRole" xml:lang="en">library file > xlink:role="UriDescribingTheRole" xml:lang="en">makefile > > > > What's wrong with it? It fulfills all requirements and uses W3C specs where > applicable. It does mean requiring that clients resolve XML namespaces on attribute names, which hasn't be necessary so far to implement a DAV client (in my experience anyway); possible interoperability issues there. I'll implement this source-set proposal sometime this week hopefully, given that nobody else objects to using XLink. joe From w3c-dist-auth-request@w3.org Wed May 15 22:39: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 WAA00959 for ; Wed, 15 May 2002 22:39:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06900; Wed, 15 May 2002 13:10:50 -0400 (EDT) Resent-Date: Wed, 15 May 2002 13:10:50 -0400 (EDT) Resent-Message-Id: <200205151710.NAA06900@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA06696 for ; Wed, 15 May 2002 13:10:02 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA14164 for ; Wed, 15 May 2002 13:00:45 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4FH0Ab7132762; Wed, 15 May 2002 13:00:11 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4FH08G132450; Wed, 15 May 2002 13:00:08 -0400 To: Joe Orton Cc: "Webdav WG (E-mail)" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 15 May 2002 12:53:12 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/15/2002 01:00:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6229 X-Loop: w3c-dist-auth@w3.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'll implement this source-set proposal sometime this week hopefully, > given that nobody else objects to using XLink. Can we get a few more folks implementing it so we can test interoperability? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed May 15 22:40: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 WAA01043 for ; Wed, 15 May 2002 22:40:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06959; Wed, 15 May 2002 13:11:18 -0400 (EDT) Resent-Date: Wed, 15 May 2002 13:11:18 -0400 (EDT) Resent-Message-Id: <200205151711.NAA06959@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA06698 for ; Wed, 15 May 2002 13:10:02 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA14133 for ; Wed, 15 May 2002 13:00:39 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4FH08b7098544 for ; Wed, 15 May 2002 13:00:08 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4FH06G132444 for ; Wed, 15 May 2002 13:00:06 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 15 May 2002 12:45:14 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/15/2002 01:00:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Issue: LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6230 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: See the following posting. In it Julian suggests that we clarify the format of the lockdiscovery property if a resource if under the influence of multiple shared locks. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0215.html Do we feel that this is necessary? If so, what do you suggest? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed May 15 22:44: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 WAA01117 for ; Wed, 15 May 2002 22:44:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21386; Wed, 15 May 2002 16:20:43 -0400 (EDT) Resent-Date: Wed, 15 May 2002 16:20:43 -0400 (EDT) Resent-Message-Id: <200205152020.QAA21386@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA21341 for ; Wed, 15 May 2002 16:19:53 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA07092 for ; Wed, 15 May 2002 16:19:53 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g4FKKIX23440 for ; Wed, 15 May 2002 13:20:18 -0700 (PDT) From: "Jim Whitehead" To: "Webdav WG \(E-mail\)" Date: Wed, 15 May 2002 13:19:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20020515113132.A7136@light.plus.com> Importance: Normal Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6231 X-Loop: w3c-dist-auth@w3.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 > It does mean requiring that clients resolve XML namespaces on attribute > names, which hasn't be necessary so far to implement a DAV client (in my > experience anyway); possible interoperability issues there. > > I'll implement this source-set proposal sometime this week hopefully, > given that nobody else objects to using XLink. In this case I think we should be compatible with the XLink syntax. As members of the broader community of Web standards developers, we should be consistent with existing relevant standards, unless we have a strong reason for deviating. Since most clients do not currently support the source property, I suspect the interoperability issues won't be very significant. - Jim PS - I can't wait until Yaron sees we have added another XML attribute into the DAV spec :-) From w3c-dist-auth-request@w3.org Wed May 15 22:47: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 WAA01207 for ; Wed, 15 May 2002 22:47:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA01301; Mon, 13 May 2002 20:31:59 -0400 (EDT) Resent-Date: Mon, 13 May 2002 20:31:59 -0400 (EDT) Resent-Message-Id: <200205140031.UAA01301@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA01198 for ; Mon, 13 May 2002 20:31:27 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id UAA29982 for ; Mon, 13 May 2002 20:31:26 -0400 Received: (qmail 29685 invoked by uid 0); 14 May 2002 00:31:16 -0000 Received: from p3ee2482d.dip.t-dialin.net (HELO lisa) (62.226.72.45) by mail.gmx.net (mp010-rz3) with SMTP; 14 May 2002 00:31:16 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "Webdav WG \(E-mail\)" Date: Tue, 14 May 2002 02:31:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6223 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Tuesday, May 14, 2002 1:56 AM > To: Webdav WG (E-mail) > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > > Joe Orton writes: > > I just dropped the xlink: from the href attribute, and got rid of the > > xlink:role attribute entirely, giving e.g.: > > > > > > > > Source > > href="http://example.com/dav/render.xsl">Stylesheet > > > > > > > > > > I like this, except for the "Source" and "Stylesheet" not being individual > elements or attributes. The i18n characteristics of the approach above are Why is that a problem? > not great -- I can just see a Kanji UI popping up a pick list of English > words, ugh. What was the perceived problem with using the xlink:role I think Joe's example is just missing the statement that the human-readable text needs to be qualified with xml:lang *somewhere* in scope. > attribute (and Xlink syntax in general?) That I'd like to know as well. From w3c-dist-auth-request@w3.org Wed May 15 22:49: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 WAA01233 for ; Wed, 15 May 2002 22:49:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA08742; Tue, 14 May 2002 09:28:23 -0400 (EDT) Resent-Date: Tue, 14 May 2002 09:28:23 -0400 (EDT) Resent-Message-Id: <200205141328.JAA08742@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA02242 for ; Tue, 14 May 2002 08:16:08 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA06558 for ; Tue, 14 May 2002 07:51:10 -0400 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Tue, 14 May 2002 07:46:05 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 07:50:33 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B106D9C684@SUS-MA1IT01> From: "Clemm, Geoff" To: "Webdav WG (E-mail)" Date: Tue, 14 May 2002 07:50:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6224 X-Loop: w3c-dist-auth@w3.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 prefer keeping everything an element (e.g. an href element and a sourcetype element), e.g.: "http://example.com/dav/source.xml" Source "http://example.com/dav/render.xsl" Stylesheet "http://example.com/dav/etc.etc" for the standard reasons why elements are preferable to attributes. Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Monday, May 13, 2002 7:56 PM To: Webdav WG (E-mail) Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Joe Orton writes: > I just dropped the xlink: from the href attribute, and got rid of the > xlink:role attribute entirely, giving e.g.: > > > > Source > Stylesheet > > > > I like this, except for the "Source" and "Stylesheet" not being individual elements or attributes. The i18n characteristics of the approach above are not great -- I can just see a Kanji UI popping up a pick list of English words, ugh. What was the perceived problem with using the xlink:role attribute (and Xlink syntax in general?) - Jim From w3c-dist-auth-request@w3.org Wed May 15 23:06: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 XAA01466 for ; Wed, 15 May 2002 23:06:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA01404; Wed, 15 May 2002 06:54:10 -0400 (EDT) Resent-Date: Wed, 15 May 2002 06:54:10 -0400 (EDT) Resent-Message-Id: <200205151054.GAA01404@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA01291 for ; Wed, 15 May 2002 06:53:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA22145 for ; Wed, 15 May 2002 06:53:21 -0400 Received: (qmail 5308 invoked by uid 0); 15 May 2002 10:52:46 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 15 May 2002 10:52:46 -0000 From: "Julian Reschke" To: "Joe Orton" , "Webdav WG \(E-mail\)" Date: Wed, 15 May 2002 12:52:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20020515113132.A7136@light.plus.com> Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6228 X-Loop: w3c-dist-auth@w3.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 Joe Orton > Sent: Wednesday, May 15, 2002 12:32 PM > To: Webdav WG (E-mail) > Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > On Wed, May 15, 2002 at 01:19:00AM +0200, Julian Reschke wrote: > > > I just thought it was unnecessary to have to depend on yet another > > > specification for something this simple. > > > > What do you mean by "depend"? We just reuse two standard attribute names > > (xlink:href and xlink:role). That's what XLink is for -- if every > > spec/document/protocol designer would take this position, it > wouldn't make > > any sense to try to come up with common vocabularies for this. > > I just mean it's annoying to have to go and read Yet Another XSpec to > find out how to implement WebDAV. If the DAV spec can explain that the > xlink:href attribute must contain a URI-reference, and that xlink:role > is entirely optional, then it's not really a problem. OK, I'll try to come up with the right wording. > ... > > So again, why not just use the Xlink [1] compatible syntax that > I proposed > > back in October [2]: > > > > > > > > > xlink:role="UriDescribingTheRole" xml:lang="en">source file > > > xlink:role="UriDescribingTheRole" xml:lang="en">library file > > > xlink:role="UriDescribingTheRole" xml:lang="en">makefile > > > > > > > > What's wrong with it? It fulfills all requirements and uses W3C > specs where > > applicable. > > It does mean requiring that clients resolve XML namespaces on attribute > names, which hasn't be necessary so far to implement a DAV client (in my > experience anyway); possible interoperability issues there. A DAV client *must* use an XML namespace aware parser anyway. Do you say that there are parser that do support namespaces on elements, but don't on attributes? > I'll implement this source-set proposal sometime this week hopefully, > given that nobody else objects to using XLink. Sounds great. From w3c-dist-auth-request@w3.org Wed May 15 23:12: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 XAA01591 for ; Wed, 15 May 2002 23:12:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA22845; Mon, 13 May 2002 19:05:13 -0400 (EDT) Resent-Date: Mon, 13 May 2002 19:05:13 -0400 (EDT) Resent-Message-Id: <200205132305.TAA22845@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA22791 for ; Mon, 13 May 2002 19:04:25 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA20482 for ; Mon, 13 May 2002 19:04:24 -0400 Received: (qmail 29987 invoked by uid 0); 13 May 2002 23:03:52 -0000 Received: from p3ee2482d.dip.t-dialin.net (HELO lisa) (62.226.72.45) by mail.gmx.net (mp010-rz3) with SMTP; 13 May 2002 23:03:52 -0000 From: "Julian Reschke" To: "Joe Orton" , "Webdav WG \(E-mail\)" Date: Tue, 14 May 2002 01:03:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020513234650.A5389@light.plus.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6220 X-Loop: w3c-dist-auth@w3.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 Joe, - the point of a machine-readable link type is that a client may be able to offer a better user interface if it knows what kind of link this is. For instance, there might be a special "role" for the XSLT file used for creating an HTML presentation of an XML file, and certainly it would be good for client to be able to detect whether one of the sources plays this role. No, we don't have to define roles, but it certainly makes sense to have an optional place where they *may* be reported. XLink reports them using URIs, and I think so should we. - you have removed the XLink compatible syntax without, but have stayed with the href attribute. This makes your format both incompatible with XLink and the standard DAV:href format (which can be used by RFC3253's expand-property REPORT). Why did you do this? It doesn't make your format simple to process -- it just saves a few characters in the XML representation. I think HREFs should either be reported consistent with other WebDAV standards (DAV:href, supported by the expand-property REPORT), or compatible with XLink (which I would personally prefer). Unfortunately, we can't have both at the same time... Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton > Sent: Tuesday, May 14, 2002 12:47 AM > To: Webdav WG (E-mail) > Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > On Tue, May 14, 2002 at 12:15:24AM +0200, Julian Reschke wrote: > > I'm happy to have a different format (I've got enough flak promoting > > XLink-compatible syntax :-). My requirements are > > > > - must support multiple links > > - there must be a machine-readable description for the link type > > - the should be a human-readable description for the link type > > > > Please post what you're using right now -- we'll probably able > to extend if > > necessary. > > I just dropped the xlink: from the href attribute, and got rid of the > xlink:role attribute entirely, giving e.g.: > > > > Source > Stylesheet > > > > > which should satisfy your first and third requirements; I'm not sure > about "machine-readable" link descriptions being mandatory. My client > doesn't need to understand anything about the link, I just want it to be > able to display a menu of "URI: description" choices when there is >1 > source available, so that the user can decide. > > (Similarly, the minimum amount of server configuration I'd like to > require is saying e.g. "/dav/render.xsl is a source of /dav/*.xml") > > Regards, > > joe > From w3c-dist-auth-request@w3.org Thu May 16 01:38:21 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 BAA05237 for ; Thu, 16 May 2002 01:38:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA22113; Thu, 16 May 2002 01:37:46 -0400 (EDT) Resent-Date: Thu, 16 May 2002 01:37:46 -0400 (EDT) Resent-Message-Id: <200205160537.BAA22113@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA22083 for ; Thu, 16 May 2002 01:37:30 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id BAA27712 for ; Thu, 16 May 2002 01:37:29 -0400 Received: (qmail 24226 invoked by uid 0); 16 May 2002 05:36:58 -0000 Received: from p3ee24776.dip.t-dialin.net (HELO lisa) (62.226.71.118) by mail.gmx.net (mp004-rz3) with SMTP; 16 May 2002 05:36:58 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "Webdav WG \(E-mail\)" Date: Thu, 16 May 2002 07:36:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B106D9C684@SUS-MA1IT01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6232 X-Loop: w3c-dist-auth@w3.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, May 14, 2002 1:50 PM > To: Webdav WG (E-mail) > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > I would prefer keeping everything an element (e.g. an href element and > a sourcetype element), e.g.: > > > > > "http://example.com/dav/source.xml" > Source > > "http://example.com/dav/render.xsl" > Stylesheet > > "http://example.com/dav/etc.etc" > > > > for the standard reasons why elements are preferable to attributes. Geoff, - there's plainly no consensus in the XML developer community about that, - what's the *benefit* of marking up a URI as element instead of an attribute, and if there is one, why do you think that XLink ignore this fact, - your proposal doesn't include a standard way for definining the type of a link (an XLink feature that my proposal simple inherits). Julian From w3c-dist-auth-request@w3.org Thu May 16 02:13:56 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 CAA14038 for ; Thu, 16 May 2002 02:13:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA25154; Thu, 16 May 2002 02:06:39 -0400 (EDT) Resent-Date: Thu, 16 May 2002 02:06:39 -0400 (EDT) Resent-Message-Id: <200205160606.CAA25154@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA25119 for ; Thu, 16 May 2002 02:06:26 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA31049 for ; Thu, 16 May 2002 02:06:26 -0400 Received: (qmail 21317 invoked by uid 0); 16 May 2002 06:05:55 -0000 Received: from p3ee24776.dip.t-dialin.net (HELO lisa) (62.226.71.118) by mail.gmx.net (mp013-rz3) with SMTP; 16 May 2002 06:05:55 -0000 From: "Julian Reschke" To: "Jason Crawford" , Date: Thu, 16 May 2002 08:05:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6233 X-Loop: w3c-dist-auth@w3.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: Wednesday, May 15, 2002 6:45 PM > To: w3c-dist-auth@w3c.org > Subject: Issue: LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS > > > > See the following posting. In it Julian suggests that we clarify the > format of the lockdiscovery property if a resource if under the influence > of multiple shared locks. > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0215.html > > Do we feel that this is necessary? If so, what do you suggest? Jason, back when I wrote this the point was to - report the bug in IIS and - have the bug description archived. I don't think that RFC2518 really needs to be changed. However, a sample for DAV:lockdiscovery for a resource with shared locks wouldn't hurt. From w3c-dist-auth-request@w3.org Thu May 16 13:42: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 NAA03630 for ; Thu, 16 May 2002 13:42:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA10251; Thu, 16 May 2002 12:54:58 -0400 (EDT) Resent-Date: Thu, 16 May 2002 12:54:58 -0400 (EDT) Resent-Message-Id: <200205161654.MAA10251@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA10067 for ; Thu, 16 May 2002 12:54:13 -0400 (EDT) Received: from imo-d10.mx.aol.com (imo-d10.mx.aol.com [205.188.157.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA31141 for ; Thu, 16 May 2002 12:54:13 -0400 From: DLCrossman@aol.com Received: from DLCrossman@aol.com by imo-d10.mx.aol.com (mail_out_v32.5.) id r.14e.dfabfcb (4008) for ; Thu, 16 May 2002 12:53:37 -0400 (EDT) Message-ID: <14e.dfabfcb.2a153e11@aol.com> Date: Thu, 16 May 2002 12:53:37 EDT To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 114 Subject: Parallel vs. Serial Editing Strategies Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6234 X-Loop: w3c-dist-auth@w3.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 Can anyone give me a brief description of parallel and serial editing strategies, and perhaps pros and cons of using one over the other? If not, is anyone able to refer me to a web location where I might find this type of info? TIA, Morgan Foster Freelance Writer/Editor Boston, MA USA From w3c-dist-auth-request@w3.org Fri May 17 14: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 OAA27714 for ; Fri, 17 May 2002 14:59:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05137; Fri, 17 May 2002 14:57:31 -0400 (EDT) Resent-Date: Fri, 17 May 2002 14:57:31 -0400 (EDT) Resent-Message-Id: <200205171857.OAA05137@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA05106 for ; Fri, 17 May 2002 14:57:10 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA06785 for ; Fri, 17 May 2002 14:57:10 -0400 Received: from Tycho (dhcp-60-113.cse.ucsc.edu [128.114.60.113]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g4HIuSN01284 for ; Fri, 17 May 2002 11:56:28 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 17 May 2002 11:56:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C1FD99.DAF30DB0" 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: Can WebDav be used with Servlet/JSP based Web Application Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6235 X-Loop: w3c-dist-auth@w3.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_01C1FD99.DAF30DB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: saad tawwab [mailto:saad.tawwab@kapscomputing.com] Sent: Thursday, May 16, 2002 11:37 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Can WebDav be used with Servlet/JSP based Web Application Hello!! Please first let me explain my problem. I am Java Developer working on a Java based Web Application. I want to provide my user with the ability to Check In, Check Out, Add and View files i.e. I want to build a version control system that is integrated with my web site. The usecase would be that the user would log into my Web Site and then be able to access a page where he will get a list of files and then he can Check-In, Check-Out, Add and View files. I have heard that WebDav provides a sort of version control mechanism. Can WebDav be integrated with a Servlet/JSP based application and allow the user to perform the task that I have listed above. Please do reply. Regards, Saad Tawwab Khan Rao Kaps Computing Inc. ------=_NextPart_000_0000_01C1FD99.DAF30DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: saad tawwab=20 [mailto:saad.tawwab@kapscomputing.com]
Sent: Thursday, May 16, = 2002=20 11:37 PM
To: w3c-dist-auth@w3.org
Subject: = [Moderator=20 Action] Can WebDav be used with Servlet/JSP based Web=20 Application

Hello!!
Please=20 first let me explain my problem. I am Java Developer working on a Java = based Web=20 Application. I want to provide my user with the ability to Check In, = Check Out,=20 Add and View files i.e. I want to build a version control system that is = integrated with my web site. The usecase would be that the user would = log into=20 my Web Site and then be able to access a page where he will get a list = of files=20 and then he can Check-In, Check-Out, Add and View files.


I have heard that WebDav provides a sort = of version=20 control mechanism. Can WebDav be integrated with a Servlet/JSP based = application=20 and allow the user to perform the task that I have listed above. Please = do=20 reply.


Regards,
Saad=20 Tawwab Khan Rao
Kaps Computing = Inc.=20

------=_NextPart_000_0000_01C1FD99.DAF30DB0-- From w3c-dist-auth-request@w3.org Fri May 17 15:03: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 PAA27944 for ; Fri, 17 May 2002 15:03:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA05860; Fri, 17 May 2002 15:02:15 -0400 (EDT) Resent-Date: Fri, 17 May 2002 15:02:15 -0400 (EDT) Resent-Message-Id: <200205171902.PAA05860@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA05822 for ; Fri, 17 May 2002 15:01:59 -0400 (EDT) Received: from mou-002.mongoosetech.com ([65.112.244.251]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA08046 for ; Fri, 17 May 2002 15:01:59 -0400 Date: Fri, 17 May 2002 14:01:58 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FDD5.51CA51B5" Message-ID: <8B76843ADB33A34EB253216BEC0221B7196BE8@mou-002.mongoosetech.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: Can WebDav be used with Servlet/JSP based Web Application Content-Class: urn:content-classes:message thread-index: AcH91NVGEbuTPoLXTG20HOsCweCLZwAADMFw From: "Eric Hodges" To: "WebDAV" Subject: RE: Can WebDav be used with Servlet/JSP based Web Application Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6236 X-Loop: w3c-dist-auth@w3.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_001_01C1FDD5.51CA51B5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes it can. I wrote a web component for our portal framework with JSPs = using JavaScript to provide browsing, upload, download, permission management, property editing, etc. on a web page. =20 -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]=20 Sent: Friday, May 17, 2002 1:56 PM To: WebDAV Subject: FW: Can WebDav be used with Servlet/JSP based Web Application Accidentally caught by the spam filter. =20 - Jim -----Original Message----- From: saad tawwab [mailto:saad.tawwab@kapscomputing.com] Sent: Thursday, May 16, 2002 11:37 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Can WebDav be used with Servlet/JSP based = Web Application Hello!!=20 Please first let me explain my problem. I am Java Developer working on a = Java based Web Application. I want to provide my user with the ability to = Check In, Check Out, Add and View files i.e. I want to build a version control system that is integrated with my web site. The usecase would be that = the user would log into my Web Site and then be able to access a page where = he will get a list of files and then he can Check-In, Check-Out, Add and = View files.=20 I have heard that WebDav provides a sort of version control mechanism. = Can WebDav be integrated with a Servlet/JSP based application and allow the = user to perform the task that I have listed above. Please do reply. Regards,=20 Saad Tawwab Khan Rao=20 Kaps Computing Inc.=20 ------_=_NextPart_001_01C1FDD5.51CA51B5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Yes it=20 can.  I wrote a web component for our portal framework with JSPs = using=20 JavaScript to provide browsing, upload, download, permission management, = property editing, etc. on a web page.
 
-----Original Message-----
From: Jim = Whitehead=20 [mailto:ejw@cse.ucsc.edu]
Sent: Friday, May 17, 2002 1:56=20 PM
To: WebDAV
Subject: FW: Can WebDav be used with = Servlet/JSP based Web Application

Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: saad tawwab=20 [mailto:saad.tawwab@kapscomputing.com]
Sent: Thursday, May = 16, 2002=20 11:37 PM
To: w3c-dist-auth@w3.org
Subject: = [Moderator=20 Action] Can WebDav be used with Servlet/JSP based Web=20 Application

Hello!!
Please=20 first let me explain my problem. I am Java Developer working on a Java = based=20 Web Application. I want to provide my user with the ability to Check = In, Check=20 Out, Add and View files i.e. I want to build a version control system = that is=20 integrated with my web site. The usecase would be that the user would = log into=20 my Web Site and then be able to access a page where he will get a list = of=20 files and then he can Check-In, Check-Out, Add and View files. =


I have heard that WebDav provides a = sort of version=20 control mechanism. Can WebDav be integrated with a Servlet/JSP based=20 application and allow the user to perform the task that I have listed = above.=20 Please do reply.


Regards,
Saad=20 Tawwab Khan Rao
Kaps Computing = Inc.=20

------_=_NextPart_001_01C1FDD5.51CA51B5-- From w3c-dist-auth-request@w3.org Fri May 17 15:20: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 PAA28822 for ; Fri, 17 May 2002 15:20:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA07010; Fri, 17 May 2002 15:19:34 -0400 (EDT) Resent-Date: Fri, 17 May 2002 15:19:34 -0400 (EDT) Resent-Message-Id: <200205171919.PAA07010@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA06960 for ; Fri, 17 May 2002 15:19:17 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA10704 for ; Fri, 17 May 2002 15:19:17 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Fri, 17 May 2002 15:18:32 -0400 (Eastern Daylight Time) Received: from moose ([198.144.203.248]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 17 May 2002 15:18:30 -0400 From: "Lisa Dusseault" To: "'Eric Hodges'" , "'WebDAV'" Date: Fri, 17 May 2002 12:19:36 -0700 Message-ID: <000401c1fdd7$c98b9a90$f8cb90c6@moose> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <8B76843ADB33A34EB253216BEC0221B7196BE8@mou-002.mongoosetech.com> X-OriginalArrivalTime: 17 May 2002 19:18:30.0699 (UTC) FILETIME=[A12D6FB0:01C1FDD7] Subject: RE: Can WebDav be used with Servlet/JSP based Web Application Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6237 X-Loop: w3c-dist-auth@w3.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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1FD9D.1D2FCFD0" ------=_NextPart_000_0005_01C1FD9D.1D2FCFD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MessageYou can also program WebDAV requests/responses using a Servlet Engine. In addition to the doGet() method, the service() method of the servlet class must handle the WebDAV methods such as PROPFIND, PROPPATCH, MOVE, COPY... and any DeltaV methods that you end up supporting on the server. One "gotcha" with servlet engines is that some WebDAV clients won't talk to a WebDAV server unless the root directory '/' responds to the OPTIONS requests. So the WebDAV servlet has to take over the root of the server address space, rather than just be mounted as something like myserver.com/servlet/webdav. Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Hodges Sent: Friday, May 17, 2002 12:02 PM To: WebDAV Subject: RE: Can WebDav be used with Servlet/JSP based Web Application Yes it can. I wrote a web component for our portal framework with JSPs using JavaScript to provide browsing, upload, download, permission management, property editing, etc. on a web page. -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Friday, May 17, 2002 1:56 PM To: WebDAV Subject: FW: Can WebDav be used with Servlet/JSP based Web Application Accidentally caught by the spam filter. - Jim -----Original Message----- From: saad tawwab [mailto:saad.tawwab@kapscomputing.com] Sent: Thursday, May 16, 2002 11:37 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Can WebDav be used with Servlet/JSP based Web Application Hello!! Please first let me explain my problem. I am Java Developer working on a Java based Web Application. I want to provide my user with the ability to Check In, Check Out, Add and View files i.e. I want to build a version control system that is integrated with my web site. The usecase would be that the user would log into my Web Site and then be able to access a page where he will get a list of files and then he can Check-In, Check-Out, Add and View files. I have heard that WebDav provides a sort of version control mechanism. Can WebDav be integrated with a Servlet/JSP based application and allow the user to perform the task that I have listed above. Please do reply. Regards, Saad Tawwab Khan Rao Kaps Computing Inc. ------=_NextPart_000_0005_01C1FD9D.1D2FCFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
You=20 can also program WebDAV requests/responses using a Servlet Engine.  = In=20 addition to the doGet() method, the service() method of the servlet = class must=20 handle the WebDAV methods such as PROPFIND, PROPPATCH, MOVE, COPY... and = any=20 DeltaV methods that you end up supporting on the = server.
 
One=20 "gotcha" with servlet engines is that some WebDAV clients won't talk to = a WebDAV=20 server unless the root directory '/' responds to the OPTIONS = requests.  So=20 the WebDAV servlet has to take over the root of the server address = space, rather=20 than just be mounted as something like=20 myserver.com/servlet/webdav.
 
Lisa
-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric=20 Hodges
Sent: Friday, May 17, 2002 12:02 PM
To:=20 WebDAV
Subject: RE: Can WebDav be used with Servlet/JSP = based Web=20 Application

Yes=20 it can.  I wrote a web component for our portal framework with = JSPs using=20 JavaScript to provide browsing, upload, download, permission = management,=20 property editing, etc. on a web page.
 
-----Original Message-----
From: = Jim Whitehead=20 [mailto:ejw@cse.ucsc.edu]
Sent: Friday, May 17, 2002 1:56 = PM
To: WebDAV
Subject: FW: Can WebDav be used = with=20 Servlet/JSP based Web Application

Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: saad tawwab=20 [mailto:saad.tawwab@kapscomputing.com]
Sent: Thursday, May = 16,=20 2002 11:37 PM
To: w3c-dist-auth@w3.org
Subject:=20 [Moderator Action] Can WebDav be used with Servlet/JSP based Web=20 Application

Hello!!
Please=20 first let me explain my problem. I am Java Developer working on a = Java based=20 Web Application. I want to provide my user with the ability to Check = In,=20 Check Out, Add and View files i.e. I want to build a version control = system=20 that is integrated with my web site. The usecase would be that the = user=20 would log into my Web Site and then be able to access a page where = he will=20 get a list of files and then he can Check-In, Check-Out, Add and = View files.=20


I have heard that WebDav provides a = sort of=20 version control mechanism. Can WebDav be integrated with a = Servlet/JSP based=20 application and allow the user to perform the task that I have = listed above.=20 Please do reply.


Regards,
Saad=20 Tawwab Khan Rao
Kaps = Computing=20 Inc.

------=_NextPart_000_0005_01C1FD9D.1D2FCFD0-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Mon May 20 07:29: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 HAA06697 for ; Mon, 20 May 2002 07:29:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA26046; Mon, 20 May 2002 07:27:05 -0400 (EDT) Resent-Date: Mon, 20 May 2002 07:27:05 -0400 (EDT) Resent-Message-Id: <200205201127.HAA26046@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA26021 for ; Mon, 20 May 2002 07:26:57 -0400 (EDT) Received: from bosvwl02.infy.com (bosvwl02.infy.com [216.52.49.36]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA19779 for ; Mon, 20 May 2002 07:26:58 -0400 Received: from 192.168.200.81 by bosvwl02.infy.com (InterScan E-Mail VirusWall NT); Mon, 20 May 2002 07:25:36 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 May 2002 16:53:35 +0530 Received: from kecmsg04.ad.infosys.com ([192.168.117.9]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 May 2002 16:53:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-0a70ca18-b247-4f4f-88ff-11bc952875f9" Date: Mon, 20 May 2002 16:53:35 +0530 Message-ID: <1BD922A62552D411B48A00D0B7472375042F7317@kecmsg04.ad.infosys.com> Thread-Topic: Can WebDav be used with Servlet/JSP based Web Application Thread-Index: AcH917JhPn+kLUZtTyyipmz3AAd2VwB/xmTA From: "Rajiv A V" To: "WebDAV" X-OriginalArrivalTime: 20 May 2002 11:23:35.0618 (UTC) FILETIME=[C8066220:01C1FFF0] Subject: RE: Can WebDav be used with Servlet/JSP based Web Application Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6238 X-Loop: w3c-dist-auth@w3.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. ------=_NextPartTM-000-0a70ca18-b247-4f4f-88ff-11bc952875f9 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FFF0.C807CB74" ------_=_NextPart_001_01C1FFF0.C807CB74 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The server implmentation is fine but if we use a web-based application = then, to talk to the actual server that processes the webdav requests we = have to add an extra layer in the archectiure of the system. This new = layer would sit between the web-browsers requests and the webdav = implemenation. Wonder how this would affect performance? =20 Rajiv -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Saturday, May 18, 2002 12:50 AM To: 'Eric Hodges'; 'WebDAV' Subject: RE: Can WebDav be used with Servlet/JSP based Web Application You can also program WebDAV requests/responses using a Servlet Engine. = In addition to the doGet() method, the service() method of the servlet = class must handle the WebDAV methods such as PROPFIND, PROPPATCH, MOVE, = COPY... and any DeltaV methods that you end up supporting on the server. =20 One "gotcha" with servlet engines is that some WebDAV clients won't talk = to a WebDAV server unless the root directory '/' responds to the OPTIONS = requests. So the WebDAV servlet has to take over the root of the server = address space, rather than just be mounted as something like = myserver.com/servlet/webdav. =20 Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Hodges Sent: Friday, May 17, 2002 12:02 PM To: WebDAV Subject: RE: Can WebDav be used with Servlet/JSP based Web Application Yes it can. I wrote a web component for our portal framework with JSPs = using JavaScript to provide browsing, upload, download, permission = management, property editing, etc. on a web page. =20 -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]=20 Sent: Friday, May 17, 2002 1:56 PM To: WebDAV Subject: FW: Can WebDav be used with Servlet/JSP based Web Application Accidentally caught by the spam filter. =20 - Jim -----Original Message----- From: saad tawwab [mailto:saad.tawwab@kapscomputing.com] Sent: Thursday, May 16, 2002 11:37 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Can WebDav be used with Servlet/JSP based = Web Application Hello!!=20 Please first let me explain my problem. I am Java Developer working on a = Java based Web Application. I want to provide my user with the ability = to Check In, Check Out, Add and View files i.e. I want to build a = version control system that is integrated with my web site. The usecase = would be that the user would log into my Web Site and then be able to = access a page where he will get a list of files and then he can = Check-In, Check-Out, Add and View files.=20 I have heard that WebDav provides a sort of version control mechanism. = Can WebDav be integrated with a Servlet/JSP based application and allow = the user to perform the task that I have listed above. Please do reply. Regards,=20 Saad Tawwab Khan Rao=20 Kaps Computing Inc.=20 ------_=_NextPart_001_01C1FFF0.C807CB74 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
The=20 server implmentation is fine but if we use a web-based application then, = to talk=20 to the actual server that processes the webdav requests we have to add = an extra=20 layer in the archectiure of the system. This new layer would sit between = the=20 web-browsers requests and the webdav implemenation. Wonder how this = would affect=20 performance?
 
 =20 Rajiv
-----Original Message-----
From: Lisa Dusseault=20 [mailto:ldusseault@xythos.com]
Sent: Saturday, May 18, 2002 = 12:50=20 AM
To: 'Eric Hodges'; 'WebDAV'
Subject: RE: Can = WebDav be=20 used with Servlet/JSP based Web Application

You=20 can also program WebDAV requests/responses using a Servlet = Engine.  In=20 addition to the doGet() method, the service() method of the servlet = class must=20 handle the WebDAV methods such as PROPFIND, PROPPATCH, MOVE, COPY... = and any=20 DeltaV methods that you end up supporting on the = server.
 
One=20 "gotcha" with servlet engines is that some WebDAV clients won't talk = to a=20 WebDAV server unless the root directory '/' responds to the OPTIONS=20 requests.  So the WebDAV servlet has to take over the root of the = server=20 address space, rather than just be mounted as something like=20 myserver.com/servlet/webdav.
 
Lisa
-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org]On=20 Behalf Of Eric Hodges
Sent: Friday, May 17, 2002 12:02 = PM
To: WebDAV
Subject: RE: Can WebDav be used = with=20 Servlet/JSP based Web Application

Yes it can.  I wrote a web component = for our=20 portal framework with JSPs using JavaScript to provide browsing, = upload,=20 download, permission management, property editing, etc. on a web=20 page.
 
-----Original Message-----
From: = Jim=20 Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Friday, May = 17, 2002=20 1:56 PM
To: WebDAV
Subject: FW: Can WebDav be = used=20 with Servlet/JSP based Web Application

Accidentally caught by the spam=20 filter.
 
- Jim
-----Original Message-----
From: saad tawwab=20 [mailto:saad.tawwab@kapscomputing.com]
Sent: Thursday, = May 16,=20 2002 11:37 PM
To: = w3c-dist-auth@w3.org
Subject:=20 [Moderator Action] Can WebDav be used with Servlet/JSP based Web=20 Application

Hello!!
Please first let me explain my problem. I am Java = Developer working=20 on a Java based Web Application. I want to provide my user with = the=20 ability to Check In, Check Out, Add and View files i.e. I want to = build a=20 version control system that is integrated with my web site. The = usecase=20 would be that the user would log into my Web Site and then be able = to=20 access a page where he will get a list of files and then he can = Check-In,=20 Check-Out, Add and View files.


I have heard that WebDav provides a = sort of=20 version control mechanism. Can WebDav be integrated with a = Servlet/JSP=20 based application and allow the user to perform the task that I = have=20 listed above. Please do reply.


Regards,
Saad Tawwab Khan Rao
Kaps=20 Computing Inc.=20

------_=_NextPart_001_01C1FFF0.C807CB74-- ------=_NextPartTM-000-0a70ca18-b247-4f4f-88ff-11bc952875f9-- From w3c-dist-auth-request@w3.org Mon May 20 14:40: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 OAA28974 for ; Mon, 20 May 2002 14:40:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA12432; Mon, 20 May 2002 14:39:38 -0400 (EDT) Resent-Date: Mon, 20 May 2002 14:39:38 -0400 (EDT) Resent-Message-Id: <200205201839.OAA12432@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA12412 for ; Mon, 20 May 2002 14:39:28 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA30741 for ; Mon, 20 May 2002 14:39:28 -0400 Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17396; Mon, 20 May 2002 11:38:57 -0700 (PDT) Received: from ms-usca15-11.red.iplanet.com (ms-usca15-11.red.iplanet.com [192.18.56.153]) by dm-usca19-13.red.iplanet.com (8.10.2+Sun/8.10.2/IPLANET,v1.1) with ESMTP id g4KIddU06201; Mon, 20 May 2002 11:39:39 -0700 (PDT) Received: from Sun.com (h-192-18-177-140.red.iplanet.com [192.18.177.140]) by ipost.red.iplanet.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0GWF00F00AGX5Z@ipost.red.iplanet.com>; Mon, 20 May 2002 11:38:57 -0700 (PDT) Date: Mon, 20 May 2002 11:39:07 -0700 From: Murthy Chintalapati To: Rajiv A V Cc: WebDAV Message-id: <3CE942CB.4040401@Sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rYrPkFXJj2IoM3JKhbf2uw)" X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 References: <1BD922A62552D411B48A00D0B7472375042F7317@kecmsg04.ad.infosys.com> Subject: Re: Can WebDav be used with Servlet/JSP based Web Application Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6239 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --Boundary_(ID_rYrPkFXJj2IoM3JKhbf2uw) Content-type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7BIT It depends how your layer interposes the WebDAV runtime and what additional overhead it adds to overall request processing. For Servlet based implementation, there is Filter mechanism -- which is used very effectively (say for caching) without much performance hit. Hope this helps. --cvr murthy Rajiv A V wrote: > The server implmentation is fine but if we use a web-based application > then, to talk to the actual server that processes the webdav requests > we have to add an extra layer in the archectiure of the system. This > new layer would sit between the web-browsers requests and the webdav > implemenation. Wonder how this would affect performance? > > > > Rajiv > > -----Original Message----- > From: Lisa Dusseault [mailto:ldusseault@xythos.com] > Sent: Saturday, May 18, 2002 12:50 AM > To: 'Eric Hodges'; 'WebDAV' > Subject: RE: Can WebDav be used with Servlet/JSP based Web Application > > You can also program WebDAV requests/responses using a Servlet > Engine. In addition to the doGet() method, the service() method > of the servlet class must handle the WebDAV methods such as > PROPFIND, PROPPATCH, MOVE, COPY... and any DeltaV methods that you > end up supporting on the server. > > > > One "gotcha" with servlet engines is that some WebDAV clients > won't talk to a WebDAV server unless the root directory '/' > responds to the OPTIONS requests. So the WebDAV servlet has to > take over the root of the server address space, rather than just > be mounted as something like myserver.com/servlet/webdav. > > > > Lisa > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Eric Hodges > Sent: Friday, May 17, 2002 12:02 PM > To: WebDAV > Subject: RE: Can WebDav be used with Servlet/JSP based Web > Application > > Yes it can. I wrote a web component for our portal framework > with JSPs using JavaScript to provide browsing, upload, > download, permission management, property editing, etc. on a > web page. > > > > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Friday, May 17, 2002 1:56 PM > To: WebDAV > Subject: FW: Can WebDav be used with Servlet/JSP based Web > Application > > Accidentally caught by the spam filter. > > > > - Jim > > -----Original Message----- > From: saad tawwab [mailto:saad.tawwab@kapscomputing.com] > Sent: Thursday, May 16, 2002 11:37 PM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] Can WebDav be used with > Servlet/JSP based Web Application > > Hello!! > Please first let me explain my problem. I am Java > Developer working on a Java based Web Application. I want > to provide my user with the ability to Check In, Check > Out, Add and View files i.e. I want to build a version > control system that is integrated with my web site. The > usecase would be that the user would log into my Web Site > and then be able to access a page where he will get a list > of files and then he can Check-In, Check-Out, Add and View > files. > > > I have heard that WebDav provides a sort of version > control mechanism. Can WebDav be integrated with a > Servlet/JSP based application and allow the user to > perform the task that I have listed above. Please do reply. > > > Regards, > Saad Tawwab Khan Rao > Kaps Computing Inc. > --Boundary_(ID_rYrPkFXJj2IoM3JKhbf2uw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT It depends how your layer interposes the WebDAV runtime and what additional overhead it adds to overall request processing. For Servlet based implementation, there is Filter mechanism -- which is used very effectively (say for caching) without much performance hit.

Hope this helps.
--cvr murthy

Rajiv A V wrote:
Message
The server implmentation is fine but if we use a web-based application then, to talk to the actual server that processes the webdav requests we have to add an extra layer in the archectiure of the system. This new layer would sit between the web-browsers requests and the webdav implemenation. Wonder how this would affect performance?
 
  Rajiv
-----Original Message-----
From: Lisa Dusseault [mailto:ldusseault@xythos.com]
Sent: Saturday, May 18, 2002 12:50 AM
To: 'Eric Hodges'; 'WebDAV'
Subject: RE: Can WebDav be used with Servlet/JSP based Web Application

You can also program WebDAV requests/responses using a Servlet Engine.  In addition to the doGet() method, the service() method of the servlet class must handle the WebDAV methods such as PROPFIND, PROPPATCH, MOVE, COPY... and any DeltaV methods that you end up supporting on the server.
 
One "gotcha" with servlet engines is that some WebDAV clients won't talk to a WebDAV server unless the root directory '/' responds to the OPTIONS requests.  So the WebDAV servlet has to take over the root of the server address space, rather than just be mounted as something like myserver.com/servlet/webdav.
 
Lisa
-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Eric Hodges
Sent: Friday, May 17, 2002 12:02 PM
To: WebDAV
Subject: RE: Can WebDav be used with Servlet/JSP based Web Application

Yes it can.  I wrote a web component for our portal framework with JSPs using JavaScript to provide browsing, upload, download, permission management, property editing, etc. on a web page.
 
-----Original Message-----
From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Friday, May 17, 2002 1:56 PM
To: WebDAV
Subject: FW: Can WebDav be used with Servlet/JSP based Web Application

Accidentally caught by the spam filter.
 
- Jim
-----Original Message-----
From: saad tawwab [mailto:saad.tawwab@kapscomputing.com]
Sent: Thursday, May 16, 2002 11:37 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] Can WebDav be used with Servlet/JSP based Web Application

Hello!!
Please first let me explain my problem. I am Java Developer working on a Java based Web Application. I want to provide my user with the ability to Check In, Check Out, Add and View files i.e. I want to build a version control system that is integrated with my web site. The usecase would be that the user would log into my Web Site and then be able to access a page where he will get a list of files and then he can Check-In, Check-Out, Add and View files.


I have heard that WebDav provides a sort of version control mechanism. Can WebDav be integrated with a Servlet/JSP based application and allow the user to perform the task that I have listed above. Please do reply.


Regards,
Saad Tawwab Khan Rao
Kaps Computing Inc.


--Boundary_(ID_rYrPkFXJj2IoM3JKhbf2uw)-- From w3c-dist-auth-request@w3.org Mon May 20 16:57: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 QAA10517 for ; Mon, 20 May 2002 16:57:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA25702; Mon, 20 May 2002 16:55:55 -0400 (EDT) Resent-Date: Mon, 20 May 2002 16:55:55 -0400 (EDT) Resent-Message-Id: <200205202055.QAA25702@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA25682 for ; Mon, 20 May 2002 16:55:49 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA27396 for ; Mon, 20 May 2002 16:55:48 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g4KKt6N04914 for ; Mon, 20 May 2002 13:55:06 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 20 May 2002 13:54:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Fwd: DAV question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6240 X-Loop: w3c-dist-auth@w3.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. - Jim -----Original Message----- From: Rick Pinson [mailto:rickpinson@yahoo.com] Sent: Saturday, May 18, 2002 3:18 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Fwd: DAV question To: gstein@lyra.org Hello, Mr. Stein I submitted the following question to the ODMA site/newsgroup, and was referred to your site by a moderator there (who basically said WebDAV was the coming/current standard to investigate). If you substitute 'WebDAV' below for each 'ODMA' reference, can you provide any guidance? Thanks, Rick Pinson -------------------------------------- My partner and I are in the process of developing a Web-based specialized document management system, intended for commercial sale. We were unfamiliar with ODMA until just a couple of days ago, when my partner found the infonuovo.com Web site. We are (at least initially) developing in ASP, with an underlying SQL Server database, and have been reviewing all of the documentation on this site to try and determine: 1. If ODMA-compliance is a necessary feature to add to our product 2. If so, exactly what form this compliance would take. We have not found any ASP/SQL Server code samples on the site. We hope you can either provide some information/code samples which will help us on these two points, or else direct us to another Web site, book, etc. which will do so. Thanks! Rick Pinson __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From w3c-dist-auth-request@w3.org Mon May 20 16:57: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 QAA10532 for ; Mon, 20 May 2002 16:57:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA25768; Mon, 20 May 2002 16:56:27 -0400 (EDT) Resent-Date: Mon, 20 May 2002 16:56:27 -0400 (EDT) Resent-Message-Id: <200205202056.QAA25768@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA25722 for ; Mon, 20 May 2002 16:56:20 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA27496 for ; Mon, 20 May 2002 16:56:20 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g4KKtcN04973 for ; Mon, 20 May 2002 13:55:38 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 20 May 2002 13:55:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: Help regarding WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6241 X-Loop: w3c-dist-auth@w3.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. - Jim -----Original Message----- From: Anand Deshpande [mailto:adeshpande@etouch.net] Sent: Monday, May 20, 2002 1:09 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Help regarding WebDAV Hi Greg, My objective is to establish a connection between an application (developed in Java) with any mail Server(Ex: Exchange/Lotus). Please guide me to use WebDAV for this purpose. I mean help me to use WebDav to talk to any server (using Java). It'd be nice if you can send me the Java API to get started with WebDAV. Regards, Anand Deshpande etouch System Corp. www.etouch.net --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.281 / Virus Database: 149 - Release Date: 9/18/2001 From w3c-dist-auth-request@w3.org Tue May 21 02:21: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 CAA20958 for ; Tue, 21 May 2002 02:21:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA07923; Tue, 21 May 2002 02:20:35 -0400 (EDT) Resent-Date: Tue, 21 May 2002 02:20:35 -0400 (EDT) Resent-Message-Id: <200205210620.CAA07923@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA07642 for ; Tue, 21 May 2002 02:20:00 -0400 (EDT) Received: from bosvwl02.infy.com (bosvwl02.infy.com [216.52.49.36]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA10441 for ; Tue, 21 May 2002 02:14:32 -0400 Received: from 192.168.200.83 by bosvwl02.infy.com (InterScan E-Mail VirusWall NT); Tue, 21 May 2002 02:13:09 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS03.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 21 May 2002 11:41:28 +0530 Received: from kecmsg04.ad.infosys.com ([192.168.117.9]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 21 May 2002 11:41:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-ddc780f1-45a5-44fc-a20c-54c83f540e42" Date: Tue, 21 May 2002 11:41:28 +0530 Message-ID: <1BD922A62552D411B48A00D0B7472375042F7318@kecmsg04.ad.infosys.com> Thread-Topic: Can WebDav be used with Servlet/JSP based Web Application Thread-Index: AcIALW3F5hrLRWA3QZevWBIh1PoimAARnQuA From: "Rajiv A V" To: "WebDAV" X-OriginalArrivalTime: 21 May 2002 06:11:28.0509 (UTC) FILETIME=[583612D0:01C2008E] Subject: RE: Can WebDav be used with Servlet/JSP based Web Application Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6242 X-Loop: w3c-dist-auth@w3.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. ------=_NextPartTM-000-ddc780f1-45a5-44fc-a20c-54c83f540e42 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2008E.58136FA0" ------_=_NextPart_001_01C2008E.58136FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If anyone has any architecture or any reference implementatuion of a = Servlet/JSP based WebApplication to implement WebDAV. I would like to = have a look at it. Thanks and Regards, Rajiv -----Original Message----- From: Murthy Chintalapati [mailto:Murthy.Chintalapati@Sun.com] Sent: Tuesday, May 21, 2002 12:09 AM To: Rajiv A V Cc: WebDAV Subject: Re: Can WebDav be used with Servlet/JSP based Web Application It depends how your layer interposes the WebDAV runtime and what = additional overhead it adds to overall request processing. For Servlet = based implementation, there is Filter mechanism -- which is used very = effectively (say for caching) without much performance hit. Hope this helps. --cvr murthy Rajiv A V wrote: The server implmentation is fine but if we use a web-based application = then, to talk to the actual server that processes the webdav requests we = have to add an extra layer in the archectiure of the system. This new = layer would sit between the web-browsers requests and the webdav = implemenation. Wonder how this would affect performance? =20 Rajiv -----Original Message----- From: Lisa Dusseault [ mailto:ldusseault@xythos.com] Sent: Saturday, May 18, 2002 12:50 AM To: 'Eric Hodges'; 'WebDAV' Subject: RE: Can WebDav be used with Servlet/JSP based Web Application You can also program WebDAV requests/responses using a Servlet Engine. = In addition to the doGet() method, the service() method of the servlet = class must handle the WebDAV methods such as PROPFIND, PROPPATCH, MOVE, = COPY... and any DeltaV methods that you end up supporting on the server. =20 One "gotcha" with servlet engines is that some WebDAV clients won't talk = to a WebDAV server unless the root directory '/' responds to the OPTIONS = requests. So the WebDAV servlet has to take over the root of the server = address space, rather than just be mounted as something like = myserver.com/servlet/webdav. =20 Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [ = mailto:w3c-dist-auth-request@w3.org] On Behalf Of Eric Hodges Sent: Friday, May 17, 2002 12:02 PM To: WebDAV Subject: RE: Can WebDav be used with Servlet/JSP based Web Application Yes it can. I wrote a web component for our portal framework with JSPs = using JavaScript to provide browsing, upload, download, permission = management, property editing, etc. on a web page. =20 -----Original Message----- From: Jim Whitehead [ mailto:ejw@cse.ucsc.edu]=20 Sent: Friday, May 17, 2002 1:56 PM To: WebDAV Subject: FW: Can WebDav be used with Servlet/JSP based Web Application Accidentally caught by the spam filter. =20 - Jim -----Original Message----- From: saad tawwab [ mailto:saad.tawwab@kapscomputing.com] Sent: Thursday, May 16, 2002 11:37 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Can WebDav be used with Servlet/JSP based = Web Application Hello!! Please first let me explain my problem. I am Java Developer working on a = Java based Web Application. I want to provide my user with the ability = to Check In, Check Out, Add and View files i.e. I want to build a = version control system that is integrated with my web site. The usecase = would be that the user would log into my Web Site and then be able to = access a page where he will get a list of files and then he can = Check-In, Check-Out, Add and View files.=20 I have heard that WebDav provides a sort of version control mechanism. = Can WebDav be integrated with a Servlet/JSP based application and allow = the user to perform the task that I have listed above. Please do reply. Regards, Saad Tawwab Khan Rao Kaps Computing Inc. ------_=_NextPart_001_01C2008E.58136FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
If=20 anyone has any architecture or any reference implementatuion of a=20 Servlet/JSP based WebApplication to implement WebDAV. I would like to = have a=20 look at it.
 Thanks and Regards,
     = Rajiv
-----Original Message-----
From: Murthy = Chintalapati=20 [mailto:Murthy.Chintalapati@Sun.com]
Sent: Tuesday, May 21, = 2002=20 12:09 AM
To: Rajiv A V
Cc: = WebDAV
Subject: Re:=20 Can WebDav be used with Servlet/JSP based Web=20 Application

It depends how your layer interposes = the=20 WebDAV runtime and what additional overhead it adds to overall request = processing. For Servlet based implementation, there is Filter = mechanism --=20 which is used very effectively (say for caching) without much = performance=20 hit.

Hope this helps.
--cvr murthy

Rajiv A V = wrote:
The server implmentation is fine but if = we use a=20 web-based application then, to talk to the actual server that = processes the=20 webdav requests we have to add an extra layer in the archectiure of = the=20 system. This new layer would sit between the web-browsers requests = and the=20 webdav implemenation. Wonder how this would affect=20 performance?
 
  Rajiv
-----Original Message-----
From: Lisa Dusseault = [mailto:ldusseault@xythos.com]Sent:=20 Saturday, May 18, 2002 12:50 AM
To: 'Eric Hodges';=20 'WebDAV'
Subject: RE: Can WebDav be used with = Servlet/JSP based=20 Web Application

You can also program WebDAV requests/responses using a = Servlet=20 Engine.  In addition to the doGet() method, the service() = method of=20 the servlet class must handle the WebDAV methods such as PROPFIND, = PROPPATCH, MOVE, COPY... and any DeltaV methods that you end up = supporting=20 on the server.
 
One "gotcha" with servlet engines is that some WebDAV = clients won't=20 talk to a WebDAV server unless the root directory '/' responds to = the=20 OPTIONS requests.  So the WebDAV servlet has to take over the = root of=20 the server address space, rather than just be mounted as something = like=20 myserver.com/servlet/webdav.
 
Lisa
-----Original Message-----
From: w3c-dist-auth-request@w3.org= =20 [mailto:w3c-dist-auth-request= @w3.org]=20 On Behalf Of Eric Hodges
Sent: Friday, May 17, = 2002 12:02=20 PM
To: WebDAV
Subject: RE: Can WebDav be = used with=20 Servlet/JSP based Web Application

Yes it can.  I wrote a web = component for=20 our portal framework with JSPs using JavaScript to provide = browsing,=20 upload, download, permission management, property editing, etc. = on a web=20 page.
 
-----Original = Message-----
From: Jim=20 Whitehead [mailto:ejw@cse.ucsc.edu]=20
Sent: Friday, May 17, 2002 1:56 PM
To:=20 WebDAV
Subject: FW: Can WebDav be used with = Servlet/JSP=20 based Web Application

Accidentally caught by the spam=20 filter.
 
- Jim
-----Original Message-----
From: saad = tawwab [mailto:saad.tawwab@kapscomp= uting.com]
Sent:=20 Thursday, May 16, 2002 11:37 PM
To: w3c-dist-auth@w3.org
Subje= ct:=20 [Moderator Action] Can WebDav be used with Servlet/JSP based = Web=20 Application

Hello!!
Please first let me explain my problem. I am Java = Developer=20 working on a Java based Web Application. I want to provide my = user=20 with the ability to Check In, Check Out, Add and View files = i.e. I=20 want to build a version control system that is integrated with = my web=20 site. The usecase would be that the user would log into my Web = Site=20 and then be able to access a page where he will get a list of = files=20 and then he can Check-In, Check-Out, Add and View files.=20


I have heard that WebDav = provides a sort of=20 version control mechanism. Can WebDav be integrated with a = Servlet/JSP=20 based application and allow the user to perform the task that = I have=20 listed above. Please do reply.


Regards,
Saad Tawwab Khan Rao
Kaps=20 Computing=20 = Inc.


------_=_NextPart_001_01C2008E.58136FA0-- ------=_NextPartTM-000-ddc780f1-45a5-44fc-a20c-54c83f540e42-- From w3c-dist-auth-request@w3.org Fri May 24 16:07: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 QAA12735 for ; Fri, 24 May 2002 16:07:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA20771; Fri, 24 May 2002 16:06:25 -0400 (EDT) Resent-Date: Fri, 24 May 2002 16:06:25 -0400 (EDT) Resent-Message-Id: <200205242006.QAA20771@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA20747 for ; Fri, 24 May 2002 16:06:17 -0400 (EDT) Received: from stthomas.edu (stthomas.edu [140.209.1.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA26562 for ; Fri, 24 May 2002 16:06:17 -0400 Received: from CONVERSION-DAEMON.stthomas.edu by stthomas.edu (PMDF V6.1 #39392) id <01KI3Z8J8J34A2N88K@stthomas.edu> for w3c-dist-auth@w3.org; Fri, 24 May 2002 15:06:16 -0600 (CST) Received: from ust-gateway4.stthomas.edu ([140.209.3.48]) by stthomas.edu (PMDF V6.1 #39392) with ESMTP id <01KI3Z8J4X48A2PPOC@stthomas.edu> for w3c-dist-auth@w3.org; Fri, 24 May 2002 15:06:16 -0600 (CST) Received: by exchange.stthomas.edu with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 15:06:16 -0500 Content-return: allowed Date: Fri, 24 May 2002 15:06:15 -0500 From: "Kinsella, John R." To: "'w3c-dist-auth@w3.org'" Message-id: <65F751F210A8D511A23F00A0C9D80492D1D68E@ust-staff1.stthomas.edu> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Subject: connect to a WebDav Share via the Web Browser Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6243 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: My deepest apologies if this question doesn't belong on this list. I'm having trouble finding any resources that can help us. I've got a question regarding implementing WebDav. We'd like to turn WbDav on on our file servers that will give users access to centralized storage from a net connected computer. Currently they gain access off-campus using a custom FTP-in-a-browser-window solution that we developed. We're hoping that WebDav can replace this, but I'm having some doubts we can provide the same functionality. So here's the question, Is there a way or a product that will mount (on a mac) and map (on a PC) a WebDav share by clicking on a link in a webpage? I know we could just provide directions for our users to do this themselves manually, but that suggestion wasn't received very well :-) So I'm trying to double check and make sure that this isn't possible. There must be some workaround to do this, since Apple does it for Mac clients with the iDisk. But I haven't figured out how they do that. I'm hoping some smart folks here may have an idea or suggestion for us. Thanks either way! John Kinsella ------------- "The surest way to corrupt a youth is to teach him to hold in higher regard those who think alike rather than those who think differently." --Nietzsche From w3c-dist-auth-request@w3.org Sat May 25 16:34: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 QAA00009 for ; Sat, 25 May 2002 16:34:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14669; Sat, 25 May 2002 16:33:29 -0400 (EDT) Resent-Date: Sat, 25 May 2002 16:33:29 -0400 (EDT) Resent-Message-Id: <200205252033.QAA14669@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA14598 for ; Sat, 25 May 2002 16:33:23 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA08060 for ; Sat, 25 May 2002 16:33:22 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4PKWpg5126178; Sat, 25 May 2002 16:32:51 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4PKWn6121850; Sat, 25 May 2002 16:32:49 -0400 To: "Lisa Dusseault" Cc: "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sat, 25 May 2002 16:21:31 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/25/2002 04:32:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Shared locks, interoperable? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6244 X-Loop: w3c-dist-auth@w3.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 did we conclude that we have shown interoperability for shared locks? Please check out the following thread and tell me what you think... http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0281.html ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat May 25 16:54: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 QAA00287 for ; Sat, 25 May 2002 16:54:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15908; Sat, 25 May 2002 16:53:48 -0400 (EDT) Resent-Date: Sat, 25 May 2002 16:53:48 -0400 (EDT) Resent-Message-Id: <200205252053.QAA15908@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA15888 for ; Sat, 25 May 2002 16:53:43 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA11038 for ; Sat, 25 May 2002 16:53:43 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4PKr7g5053790; Sat, 25 May 2002 16:53:07 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4PKr5614564; Sat, 25 May 2002 16:53:05 -0400 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: Sat, 25 May 2002 16:50:59 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/25/2002 04:53:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6245 X-Loop: w3c-dist-auth@w3.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 the following posting, http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0254.html Julian requests that we denote in rfc2518 that spaces are significant in property values. Is this agreeable to everyone? Would someone like to offer some precise wording? If so, please clarify if specific properties can specify otherwise. Thanks :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat May 25 17:56: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 RAA01356 for ; Sat, 25 May 2002 17:56:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA19151; Sat, 25 May 2002 17:55:02 -0400 (EDT) Resent-Date: Sat, 25 May 2002 17:55:02 -0400 (EDT) Resent-Message-Id: <200205252155.RAA19151@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA19128 for ; Sat, 25 May 2002 17:54:57 -0400 (EDT) Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA16127 for ; Sat, 25 May 2002 17:54:56 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id PAA00916 for ; Sat, 25 May 2002 15:15:49 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Sat, 25 May 2002 14:53:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: WebDAV and Windows 2000 problems... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6246 X-Loop: w3c-dist-auth@w3.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. - Jim -----Original Message----- From: Brian Holman [mailto:bholman@mail.gcsu.edu] Sent: Friday, May 24, 2002 12:31 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV and Windows 2000 problems... We've got a problem with the Network connection in Windows 2000 (Professional) that was installed here recently. It's unable to fully connect with our WebDAV-enabled webservers. On our new web servers we have four WebDAV realms that have been setup for Network access. We are able to access all realms from a MacOS X system w/ no problem from both the built-in WebDAV client and via third-party software (Goliath 1.2). We are also able to access all realms from Windows 2000 via third-party software WebDrive 5.0). The problem is that only two of the four realms can be accessed via the Network Places function built into the Windows 2000 OS. The realms that are inaccessible to Network Places are: * http://wwwxdav.gcsu.edu:8080/bus_fin/human_srvcs/human_res/ (user/password: lallen/red) * http://wwwxdav.gcsu.edu:8080/acad_affairs/acad_srvcs/ (user/password: mwilliam/blue) The exact error message received is: "The folder you've chosen does not appear to be valid. Please choose another." Yes, I have checked the folder names and the correct URL path. These URLs are accurate. Because we can access these via other platforms and windows-based third-party software, I'm lead to believe that the source of the problem is either in the OS or how it was setup on our particular system. Is there some aspect of the user setup in Win 2000 Professional that would prevent our access attempts in this exact way? If not, your input into this problem would be appreciated. The WebDAV folders that do work under Windows 2000 (and everything else) are: * http://wwwxdav.gcsu.edu:8080/student_affairs/athletics (username/password: bmuller/yellow) * http://wwwxdav.gcsu.edu:8080/ (user/password: mmcginni/green) Brian Holman Electronic Instructional Services Georgia College & State University Milledgeville, GA The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' but 'That's funny ...' -Isaac Asimov- From w3c-dist-auth-request@w3.org Sun May 26 06:19: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 GAA19505 for ; Sun, 26 May 2002 06:19:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA02462; Sun, 26 May 2002 06:18:19 -0400 (EDT) Resent-Date: Sun, 26 May 2002 06:18:19 -0400 (EDT) Resent-Message-Id: <200205261018.GAA02462@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA02435 for ; Sun, 26 May 2002 06:17:58 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA18220 for ; Sun, 26 May 2002 06:17:57 -0400 Received: (qmail 10602 invoked by uid 0); 26 May 2002 10:17:26 -0000 Received: from p3ee24771.dip.t-dialin.net (HELO lisa) (62.226.71.113) by mail.gmx.net (mp010-rz3) with SMTP; 26 May 2002 10:17:26 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Lisa Dusseault" Cc: "'WebDAV'" Date: Sun, 26 May 2002 12:17:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Shared locks, interoperable? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6247 X-Loop: w3c-dist-auth@w3.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: Saturday, May 25, 2002 10:22 PM > To: Lisa Dusseault > Cc: 'WebDAV' > Subject: RE: Shared locks, interoperable? > > > > So did we conclude that we have shown interoperability for shared locks? > > Please check out the following thread and tell me what you think... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0281.html We have implemented shared locks in our server and our client (adapter) software, and tested interoperability with: - Server: moddav - Server: IIS (with the reported issues) - Client: Adobe GoLive - Client: neon test suite From w3c-dist-auth-request@w3.org Sun May 26 09:05: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 JAA23081 for ; Sun, 26 May 2002 09:05:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA04102; Sun, 26 May 2002 06:33:34 -0400 (EDT) Resent-Date: Sun, 26 May 2002 06:33:34 -0400 (EDT) Resent-Message-Id: <200205261033.GAA04102@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA03814 for ; Sun, 26 May 2002 06:32:04 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA20064 for ; Sun, 26 May 2002 06:32:03 -0400 Received: (qmail 5477 invoked by uid 0); 26 May 2002 10:31:31 -0000 Received: from p3ee24771.dip.t-dialin.net (HELO lisa) (62.226.71.113) by mail.gmx.net (mp004-rz3) with SMTP; 26 May 2002 10:31:31 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: Date: Sun, 26 May 2002 12:31:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6248 X-Loop: w3c-dist-auth@w3.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: Saturday, May 25, 2002 10:51 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3c.org > Subject: Re: xml:space > > > > In the following posting, > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0254.html > > Julian requests that we denote in rfc2518 that spaces are significant in > property values. > > Is this agreeable to everyone? Would someone like to offer some precise > wording? If so, please > clarify if specific properties can specify otherwise. > > Thanks :-) OK, I'd propose to add to section 4.4 the simple statement: "White space in property values is significant. The XML attribute xml:space MUST not be used to change white space handling." Also, we should make sure that all examples follow this rule. (If somebody disagrees, I'd like to see examples of interoperability where white space indeed is handled as insignificant). From w3c-dist-auth-request@w3.org Mon May 27 11:43: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 LAA20814 for ; Mon, 27 May 2002 11:43:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA00556; Mon, 27 May 2002 11:41:46 -0400 (EDT) Resent-Date: Mon, 27 May 2002 11:41:46 -0400 (EDT) Resent-Message-Id: <200205271541.LAA00556@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA00509 for ; Mon, 27 May 2002 11:41:19 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA17146; Mon, 27 May 2002 11:41:18 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4RFedg5156610; Mon, 27 May 2002 11:40:39 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4RFebr70354; Mon, 27 May 2002 11:40:37 -0400 To: "Julian Reschke" Cc: "Jim Whitehead" , "Roy T. Fielding" , "Webdav WG \(E-mail\)" , w3c-dist-auth-request@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 27 May 2002 11:32:17 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/27/2002 11:40:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6249 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It sounds like we're converging on a proposal that looks much like Julian's at the bottom of the following posting... http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html I have one other proposal to make. It's based on the above proposal, but adjusts it a bit so that we have room to add other structured data to the source tag later if we want. It just creates a tag (sourcelabel) to envelop the optional? natural language description of the source. source file library file makefile Also please comment on how you'd express the situation where a single source URL has multiple roles. Thanks :-) J ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon May 27 19:46: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 TAA26151 for ; Mon, 27 May 2002 19:46:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA02893; Mon, 27 May 2002 19:45:56 -0400 (EDT) Resent-Date: Mon, 27 May 2002 19:45:56 -0400 (EDT) Resent-Message-Id: <200205272345.TAA02893@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA02873 for ; Mon, 27 May 2002 19:45:50 -0400 (EDT) Received: from hq-exgw2.filenet.com (Filenet-gw.filenet.com [198.3.8.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA11947 for ; Mon, 27 May 2002 19:45:48 -0400 Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 16:45:12 -0700 Message-ID: From: "Babich, Alan" To: w3c-dist-auth@w3c.org Date: Mon, 27 May 2002 16:45:12 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6250 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Obviously, white space has to be significant in the values of string properties, or it won't be interoperable. Alan -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, May 26, 2002 3:32 AM To: Jason Crawford; Julian Reschke Cc: w3c-dist-auth@w3c.org Subject: RE: xml:space > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Saturday, May 25, 2002 10:51 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3c.org > Subject: Re: xml:space > > > > In the following posting, > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0254.html > > Julian requests that we denote in rfc2518 that spaces are significant in > property values. > > Is this agreeable to everyone? Would someone like to offer some precise > wording? If so, please > clarify if specific properties can specify otherwise. > > Thanks :-) OK, I'd propose to add to section 4.4 the simple statement: "White space in property values is significant. The XML attribute xml:space MUST not be used to change white space handling." Also, we should make sure that all examples follow this rule. (If somebody disagrees, I'd like to see examples of interoperability where white space indeed is handled as insignificant). From w3c-dist-auth-request@w3.org Mon May 27 20:45: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 UAA26557 for ; Mon, 27 May 2002 20:45:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA06688; Mon, 27 May 2002 20:44:48 -0400 (EDT) Resent-Date: Mon, 27 May 2002 20:44:48 -0400 (EDT) Resent-Message-Id: <200205280044.UAA06688@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA06663 for ; Mon, 27 May 2002 20:44:39 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA17935 for ; Mon, 27 May 2002 20:44:39 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 27 May 2002 20:38:59 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 20:44:03 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B106EEC1DD@SUS-MA1IT01> From: "Clemm, Geoff" To: "Webdav WG (E-mail)" Date: Mon, 27 May 2002 20:43:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6251 X-Loop: w3c-dist-auth@w3.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 the addition of the DAV:sourcelabel element. But I object to the use of the xlink:href attribute, instead of the standard WebDAV DAV:href element. I believe it is significantly more important to maintain consistency within the WebDAV standard than it is to be consistent with some non-WebDAV standard such as xlink. In particular, this breaks functionality such as is provided by the DAV:expand-property report defined in RFC-3253, which is based on the existence of DAV:href nodes in property values. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Monday, May 27, 2002 11:32 AM To: Julian Reschke Cc: Jim Whitehead; Roy T. Fielding; Webdav WG (E-mail); w3c-dist-auth-request@w3.org Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED It sounds like we're converging on a proposal that looks much like Julian's at the bottom of the following posting... http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html I have one other proposal to make. It's based on the above proposal, but adjusts it a bit so that we have room to add other structured data to the source tag later if we want. It just creates a tag (sourcelabel) to envelop the optional? natural language description of the source. source file library file makefile Also please comment on how you'd express the situation where a single source URL has multiple roles. Thanks :-) J ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue May 28 03: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 DAA09887 for ; Tue, 28 May 2002 03:05:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA06192; Tue, 28 May 2002 03:04:00 -0400 (EDT) Resent-Date: Tue, 28 May 2002 03:04:00 -0400 (EDT) Resent-Message-Id: <200205280704.DAA06192@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA06161 for ; Tue, 28 May 2002 03:03:52 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA27388 for ; Tue, 28 May 2002 03:03:52 -0400 Received: (qmail 8696 invoked by uid 0); 28 May 2002 07:03:21 -0000 Received: from pd950c389.dip.t-dialin.net (HELO lisa) (217.80.195.137) by mail.gmx.net (mp015-rz3) with SMTP; 28 May 2002 07:03:21 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Jim Whitehead" , "Roy T. Fielding" , "Webdav WG \(E-mail\)" , Date: Tue, 28 May 2002 09:03:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6252 X-Loop: w3c-dist-auth@w3.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: Monday, May 27, 2002 5:32 PM > To: Julian Reschke > Cc: Jim Whitehead; Roy T. Fielding; Webdav WG (E-mail); > w3c-dist-auth-request@w3.org > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > > It sounds like we're converging on a proposal that looks much > like Julian's > at the bottom of the following posting... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html > > > I have one other proposal to make. It's based on the above proposal, but > adjusts it a bit so that we have room to > add other structured data to the source tag later if we want. It just > creates a tag (sourcelabel) to envelop the optional? natural > language description of the source. > > > > > xlink:role="UriDescribingTheRole"> > source file > > xlink:role="UriDescribingTheRole"> > library file > > xlink:role="UriDescribingTheRole"> > makefile > > > Fine with me. 1) Idea: maybe D:sourcelabel could be named more generically, such as: D:displayname. > Also please comment on how you'd express the situation where a single > source URL has multiple roles. 2) That's something XLink (at least simple XLinks) do not handle. Do you have a specific use case where it wouldn't be appropiate to simply repeat the D:source element? Julian From w3c-dist-auth-request@w3.org Tue May 28 03:12: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 DAA09970 for ; Tue, 28 May 2002 03:12:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA06469; Tue, 28 May 2002 03:11:36 -0400 (EDT) Resent-Date: Tue, 28 May 2002 03:11:36 -0400 (EDT) Resent-Message-Id: <200205280711.DAA06469@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA06449 for ; Tue, 28 May 2002 03:11:31 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA27921 for ; Tue, 28 May 2002 03:11:30 -0400 Received: (qmail 3078 invoked by uid 0); 28 May 2002 07:11:00 -0000 Received: from pd950c389.dip.t-dialin.net (HELO lisa) (217.80.195.137) by mail.gmx.net (mp016-rz3) with SMTP; 28 May 2002 07:11:00 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "Webdav WG \(E-mail\)" Date: Tue, 28 May 2002 09:10:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B106EEC1DD@SUS-MA1IT01> Importance: Normal Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6253 X-Loop: w3c-dist-auth@w3.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, May 28, 2002 2:44 AM > To: Webdav WG (E-mail) > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > I agree with the addition of the DAV:sourcelabel element. > > But I object to the use of the xlink:href attribute, instead of the > standard WebDAV DAV:href element. I believe it is significantly more > important to maintain consistency within the WebDAV standard than it > is to be consistent with some non-WebDAV standard such as xlink. In > particular, this breaks functionality such as is provided by the > DAV:expand-property report defined in RFC-3253, which is based on the > existence of DAV:href nodes in property values. Geoff, I expected this one :-) Pros for DAV:href syntax: h1 - consistent with other WebDAV specs h2 - can take advantage of DAV:expand-property report Pros for XLink syntax: x1 - consistent with W3C recommendations x2 - can be processed using standard XLink aware code (for instance, in browsers / xml based user interfaces) x3 - provides a standard framework for the definition of rules as URIs Thoughts: h2: isn't really a problem. We just define a new REPORT (or extend the existing one) to work on xlink:href elements as well. Note that xlink:href elements may appear in other people's dead (and live) properties anyway, so it makes sense to have a standard way to resolve them anyway. If there's some interest in this, I'll make a proposal. x3: I think any solution using non-XLink based syntax must define a way how to express the role of the link. One way would be to reuse XLinks link role URIs *without* using their syntax (which I'd consider lame :-). From w3c-dist-auth-request@w3.org Tue May 28 08:21: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 IAA15149 for ; Tue, 28 May 2002 08:21:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA05900; Tue, 28 May 2002 08:20:00 -0400 (EDT) Resent-Date: Tue, 28 May 2002 08:20:00 -0400 (EDT) Resent-Message-Id: <200205281220.IAA05900@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA05873 for ; Tue, 28 May 2002 08:19:47 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA31165 for ; Tue, 28 May 2002 08:19:48 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Tue, 28 May 2002 08:14:11 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 08:19:16 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B106EEC20B@SUS-MA1IT01> From: "Clemm, Geoff" To: "Webdav WG (E-mail)" Date: Tue, 28 May 2002 08:19:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6254 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: x1: I consider it significantly more important that a WebDAV feature be consistent with the WebDAV standard than that it be consistent with some other non-WebDAV standard, W3C or other. x2: I consider it significantly more important that a WebDAV feature be processable with standard WebDAV aware parsers (which expect href elements) than that they be processable with a non-WebDAV parser (such as XLink). x3: I consider adding a DAV:role element to be a superior way of adding this functionality in a WebDAV spec, given the capability of later extending the DAV:role element with additional structured values, which is not available with a role attribute. h2: The DAV:expand-property report is just a concrete instance of the cost of being inconsistent ... if we adopt the xlink:href attribute for the DAV:source property, every WebDAV feature that wants to do something generic with DAV:href elements would have to be defined and coded to look for both DAV:href elements and xlink:href attributes. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, May 28, 2002 3:11 AM To: Clemm, Geoff; Webdav WG (E-mail) Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, May 28, 2002 2:44 AM > To: Webdav WG (E-mail) > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > I agree with the addition of the DAV:sourcelabel element. > > But I object to the use of the xlink:href attribute, instead of the > standard WebDAV DAV:href element. I believe it is significantly more > important to maintain consistency within the WebDAV standard than it > is to be consistent with some non-WebDAV standard such as xlink. In > particular, this breaks functionality such as is provided by the > DAV:expand-property report defined in RFC-3253, which is based on the > existence of DAV:href nodes in property values. Geoff, I expected this one :-) Pros for DAV:href syntax: h1 - consistent with other WebDAV specs h2 - can take advantage of DAV:expand-property report Pros for XLink syntax: x1 - consistent with W3C recommendations x2 - can be processed using standard XLink aware code (for instance, in browsers / xml based user interfaces) x3 - provides a standard framework for the definition of rules as URIs Thoughts: h2: isn't really a problem. We just define a new REPORT (or extend the existing one) to work on xlink:href elements as well. Note that xlink:href elements may appear in other people's dead (and live) properties anyway, so it makes sense to have a standard way to resolve them anyway. If there's some interest in this, I'll make a proposal. x3: I think any solution using non-XLink based syntax must define a way how to express the role of the link. One way would be to reuse XLinks link role URIs *without* using their syntax (which I'd consider lame :-). From w3c-dist-auth-request@w3.org Tue May 28 09:19: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 JAA17436 for ; Tue, 28 May 2002 09:19:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA13361; Tue, 28 May 2002 09:19:09 -0400 (EDT) Resent-Date: Tue, 28 May 2002 09:19:09 -0400 (EDT) Resent-Message-Id: <200205281319.JAA13361@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA13338 for ; Tue, 28 May 2002 09:18:53 -0400 (EDT) Received: from bbhm.na.pg.com (bbhm.na.pg.com [192.44.184.159]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA12002 for ; Tue, 28 May 2002 09:18:54 -0400 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 bbhm.na.pg.com (8.8.8/8.11.1/v2r8) with ESMTP id g4SDIno22008; Tue, 28 May 2002 09:18:49 -0400 (EDT) To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 28 May 2002 09:17:58 -0400 X-MIMETrack: Serialize by Router on BDC-NOTES041.NA.PG.COM/PGI(Release 5.0.3 (Intl)|21 March 2000) at 05/28/2002 09:18:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: connect to a WebDav Share via the Web Browser Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6255 X-Loop: w3c-dist-auth@w3.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 following code will open a web folder on a windows-based pc (assuming appropriate versions of IE). The trick is to pass the appropriate string for servername and documentpath. Jim
Internet Mail Message Received from host: w3c-dist-auth@w3.org Sent To: "'w3c-dist-auth@w3.org'" by: cc: (bcc: Jim Hanna-JI/PGI) w3c-dist-auth-request@w3.org Subject: connect to a WebDav Share via the Web Browser 05/24/2002 04:06 PM My deepest apologies if this question doesn't belong on this list. I'm having trouble finding any resources that can help us. I've got a question regarding implementing WebDav. We'd like to turn WbDav on on our file servers that will give users access to centralized storage from a net connected computer. Currently they gain access off-campus using a custom FTP-in-a-browser-window solution that we developed. We're hoping that WebDav can replace this, but I'm having some doubts we can provide the same functionality. So here's the question, Is there a way or a product that will mount (on a mac) and map (on a PC) a WebDav share by clicking on a link in a webpage? I know we could just provide directions for our users to do this themselves manually, but that suggestion wasn't received very well :-) So I'm trying to double check and make sure that this isn't possible. There must be some workaround to do this, since Apple does it for Mac clients with the iDisk. But I haven't figured out how they do that. I'm hoping some smart folks here may have an idea or suggestion for us. Thanks either way! John Kinsella ------------- "The surest way to corrupt a youth is to teach him to hold in higher regard those who think alike rather than those who think differently." --Nietzsche From w3c-dist-auth-request@w3.org Tue May 28 18:25: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 SAA03010 for ; Tue, 28 May 2002 18:25:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23802; Tue, 28 May 2002 18:20:45 -0400 (EDT) Resent-Date: Tue, 28 May 2002 18:20:45 -0400 (EDT) Resent-Message-Id: <200205282220.SAA23802@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA23768 for ; Tue, 28 May 2002 18:20:27 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA17544 for ; Tue, 28 May 2002 18:20:28 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4SMJug5164526; Tue, 28 May 2002 18:19:56 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4SMJsj63384; Tue, 28 May 2002 18:19:54 -0400 To: "Babich, Alan" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 28 May 2002 18:18:09 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/28/2002 06:19:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6256 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << Obviously, white space has to be significant in the values of string properties, or it won't be interoperable. >> Yup. And conversely w.s. is probably not signficant in values that consist only of tags. And we don't need to make it significant in known properties like getcontentlength where we can probably deal with leading and trailing spaces. Buf if a server/client isn't familiar with an incoming property, they need to treat non tagged values in a way that preserves spaces. This also applies to known properties where there are signficant reasons why the spacing should not be altered. Right? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue May 28 19:41: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 TAA04235 for ; Tue, 28 May 2002 19:41:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA00474; Tue, 28 May 2002 19:41:13 -0400 (EDT) Resent-Date: Tue, 28 May 2002 19:41:13 -0400 (EDT) Resent-Message-Id: <200205282341.TAA00474@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA00434 for ; Tue, 28 May 2002 19:41:05 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA28034 for ; Tue, 28 May 2002 19:41:04 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g4SNfbX29006 for ; Tue, 28 May 2002 16:41:37 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 28 May 2002 16:40:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6257 X-Loop: w3c-dist-auth@w3.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 > In the following posting, > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0254.html > > Julian requests that we denote in rfc2518 that spaces are significant in > property values. > > Is this agreeable to everyone? Would someone like to offer some precise > wording? If so, please > clarify if specific properties can specify otherwise. This is a good clarification to make. - Jim From w3c-dist-auth-request@w3.org Tue May 28 21:20: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 VAA05741 for ; Tue, 28 May 2002 21:20:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA10983; Tue, 28 May 2002 21:19:07 -0400 (EDT) Resent-Date: Tue, 28 May 2002 21:19:07 -0400 (EDT) Resent-Message-Id: <200205290119.VAA10983@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA10856 for ; Tue, 28 May 2002 21:18:42 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA07776 for ; Tue, 28 May 2002 21:18:42 -0400 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g4T1Ifs08234 for ; Tue, 28 May 2002 18:18:42 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 28 May 2002 18:18:41 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g4T1IfX14654 for ; Tue, 28 May 2002 18:18:41 -0700 (PDT) Date: Tue, 28 May 2002 18:18:41 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Jim Luther To: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <02D5A282-72A2-11D6-B08A-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.481) Subject: Lightweight PROPFIND requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6258 X-Loop: w3c-dist-auth@w3.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 are a few times when the Mac OS X WebDAV file system client needs to use the PROPFIND method with "Depth: 1" on a collection resource to determine if it contains any children resources. For example, POSIX requires that my rmdir code must not delete a directory (collection) unless it is empty. Since the WebDAV DELETE method doesn't work that way (it deletes all children), my code uses the PROPFIND method with "Depth: 1" to determine if the DELETE method can be called on the empty collection, or if ENOTEMPTY should be returned because the collection has children. I don't need any properties from that PROPFIND, just the list of children. I tried this: and it works with mod_dav. However (and this is my question), is this legal by the rule ? I looked through the XML docs to see how ANY was defined but couldn't tell it allowed an empty set. If that's illegal and I must I ask for at least one property, I'll just ask for the resourcetype property since it looks like the only property that MUST be defined for all DAV compliant resources (all of the other DAV properties are shoulds, or are MUSTs under certain conditions). Thanks, - Jim Luther From w3c-dist-auth-request@w3.org Wed May 29 03:08:30 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05002 for ; Wed, 29 May 2002 03:08:30 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA13959; Wed, 29 May 2002 03:08:25 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4T77pm05686; Wed, 29 May 2002 03:07:51 -0400 (EDT) Resent-Date: Wed, 29 May 2002 03:07:51 -0400 (EDT) Resent-Message-Id: <200205290707.g4T77pm05686@frink.w3.org> Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4T77ln05555 for ; Wed, 29 May 2002 03:07:47 -0400 (EDT) Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA26204 for ; Wed, 29 May 2002 03:07:12 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA10545 for ; Wed, 29 May 2002 02:42:12 -0400 Received: (qmail 2345 invoked by uid 0); 29 May 2002 06:41:41 -0000 Received: from p3ee24825.dip.t-dialin.net (HELO lisa) (62.226.72.37) by mail.gmx.net (mp009-rz3) with SMTP; 29 May 2002 06:41:41 -0000 From: "Julian Reschke" To: "Jim Luther" , Date: Wed, 29 May 2002 08:41:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <02D5A282-72A2-11D6-B08A-0003934B6A22@apple.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Lightweight PROPFIND requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6259 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther > Sent: Wednesday, May 29, 2002 3:19 AM > To: w3c-dist-auth@w3.org > Subject: Lightweight PROPFIND requests > > > There are a few times when the Mac OS X WebDAV file system client needs > to use the PROPFIND method with "Depth: 1" on a collection resource to > determine if it contains any children resources. For example, POSIX > requires that my rmdir code must not delete a directory (collection) > unless it is empty. Since the WebDAV DELETE method doesn't work that way > (it deletes all children), my code uses the PROPFIND method with "Depth: > 1" to determine if the DELETE method can be called on the empty > collection, or if ENOTEMPTY should be returned because the collection > has children. I don't need any properties from that PROPFIND, just the > list of children. > > I tried this: > > > > > > > > and it works with mod_dav. However (and this is my question), is this > legal by the rule ? I looked through the XML docs to > see how ANY was defined but couldn't tell it allowed an empty set. It's legal according to the DTD, and I don't think that RFC2518 explicitly forbids it. It certainly works with our server. > If that's illegal and I must I ask for at least one property, I'll just > ask for the resourcetype property since it looks like the only property > that MUST be defined for all DAV compliant resources (all of the other > DAV properties are shoulds, or are MUSTs under certain conditions). That's probably the cheapest workaround -- but I'd try to stay with the former solution. If this breaks somewhere, please report the issue. From w3c-dist-auth-request@w3.org Wed May 29 03:11:45 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05095 for ; Wed, 29 May 2002 03:11:45 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA15656; Wed, 29 May 2002 03:11:53 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4T7CQ610812; Wed, 29 May 2002 03:12:26 -0400 (EDT) Resent-Date: Wed, 29 May 2002 03:12:26 -0400 (EDT) Resent-Message-Id: <200205290712.g4T7CQ610812@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4T7CPn10792 for ; Wed, 29 May 2002 03:12:25 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA15645 for ; Wed, 29 May 2002 03:11:51 -0400 Received: (qmail 1430 invoked by uid 0); 29 May 2002 07:11:17 -0000 Received: from p3ee24825.dip.t-dialin.net (HELO lisa) (62.226.72.37) by mail.gmx.net (mp016-rz3) with SMTP; 29 May 2002 07:11:17 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Babich, Alan" Cc: Date: Wed, 29 May 2002 09:11:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6260 X-Loop: w3c-dist-auth@w3.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: Wednesday, May 29, 2002 12:18 AM > To: Babich, Alan > Cc: w3c-dist-auth@w3c.org > Subject: RE: xml:space > > > > << > Obviously, white space has to be significant in the values of string > properties, or it won't be interoperable. > >> > Yup. And conversely w.s. is probably not signficant in values > that consist > only of tags. How do you decide that it only consists of tags (element content), if it *does* include whitespace? > And we don't need to make it significant in known properties like > getcontentlength where we > can probably deal with leading and trailing spaces. Buf if a I think we should say that for these properties, - servers SHOULD not send ignorable whitespace, and - that servers SHOULD accept ignorable whitespace from clients (and then we'll have to list those standard DAV: properties where ws is ignorable). Alternatively, we could also say that ignorable WS never should be sent, which would make the spec much simpler. > server/client > isn't familiar with an incoming property, > they need to treat non tagged values in a way that preserves spaces. This *all*. > also applies to known properties where there are > signficant reasons why the spacing should not be altered. > > Right? Almost. I think the easist solution is to say that whitespace *always* is signifcant (== ignorable whitespace SHOULD NOT be sent), and then possibly allow some workarounds for old known DAV: properties if we need to avoid breaking existing code. From w3c-dist-auth-request@w3.org Wed May 29 03:18:51 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05362 for ; Wed, 29 May 2002 03:18:51 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA17611; Wed, 29 May 2002 03:18:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4T7JAO14329; Wed, 29 May 2002 03:19:10 -0400 (EDT) Resent-Date: Wed, 29 May 2002 03:19:10 -0400 (EDT) Resent-Message-Id: <200205290719.g4T7JAO14329@frink.w3.org> Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4T7J3n13993 for ; Wed, 29 May 2002 03:19:03 -0400 (EDT) Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA26875 for ; Wed, 29 May 2002 03:18:28 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id XAA22641 for ; Tue, 28 May 2002 23:13:11 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 23:12:07 -0400 (Eastern Daylight Time) Received: from moose ([198.144.203.248]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 28 May 2002 23:12:06 -0400 From: "Lisa Dusseault" To: "Webdav WG \(E-mail\)" , Date: Tue, 28 May 2002 20:13:18 -0700 Message-ID: <001d01c206be$c8b20ce0$7801a8c0@moose> 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 V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 29 May 2002 03:12:06.0769 (UTC) FILETIME=[9D04DE10:01C206BE] Subject: Online interoperability testing Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6261 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit We should get some online interoperability testing going again. I've heard a proposal that we should do this on a one-on-one basis but do it every month. Every month, servers and clients would partner up. During a specified day in the month, the client would test against its server partner. A week later, if any issues were found which developers were able to resolve, the pair would test again. The advantages of one-on-one testing are focus and availability. The client would focus on improving interoperability with one server, and the server technical people would be available. First, is there support for this plan? What days? E.g. first Wednesday of the month for first pass, second Wednesday for second pass. If not, should we hold another mass online interop in June like the one held last October? Second, can somebody take charge of organizing online interop? Organizing a monthly one-on-one would mean coming up with some way to pair up servers and clients (servers advertise and clients select?) and registering/publishing that pairing and exchanging contact info, and sending out reminder mail. This is not intended to take the place of another face-to-face interop, which Jim is already thinking about. It should lead nicely into the face-to-face interop, because at the face-to-face interop people can focus on connecting to software they haven't already tested with. Lisa From w3c-dist-auth-request@w3.org Wed May 29 07:42:46 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11578 for ; Wed, 29 May 2002 07:42:46 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA27060; Wed, 29 May 2002 07:42:39 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4TBhCG19469; Wed, 29 May 2002 07:43:12 -0400 (EDT) Resent-Date: Wed, 29 May 2002 07:43:12 -0400 (EDT) Resent-Message-Id: <200205291143.g4TBhCG19469@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4TBhAn19445 for ; Wed, 29 May 2002 07:43:10 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA27057 for ; Wed, 29 May 2002 07:42:36 -0400 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 29 May 2002 13:30:49 +0200 Date: Wed, 29 May 2002 13:30:48 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: w3c-dist-auth@w3.org To: Jim Luther From: Stefan Eissing In-Reply-To: <02D5A282-72A2-11D6-B08A-0003934B6A22@apple.com> Message-Id: <862701CA-72F7-11D6-AB6D-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: Lightweight PROPFIND requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6262 X-Loop: w3c-dist-auth@w3.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 of course opens the question why DELETE on a collection with Depth: 0 is forbidden. There seems to be a use case for this and it is easy for a server to implement. Jim, did you make any tests how servers respond to a Depth: 0 DELETE request? //Stefan Am Mittwoch den, 29. Mai 2002, um 03:18, schrieb Jim Luther: > There are a few times when the Mac OS X WebDAV file system client > needs to use the PROPFIND method with "Depth: 1" on a collection > resource to determine if it contains any children resources. For > example, POSIX requires that my rmdir code must not delete a > directory (collection) unless it is empty. Since the WebDAV DELETE > method doesn't work that way (it deletes all children), my code > uses the PROPFIND method with "Depth: 1" to determine if the > DELETE method can be called on the empty collection, or if > ENOTEMPTY should be returned because the collection has children. > I don't need any properties from that PROPFIND, just the list of > children. > > I tried this: > > > > > > > > and it works with mod_dav. However (and this is my question), is > this legal by the rule ? I looked through the > XML docs to see how ANY was defined but couldn't tell it allowed > an empty set. > > If that's illegal and I must I ask for at least one property, I'll > just ask for the resourcetype property since it looks like the > only property that MUST be defined for all DAV compliant resources > (all of the other DAV properties are shoulds, or are MUSTs under > certain conditions). > > Thanks, > > - Jim Luther > > From w3c-dist-auth-request@w3.org Wed May 29 08:20:48 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13355 for ; Wed, 29 May 2002 08:20:47 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA00991; Wed, 29 May 2002 08:20:52 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4TCLPb23772; Wed, 29 May 2002 08:21:25 -0400 (EDT) Resent-Date: Wed, 29 May 2002 08:21:25 -0400 (EDT) Resent-Message-Id: <200205291221.g4TCLPb23772@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4TCLOn23733 for ; Wed, 29 May 2002 08:21:24 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA00978 for ; Wed, 29 May 2002 08:20:50 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 29 May 2002 08:15:11 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 08:20:19 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10704C05F@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 29 May 2002 08:20:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Lightweight PROPFIND requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6263 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Good point Stefan. Unfortunately, this use case was not something the writers of 2518 thought of, and they explicitly disallowed the use of a non-Infinity Depth header for DELETE. We should add this to the list of features we'd like to add/change in RFC 2518. Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Sent: Wednesday, May 29, 2002 7:31 AM To: Jim Luther Cc: w3c-dist-auth@w3.org Subject: Re: Lightweight PROPFIND requests That of course opens the question why DELETE on a collection with Depth: 0 is forbidden. There seems to be a use case for this and it is easy for a server to implement. Jim, did you make any tests how servers respond to a Depth: 0 DELETE request? //Stefan Am Mittwoch den, 29. Mai 2002, um 03:18, schrieb Jim Luther: > There are a few times when the Mac OS X WebDAV file system client > needs to use the PROPFIND method with "Depth: 1" on a collection > resource to determine if it contains any children resources. For > example, POSIX requires that my rmdir code must not delete a > directory (collection) unless it is empty. Since the WebDAV DELETE > method doesn't work that way (it deletes all children), my code > uses the PROPFIND method with "Depth: 1" to determine if the > DELETE method can be called on the empty collection, or if > ENOTEMPTY should be returned because the collection has children. > I don't need any properties from that PROPFIND, just the list of > children. > > I tried this: > > > > > > > > and it works with mod_dav. However (and this is my question), is > this legal by the rule ? I looked through the > XML docs to see how ANY was defined but couldn't tell it allowed > an empty set. > > If that's illegal and I must I ask for at least one property, I'll > just ask for the resourcetype property since it looks like the > only property that MUST be defined for all DAV compliant resources > (all of the other DAV properties are shoulds, or are MUSTs under > certain conditions). > > Thanks, > > - Jim Luther > > From w3c-dist-auth-request@w3.org Wed May 29 10:14:01 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18590 for ; Wed, 29 May 2002 10:14:00 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA25217; Wed, 29 May 2002 10:14:01 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4TEEV009514; Wed, 29 May 2002 10:14:31 -0400 (EDT) Resent-Date: Wed, 29 May 2002 10:14:31 -0400 (EDT) Resent-Message-Id: <200205291414.g4TEEV009514@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4TEETn09490 for ; Wed, 29 May 2002 10:14:29 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA25157 for ; Wed, 29 May 2002 10:13:54 -0400 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g4TEDrs11659 for ; Wed, 29 May 2002 07:13:53 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 29 May 2002 07:13:53 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g4TEDri12680 for ; Wed, 29 May 2002 07:13:53 -0700 (PDT) Date: Wed, 29 May 2002 07:13:53 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Jim Luther To: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10704C05F@SUS-MA1IT01> Message-Id: <4E1E5704-730E-11D6-B08A-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.481) Subject: Re: Lightweight PROPFIND requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6264 X-Loop: w3c-dist-auth@w3.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 No, I didn't test DELETE with Depth: 0 because (as Geoff also pointed out) RFC 2518 says "A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity." - Jim On Wednesday, May 29, 2002, at 05:20 AM, Clemm, Geoff wrote: > > Good point Stefan. Unfortunately, this use case was not > something the writers of 2518 thought of, and they explicitly > disallowed the use of a non-Infinity Depth header for DELETE. > > We should add this to the list of features we'd like to add/change > in RFC 2518. > > Cheers, > Geoff > > -----Original Message----- > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > Sent: Wednesday, May 29, 2002 7:31 AM > To: Jim Luther > Cc: w3c-dist-auth@w3.org > Subject: Re: Lightweight PROPFIND requests > > That of course opens the question why DELETE on a collection > with Depth: 0 is forbidden. There seems to be a use case > for this and it is easy for a server to implement. > > Jim, did you make any tests how servers respond to a Depth: 0 > DELETE request? > > //Stefan > > Am Mittwoch den, 29. Mai 2002, um 03:18, schrieb Jim Luther: > >> There are a few times when the Mac OS X WebDAV file system client >> needs to use the PROPFIND method with "Depth: 1" on a collection >> resource to determine if it contains any children resources. For >> example, POSIX requires that my rmdir code must not delete a >> directory (collection) unless it is empty. Since the WebDAV DELETE >> method doesn't work that way (it deletes all children), my code >> uses the PROPFIND method with "Depth: 1" to determine if the >> DELETE method can be called on the empty collection, or if >> ENOTEMPTY should be returned because the collection has children. >> I don't need any properties from that PROPFIND, just the list of >> children. >> >> I tried this: >> >> >> >> >> >> >> >> and it works with mod_dav. However (and this is my question), is >> this legal by the rule ? I looked through the >> XML docs to see how ANY was defined but couldn't tell it allowed >> an empty set. >> >> If that's illegal and I must I ask for at least one property, I'll >> just ask for the resourcetype property since it looks like the >> only property that MUST be defined for all DAV compliant resources >> (all of the other DAV properties are shoulds, or are MUSTs under >> certain conditions). >> >> Thanks, >> >> - Jim Luther From w3c-dist-auth-request@w3.org Wed May 29 10:29:44 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19140 for ; Wed, 29 May 2002 10:29:44 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA30102; Wed, 29 May 2002 10:29:45 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4TEUJc11915; Wed, 29 May 2002 10:30:19 -0400 (EDT) Resent-Date: Wed, 29 May 2002 10:30:19 -0400 (EDT) Resent-Message-Id: <200205291430.g4TEUJc11915@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4TEUIn11895 for ; Wed, 29 May 2002 10:30:18 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA30095 for ; Wed, 29 May 2002 10:29:43 -0400 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g4TETgt23671 for ; Wed, 29 May 2002 07:29:42 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 29 May 2002 07:29:42 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g4TETfX08855 for ; Wed, 29 May 2002 07:29:41 -0700 (PDT) Date: Wed, 29 May 2002 07:29:41 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Jim Luther To: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <838226AC-7310-11D6-B08A-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.481) Subject: Re: Lightweight PROPFIND requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6265 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, May 28, 2002, at 11:41 PM, Julian Reschke wrote: >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther >> Sent: Wednesday, May 29, 2002 3:19 AM >> To: w3c-dist-auth@w3.org >> Subject: Lightweight PROPFIND requests >> >> >> There are a few times when the Mac OS X WebDAV file system client needs >> to use the PROPFIND method with "Depth: 1" on a collection resource to >> determine if it contains any children resources. For example, POSIX >> requires that my rmdir code must not delete a directory (collection) >> unless it is empty. Since the WebDAV DELETE method doesn't work that >> way >> (it deletes all children), my code uses the PROPFIND method with >> "Depth: >> 1" to determine if the DELETE method can be called on the empty >> collection, or if ENOTEMPTY should be returned because the collection >> has children. I don't need any properties from that PROPFIND, just the >> list of children. >> >> I tried this: >> >> >> >> >> >> >> >> and it works with mod_dav. However (and this is my question), is this >> legal by the rule ? I looked through the XML docs to >> see how ANY was defined but couldn't tell it allowed an empty set. > > It's legal according to the DTD, and I don't think that RFC2518 > explicitly > forbids it. It certainly works with our server. > >> If that's illegal and I must I ask for at least one property, I'll just >> ask for the resourcetype property since it looks like the only property >> that MUST be defined for all DAV compliant resources (all of the other >> DAV properties are shoulds, or are MUSTs under certain conditions). > > That's probably the cheapest workaround -- but I'd try to stay with the > former solution. If this breaks somewhere, please report the issue. Thanks for the quick feedback. As you may have guessed, I'm attempting to reduce the number of transactions and the amount of data transferred (and parsed) to the minimum possible. I'll continue to test our client for interoperability against all servers I can get access to and report any problems found. - Jim From w3c-dist-auth-request@w3.org Wed May 29 12:58:12 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24639 for ; Wed, 29 May 2002 12:58:12 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA10231; Wed, 29 May 2002 12:57:04 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4TGuuV13998; Wed, 29 May 2002 12:56:56 -0400 (EDT) Resent-Date: Wed, 29 May 2002 12:56:56 -0400 (EDT) Resent-Message-Id: <200205291656.g4TGuuV13998@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4TGutn13976 for ; Wed, 29 May 2002 12:56:55 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA10098 for ; Wed, 29 May 2002 12:56:21 -0400 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g4TGuKt16779 for ; Wed, 29 May 2002 09:56:21 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 29 May 2002 09:56:20 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g4TGuJX08329 for ; Wed, 29 May 2002 09:56:19 -0700 (PDT) Date: Wed, 29 May 2002 09:56:19 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Jim Luther To: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.481) Subject: Re: Lightweight PROPFIND requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6266 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, May 28, 2002, at 11:41 PM, Julian Reschke wrote: >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther >> Sent: Wednesday, May 29, 2002 3:19 AM >> To: w3c-dist-auth@w3.org >> Subject: Lightweight PROPFIND requests >> >> >> There are a few times when the Mac OS X WebDAV file system client needs >> to use the PROPFIND method with "Depth: 1" on a collection resource to >> determine if it contains any children resources. For example, POSIX >> requires that my rmdir code must not delete a directory (collection) >> unless it is empty. Since the WebDAV DELETE method doesn't work that >> way >> (it deletes all children), my code uses the PROPFIND method with >> "Depth: >> 1" to determine if the DELETE method can be called on the empty >> collection, or if ENOTEMPTY should be returned because the collection >> has children. I don't need any properties from that PROPFIND, just the >> list of children. >> >> I tried this: >> >> >> >> >> >> >> >> and it works with mod_dav. However (and this is my question), is this >> legal by the rule ? I looked through the XML docs to >> see how ANY was defined but couldn't tell it allowed an empty set. > > It's legal according to the DTD, and I don't think that RFC2518 > explicitly > forbids it. It certainly works with our server. > >> If that's illegal and I must I ask for at least one property, I'll just >> ask for the resourcetype property since it looks like the only property >> that MUST be defined for all DAV compliant resources (all of the other >> DAV properties are shoulds, or are MUSTs under certain conditions). > > That's probably the cheapest workaround -- but I'd try to stay with the > former solution. If this breaks somewhere, please report the issue. I found a server which requires you to ask for at least one property... Microsoft-IIS/5.0 (Windows 2000 Professional). If you ask for no properties, it replies with "400 Bad Request". The other servers I tested (Apple iDisk, Xythos Sharemation, Apache 1.3/mod_dav 1.0.2, Greenbytes SAP Portals Enterprise Portal WebDAV Interface) all work correctly with no properties. So in the name of interoperability, I'll be asking for the resourcetype property like this: - Jim From w3c-dist-auth-request@w3.org Wed May 29 13:57:13 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26924 for ; Wed, 29 May 2002 13:57:13 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA24161; Wed, 29 May 2002 13:56:23 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4THuvx27506; Wed, 29 May 2002 13:56:57 -0400 (EDT) Resent-Date: Wed, 29 May 2002 13:56:57 -0400 (EDT) Resent-Message-Id: <200205291756.g4THuvx27506@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4THuun27471 for ; Wed, 29 May 2002 13:56:56 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA24148 for ; Wed, 29 May 2002 13:56:21 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 13:55:21 -0400 (Eastern Daylight Time) Received: from moose ([216.36.77.241]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 May 2002 13:55:21 -0400 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Jason Crawford'" , "'Babich, Alan'" Cc: Date: Wed, 29 May 2002 10:56:32 -0700 Message-ID: <003901c2073a$2b89e470$7801a8c0@moose> 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 29 May 2002 17:55:21.0267 (UTC) FILETIME=[00338830:01C2073A] Subject: RE: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6267 X-Loop: w3c-dist-auth@w3.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 > How do you decide that it only consists of tags (element > content), if it > *does* include whitespace? If an element is declared to contain PCDATA, like the depth element in 12.1.1 in RFC 2518, then whitespace is important. If an element is declared to contain other elements, e.g. activelock in 12.1 of RFC2518, then whitespace around the contained elements is removable according to the rules of XML parsing. If an element is not recognized, typically it is ignored. However, WebDAV properties may be retrieved which are not recognized elements, it is not known whether they are supposed to contain elements or text, and yet it is still desirable to display to the user. In this case, a couple heuristics may help: - if the value contains unescaped < after some white space, it probably contains XML elements, and the whitespace before the < and after the end of the value can be removed. However you must recurse and make the same evaluation before removing internal whitespace. - if the value begins with " All this whitespace is important. Your XML parser should be able to do this for you. E.g. a DOM parser will return a regular element as the child of foo1, automatically stripping whitespace, and a text thing as the child of foo3 with whitespace preserved. > Alternatively, we could also say that ignorable WS never > should be sent, > which would make the spec much simpler. I don't think so. That would make requests/responses hard to debug. In practice, it's very helpful to have line returns and tabs to make XML easier to read. It would also be adding rules on top of XML, to little purpose. Finally, it would be very difficult to put examples in specification text that conformed to this rule. > Almost. I think the easist solution is to say that whitespace > *always* is > signifcant (== ignorable whitespace SHOULD NOT be sent), and > then possibly > allow some workarounds for old known DAV: properties if we > need to avoid > breaking existing code. No, we should follow the XML rules for where whitespace is significant. According to those rules, whitespace is significant inside our date and content length (integer) properties, inside depth elements, etc. Lisa From w3c-dist-auth-request@w3.org Wed May 29 16:57:36 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03065 for ; Wed, 29 May 2002 16:57:36 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA06852; Wed, 29 May 2002 16:55:49 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4TKuOX15395; Wed, 29 May 2002 16:56:24 -0400 (EDT) Resent-Date: Wed, 29 May 2002 16:56:24 -0400 (EDT) Resent-Message-Id: <200205292056.g4TKuOX15395@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4TKuMn15371 for ; Wed, 29 May 2002 16:56:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA06822 for ; Wed, 29 May 2002 16:55:46 -0400 Received: (qmail 16403 invoked by uid 0); 29 May 2002 20:55:15 -0000 Received: from p3ee2472e.dip.t-dialin.net (HELO lisa) (62.226.71.46) by mail.gmx.net (mp013-rz3) with SMTP; 29 May 2002 20:55:15 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Jason Crawford'" , "'Babich, Alan'" Cc: Date: Wed, 29 May 2002 22:55:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <003901c2073a$2b89e470$7801a8c0@moose> Subject: RE: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6268 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, I don't agree at all. First of all, whitespace is only available if a DTD tells you that this is the case. If you don't know an element, there's no reliable way to tell whether it's ignorable or not. Whether CDATA is present or not isn't relevant at all. It's just a markup construct that allows the (human) author of an XML file not to escape the special characters "<", ">", "&" and the quote characters. In particular: > > outside isn't]]> > > All this whitespace is important. In each case I can construct a case where the opposite is true. Finally, > No, we should follow the XML rules for where whitespace is significant. > According to those rules, whitespace is significant inside our date and > content length (integer) properties, inside depth elements, etc. Yes we should to that. And in XML, you can't ignore whitespace unless you have a validated file and a DTD which tells you where whitespace is ignorable. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, May 29, 2002 7:57 PM > To: 'Julian Reschke'; 'Jason Crawford'; 'Babich, Alan' > Cc: w3c-dist-auth@w3c.org > Subject: RE: xml:space > > > > > How do you decide that it only consists of tags (element > > content), if it > > *does* include whitespace? > > If an element is declared to contain PCDATA, like the depth element in > 12.1.1 in RFC 2518, then whitespace is important. If an element > is declared > to contain other elements, e.g. activelock in 12.1 of RFC2518, then > whitespace around the contained elements is removable according > to the rules > of XML parsing. > > If an element is not recognized, typically it is ignored. However, WebDAV > properties may be retrieved which are not recognized elements, it is not > known whether they are supposed to contain elements or text, and yet it is > still desirable to display to the user. In this case, a couple heuristics > may help: > - if the value contains unescaped < after some white space, it probably > contains XML elements, and the whitespace before the < and after > the end of > the value can be removed. However you must recurse and make the same > evaluation before removing internal whitespace. > - if the value begins with " removed. > - Otherwise white space is crucial. > > E.g. > > outside isn't]]> > > All this whitespace is important. > > Your XML parser should be able to do this for you. E.g. a DOM parser will > return a regular element as the child of foo1, automatically stripping > whitespace, and a text thing as the child of foo3 with whitespace > preserved. > > > Alternatively, we could also say that ignorable WS never > > should be sent, > > which would make the spec much simpler. > > I don't think so. That would make requests/responses hard to debug. In > practice, it's very helpful to have line returns and tabs to make > XML easier > to read. It would also be adding rules on top of XML, to little purpose. > Finally, it would be very difficult to put examples in specification text > that conformed to this rule. > > > Almost. I think the easist solution is to say that whitespace > > *always* is > > signifcant (== ignorable whitespace SHOULD NOT be sent), and > > then possibly > > allow some workarounds for old known DAV: properties if we > > need to avoid > > breaking existing code. > > No, we should follow the XML rules for where whitespace is significant. > According to those rules, whitespace is significant inside our date and > content length (integer) properties, inside depth elements, etc. > > Lisa > From w3c-dist-auth-request@w3.org Wed May 29 18:53:08 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06385 for ; Wed, 29 May 2002 18:53:08 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA31984; Wed, 29 May 2002 18:52:21 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4TMq9U29909; Wed, 29 May 2002 18:52:09 -0400 (EDT) Resent-Date: Wed, 29 May 2002 18:52:09 -0400 (EDT) Resent-Message-Id: <200205292252.g4TMq9U29909@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4TMq8n29889 for ; Wed, 29 May 2002 18:52:08 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA31903 for ; Wed, 29 May 2002 18:51:32 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 8BDC949B70; Thu, 30 May 2002 08:51:01 +1000 (EST) Date: Thu, 30 May 2002 08:51:01 +1000 From: Alan Kent To: w3c-dist-auth@w3.org Message-ID: <20020530085101.A28975@io.mds.rmit.edu.au> References: <000001c1d05d$49de83e0$d8bd3fa6@moose> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <000001c1d05d$49de83e0$d8bd3fa6@moose>; from Lisa Dusseault on Wed, Mar 20, 2002 at 01:34:07PM -0800 Subject: Re: WebDAV and Service Location Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6269 X-Loop: w3c-dist-auth@w3.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 Wed, Mar 20, 2002 at 01:34:07PM -0800, Lisa Dusseault wrote: > I've been looking into the problem of locating WebDAV servers on an > intranet. Companies that have WebDAV servers on their net may not wish to > have users manually configure various clients with the names of all those > servers. In researching this problem, I've found only one standards-based > approach, and that's SLP. > > Who would be interested in defining a WebDAV extension so that Service > Location Protocol (SLP) clients can distinguish WebDAV servers from plain > Web servers? Any feedback on how this should work? Or are there other > options I'm ignorant of? Hi all, I have been off doing other things for a while, just trying to catch up with a big backlog of WebDAV mail. In ignorance of SLP, is UDDI an option? I am not a UDDI expert, but my understanding is that it allows businesses to publicise services (including the protocol). For example, GILS is trying to use it to publicize the location of GILS (which uses the Z39.50 protocol) servers. It seems to have a bit of momentum in the commercial world with its relationship to SOAP. Alan (Kent!) -- Alan Kent (mailto:ajk@mds.rmit.edu.au, http://www.mds.rmit.edu.au/~ajk/) Project: TeraText Technical Director, InQuirion Pty Ltd (www.inquirion.com) Postal: Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001. Where: RMIT MDS, Bld 91, Level 3, 110 Victoria St, Carlton 3053, VIC Australia. Phone: +61 3 9925 4114 Reception: +61 3 9925 4099 Fax: +61 3 9925 4098 From w3c-dist-auth-request@w3.org Wed May 29 19:00:39 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06668 for ; Wed, 29 May 2002 19:00:38 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA00381; Wed, 29 May 2002 18:59:52 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4TN0QX00458; Wed, 29 May 2002 19:00:26 -0400 (EDT) Resent-Date: Wed, 29 May 2002 19:00:26 -0400 (EDT) Resent-Message-Id: <200205292300.g4TN0QX00458@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4TN0Qn00438 for ; Wed, 29 May 2002 19:00:26 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA00374 for ; Wed, 29 May 2002 18:59:50 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 4285049B70; Thu, 30 May 2002 08:59:19 +1000 (EST) Date: Thu, 30 May 2002 08:59:19 +1000 From: Alan Kent To: WebDAV Message-ID: <20020530085919.B28975@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Subject: What is DASL for? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6270 X-Loop: w3c-dist-auth@w3.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 might sound like a very naive question, but I am trying to understand the use cases for DASL. That is, what sorts of problems are people trying to solve? Being an open framework to drop any sort of query you like into it to me does not improve interoperability in the long term. Then basicsearch - is it intended for searching the content of resources or their properties? Or both? As a search engine implementor, the combination of both is hard. Many properties are computed values, not stored. This makes them harder to index. So half the query evaluator has to ask the resource objects for computed information, then the other half can look up indexes. This gets hard to integrate nicely. Using a naive example: Google will crawl the content of a web site then index it. For WebDAV searching I can see the logic in trying to keep the index in sync with the online content. I am just trying to work out an architecture for integrating a search engine with a WebDAV file system. Our WebDAV library is a toolkit that developers can plug in their own underlying implementation (we have a text database product, so the WebDAV toolkit is to allow editing of that content). But with the mix of live and dead properties, I currently have no idea of the best model for implementing a query engine. Hence my question of what is the goal: * To enable searching of content? (Similar goals to say google) * To enable searching through a file system to find files that match certain properties (more like "Find Files" under windows") in a way that is faster than the client doing PROPFIND etc on each individual file. If the latter, I would implement the query engine without using indexes, and just do the file system walk at the server end and check the various conditions to find matching resources. Thanks Alan -- Alan Kent (mailto:ajk@mds.rmit.edu.au, http://www.mds.rmit.edu.au/~ajk/) Project: TeraText Technical Director, InQuirion Pty Ltd (www.inquirion.com) Postal: Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001. Where: RMIT MDS, Bld 91, Level 3, 110 Victoria St, Carlton 3053, VIC Australia. Phone: +61 3 9925 4114 Reception: +61 3 9925 4099 Fax: +61 3 9925 4098 From w3c-dist-auth-request@w3.org Thu May 30 10:12:58 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06088 for ; Thu, 30 May 2002 10:12:57 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA14167; Thu, 30 May 2002 10:11:10 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4UEBjw08118; Thu, 30 May 2002 10:11:45 -0400 (EDT) Resent-Date: Thu, 30 May 2002 10:11:45 -0400 (EDT) Resent-Message-Id: <200205301411.g4UEBjw08118@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4UEBhn08098 for ; Thu, 30 May 2002 10:11:44 -0400 (EDT) Received: from nimbus.esca.com (nimbus-2.esca.com [207.175.186.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA14142 for ; Thu, 30 May 2002 10:11:06 -0400 Received: from drizzle.esca.com (drizzle.esca.com [199.245.134.254]) by nimbus.esca.com (8.8.8/8.8.7) with ESMTP id HAA06174; Thu, 30 May 2002 07:10:36 -0700 (PDT) Received: from casita by drizzle.esca.com (8.8.8/1.1.10.5/25Jan98-0347PM) id HAA0000026458; Thu, 30 May 2002 07:10:33 -0700 (PDT) Message-ID: <001501c207ec$d5fcb560$0201a8c0@casita> From: "Carlos Martinez-Mascarua" To: Cc: Date: Thu, 30 May 2002 08:15:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C207B2.29039930" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: Multiple servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6271 X-Loop: w3c-dist-auth@w3.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_0012_01C207B2.29039930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know if there is any part of DAV that is related to the = issues arising when a server farm is in place; the idea is that each = server is completely independent, and there is a mechanism that will = keep the files consistent between them (using file-level = synchronization). The problem is: Can locking properties be made consistent among the = servers providing files through DAV? I hope this is the right forum for this question. Sincerely, Carlos Martinez-Mascarua ------=_NextPart_000_0012_01C207B2.29039930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I would like to know if there is any = part of DAV=20 that is related to the issues arising when a server farm is in place; = the idea=20 is that each server is completely independent, and there is a mechanism = that=20 will keep the files consistent between them (using file-level=20 synchronization).
 
The problem is: Can locking properties = be made=20 consistent among the servers providing files through DAV?
 
I hope this is the right forum for this = question.
 
Sincerely,
 
Carlos = Martinez-Mascarua
------=_NextPart_000_0012_01C207B2.29039930-- From w3c-dist-auth-request@w3.org Fri May 31 12:33:24 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21649 for ; Fri, 31 May 2002 12:33:24 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA20884; Fri, 31 May 2002 12:33:20 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g4VGXcD08272; Fri, 31 May 2002 12:33:38 -0400 (EDT) Resent-Date: Fri, 31 May 2002 12:33:38 -0400 (EDT) Resent-Message-Id: <200205311633.g4VGXcD08272@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g4VGXbh08248 for ; Fri, 31 May 2002 12:33:37 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA20557 for ; Fri, 31 May 2002 12:32:55 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g4VGXSX28477 for ; Fri, 31 May 2002 09:33:28 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 31 May 2002 09:31:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Reminder: WG Last Call on Access Control Specification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6272 X-Loop: w3c-dist-auth@w3.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 Just a brief reminder that we are rapidly approaching the end of a WG Last Call on the WebDAV Access Control Specification, draft-ietf-webdav-acl-08. The WG Last Call period ends Sunday, June 9, 2002. The original message starting the call can be found at: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0088.html Based on the feedback I have received so far, this is looking like it will definitely be the final WG last call on this document. There will be a few minor changes incorporated into the -09 document, which will then be forwarded along to the IESG for approval. So, if you want to provide feedback on this specification, you need to do so NOW. - Jim