From w3c-dist-auth-request@w3.org Mon Nov 1 10:14:25 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07553 for ; Mon, 1 Nov 1999 10:14:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA26182; Mon, 1 Nov 1999 10:02:03 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 10:02:03 -0500 (EST) Resent-Message-Id: <199911011502.KAA26182@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD244CF@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Mon, 1 Nov 1999 10:01:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3554 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list A question for server implementers: Are current server implementations supporting Digest Authentication? If not, what are they doing for authentication? Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Mon Nov 1 10:32:45 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11962 for ; Mon, 1 Nov 1999 10:32:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA26579; Mon, 1 Nov 1999 10:21:02 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 10:21:02 -0500 (EST) Resent-Message-Id: <199911011521.KAA26579@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525681C.005439C5.00@d54mta03.raleigh.ibm.com> Date: Mon, 1 Nov 1999 10:18:10 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3555 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list DAV4J just uses Basic Authentication for now. It didn't seem too important to authenticate users when there isn't any support for ACLs. We plan to do Digest though. "Slein, Judith A" on 11/01/99 10:01:38 AM To: "'WebDAV'" cc: Subject: Authentication in existing WebDAV servers A question for server implementers: Are current server implementations supporting Digest Authentication? If not, what are they doing for authentication? Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Mon Nov 1 11:21:40 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20947 for ; Mon, 1 Nov 1999 11:21:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA28032; Mon, 1 Nov 1999 11:10:04 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 11:10:04 -0500 (EST) Resent-Message-Id: <199911011610.LAA28032@www19.w3.org> Message-ID: <6253BCF3E25DD2118F0A00AA00AE6AAA03BE3E@tigger> From: David Sussman To: "'w3c-dist-auth@w3.org'" Date: Mon, 1 Nov 1999 16:09:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: Jigsaw release Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3556 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I've just seen the details for the new release of the W3C server - Jigsaw and spotted the details of the XML format and the administration protocol (http://www.w3.org/Jigsaw/Doc/Programmer/JigXML.html). Is it just me or is this not in DAV format? Does this seem a bit strange? I'm generally just a snooper in the mailing list, but this confused me. Dave From w3c-dist-auth-request@w3.org Mon Nov 1 13:35:14 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12417 for ; Mon, 1 Nov 1999 13:35:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA03837; Mon, 1 Nov 1999 13:23:05 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 13:23:05 -0500 (EST) Resent-Message-Id: <199911011823.NAA03837@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C9680B@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Mon, 1 Nov 1999 10:22:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF2496.1BC47A3E" Subject: RE: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3557 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF2496.1BC47A3E Content-Type: text/plain IIS 5/Windows 2000 supports basic, digest, NTLM, kerberos and few other algorithms I don't even remember. Yaron > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Monday, November 01, 1999 7:18 AM > To: w3c-dist-auth@w3.org > Subject: Re: Authentication in existing WebDAV servers > > > > > DAV4J just uses Basic Authentication for now. It didn't seem > too important > to authenticate users when there isn't any support for ACLs. > We plan to do > Digest though. > > > > > > "Slein, Judith A" on 11/01/99 10:01:38 AM > > To: "'WebDAV'" > cc: > > Subject: Authentication in existing WebDAV servers > > > > A question for server implementers: > > Are current server implementations supporting Digest > Authentication? If > not, what are they doing for authentication? > > Judith A. Slein > Xerox Corporation > jslein@crt.xerox.com > (716)422-5169 > 800 Phillips Road 105/50C > Webster, NY 14580 > > > > ------_=_NextPart_001_01BF2496.1BC47A3E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Authentication in existing WebDAV servers

IIS 5/Windows 2000 supports basic, digest, NTLM, = kerberos and few other algorithms I don't even remember.

        =         =         Yaron

> -----Original Message-----
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]=
> Sent: Monday, November 01, 1999 7:18 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: Authentication in existing WebDAV = servers
>
>
>
>
> DAV4J just uses Basic Authentication for now. = It didn't seem
> too important
> to authenticate users when there isn't any = support for ACLs.
> We plan to do
> Digest though.
>
>
>
>
>
> "Slein, Judith A" = <JSlein@crt.xerox.com> on 11/01/99 10:01:38 AM
>
> To:   "'WebDAV'" = <w3c-dist-auth@w3.org>
> cc:
>
> Subject:  Authentication in existing = WebDAV servers
>
>
>
> A question for server implementers:
>
> Are current server implementations supporting = Digest
> Authentication?  If
> not, what are they doing for = authentication?
>
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
>
>
>
>

------_=_NextPart_001_01BF2496.1BC47A3E-- From w3c-dist-auth-request@w3.org Mon Nov 1 13:51:15 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15920 for ; Mon, 1 Nov 1999 13:51:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA04271; Mon, 1 Nov 1999 13:39:26 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 13:39:26 -0500 (EST) Resent-Message-Id: <199911011839.NAA04271@www19.w3.org> Message-Id: <4.1.19991101102823.00a285f0@shell7.ba.best.com> X-Sender: glyph-max@pplus.shell14.ba.best.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 01 Nov 1999 10:37:51 -0800 To: "'WebDAV'" From: Max Rible In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD244CF@crte147.wc.eso.mc.x erox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3558 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 10:01 11/1/99 -0500, Slein, Judith A wrote: >A question for server implementers: > >Are current server implementations supporting Digest Authentication? If >not, what are they doing for authentication? Glyphica supports Digest authentication in our InfoPortal product, along with Basic and cookies. (And it took a good bit of hackery to arrange things so a web browser could be using cookie authentication and WebDAV could use Digest. Anyone know where I can find a spec for Windows NT challenge-response authentication? -- %% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %% %% "Before enlightenment: sharpen claws, catch mice. %% %% After enlightenment: sharpen claws, catch mice." - me %% From w3c-dist-auth-request@w3.org Mon Nov 1 16:44:16 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25706 for ; Mon, 1 Nov 1999 16:44:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA08645; Mon, 1 Nov 1999 16:32:39 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 16:32:39 -0500 (EST) Resent-Message-Id: <199911012132.QAA08645@www19.w3.org> Date: Mon, 1 Nov 1999 13:33:43 -0800 (PST) From: Greg Stein To: "Slein, Judith A" cc: "'WebDAV'" In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD244CF@crte147.wc.eso.mc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3559 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Mon, 1 Nov 1999, Slein, Judith A wrote: > A question for server implementers: > > Are current server implementations supporting Digest Authentication? If > not, what are they doing for authentication? Yes, Digest auth is part of Apache, so I get to leverage that [for mod_dav]. I also get whatever other kinds of auth people may have plugged in, and also things like SSL. Being based on HTTP definitely has its advantages... I don't have to worry about any of that stuff! Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 1 18:12:42 1999 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29412 for ; Mon, 1 Nov 1999 18:12:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA12718; Mon, 1 Nov 1999 18:00:26 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 18:00:26 -0500 (EST) Resent-Message-Id: <199911012300.SAA12718@www19.w3.org> Message-ID: From: "Chris Kaler (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Mon, 1 Nov 1999 15:00:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Subject: RE: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3561 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list But my client may use shared locks to coordinate updates. The client app doesn't recognize principals... -----Original Message----- From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] Sent: Tuesday, October 19, 1999 7:57 PM To: w3c-dist-auth@w3.org Subject: Re: One lock per resource per person? From: "Chris Kaler (Exchange)" Using SCC systems today, I can create multiple shared locks against the same resource. In general you can do this by "checking it out" multiple times, but the basic notion is that I may be engaged in parallel activities at my client even though I am the same principal. It's very important to distinguish "multiple checkouts" from "shared locks". Multiple checkouts are safe and do not suffer from any lost update problem. Shared write locks are not safe, and you are susceptible to getting your update's trashed by anyone else that shares that lock. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Nov 1 19:18:45 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28109 for ; Mon, 1 Nov 1999 19:18:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09064; Mon, 1 Nov 1999 16:51:10 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 16:51:10 -0500 (EST) Resent-Message-Id: <199911012151.QAA09064@www19.w3.org> Date: Mon, 1 Nov 1999 13:50:47 -0800 (PST) From: "Richard C." To: Greg Stein cc: "Slein, Judith A" , "'WebDAV'" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3560 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I am writing a Java problem to connect to WebDAV server, I am using HTTPClient library, so should I use basic authentication or digest authentication? Rich __ ` ` .^o ~\ ` ` ` ` `` ` Y /'~) } _____ ` `` ` ` l/ / / ,-~ ~~--.,_ ` ` `` ` ` ( ( / ~-._ ^. `` ` \ "--'--. "-._ \ ` ` ` ` "-.________ ~--.,__ ^. ` ` ` \"~r-.,___.-'-. ^. ` ` ` YI \\ ~-.\ ` ` ` ` || \\ `\ ` ` || // `Be on your guard; stand ` ` || // firm on the faith; be men ` ` ` () // of courage; be strong. ` ` || // ` ` ` || ( c 1 Corinthians 16:3 ` ___._ __ ___I|__`--__._ __ _ "~ ~ "~ "" ~~" ~ ~~ ICQ: 22864213 http://members.xoom.com/highpitch From w3c-dist-auth-request@w3.org Mon Nov 1 19:36:06 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06919 for ; Mon, 1 Nov 1999 19:36:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA01999; Mon, 1 Nov 1999 19:24:41 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 19:24:41 -0500 (EST) Resent-Message-Id: <199911020024.TAA01999@www19.w3.org> Date: Mon, 1 Nov 1999 19:24:30 -0500 Message-Id: <9911020024.AA28876@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (ckaler@Exchange.Microsoft.com) Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3562 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: "Chris Kaler (Exchange)" Using SCC systems today, I can create multiple shared locks against the same resource. In general you can do this by "checking it out" multiple times, but the basic notion is that I may be engaged in parallel activities at my client even though I am the same principal. It's very important to distinguish "multiple checkouts" from "shared locks". Multiple checkouts are safe and do not suffer from any lost update problem. Shared write locks are not safe, and you are susceptible to getting your update's trashed by anyone else that shares that lock. But my client may use shared locks to coordinate updates. The client app doesn't recognize principals... Whether or not the client recognizes principals doesn't seem to affect the issue in question. My point was that a checkout gives a client a new resource (a "working resource") that is distinct from any other parallel checkout, so you are guaranteed that your updates will not overwrite those of another client that has done a parallel checkout. In contrast, an update to a resource with a shared write lock can easily overwrite updates from another client that has a parallel shared lock. Perhaps I misunderstand what you have in mind when you say that your client may use shared locks to coordinate updates? Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Nov 1 22:10:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15602 for ; Mon, 1 Nov 1999 22:10:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA04145; Mon, 1 Nov 1999 21:52:36 -0500 (EST) Resent-Date: Mon, 1 Nov 1999 21:52:36 -0500 (EST) Resent-Message-Id: <199911020252.VAA04145@www19.w3.org> Date: Mon, 1 Nov 1999 18:53:49 -0800 (PST) From: Greg Stein To: "Richard C." cc: "'WebDAV'" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3563 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Mon, 1 Nov 1999, Richard C. wrote: > I am writing a Java problem to connect to WebDAV server, I am using > HTTPClient library, so should I use basic authentication or digest > authentication? The WebDAV spec states that Digest authentication must be used. However, all clients and servers, that I'm aware of, are flexible in this regard. For example, Apache and mod_dav will allow the use of Basic authentication. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Nov 2 02:02:26 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25463 for ; Tue, 2 Nov 1999 02:02:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA06447; Tue, 2 Nov 1999 01:50:42 -0500 (EST) Resent-Date: Tue, 2 Nov 1999 01:50:42 -0500 (EST) Resent-Message-Id: <199911020650.BAA06447@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C9681F@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Greg Stein'" , "Richard C." Cc: "'WebDAV'" Date: Mon, 1 Nov 1999 22:50:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF24FE.880F3C7A" Subject: RE: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3564 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF24FE.880F3C7A Content-Type: text/plain; charset="windows-1252" The spec says that digest MUST be supported. You can use anything you want, including nothing. > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Monday, November 01, 1999 6:54 PM > To: Richard C. > Cc: 'WebDAV' > Subject: Re: Authentication in existing WebDAV servers > > > On Mon, 1 Nov 1999, Richard C. wrote: > > I am writing a Java problem to connect to WebDAV server, I am using > > HTTPClient library, so should I use basic authentication or digest > > authentication? > > The WebDAV spec states that Digest authentication must be used. > > However, all clients and servers, that I'm aware of, are > flexible in this > regard. For example, Apache and mod_dav will allow the use of Basic > authentication. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > ------_=_NextPart_001_01BF24FE.880F3C7A Content-Type: text/html; charset="windows-1252" RE: Authentication in existing WebDAV servers

The spec says that digest MUST be supported. You can use anything you want, including nothing.

> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, November 01, 1999 6:54 PM
> To: Richard C.
> Cc: 'WebDAV'
> Subject: Re: Authentication in existing WebDAV servers
>
>
> On Mon, 1 Nov 1999, Richard C. wrote:
> > I am writing a Java problem to connect to WebDAV server, I am using
> > HTTPClient library, so should I use basic authentication or digest
> > authentication? 
>
> The WebDAV spec states that Digest authentication must be used.
>
> However, all clients and servers, that I'm aware of, are
> flexible in this
> regard. For example, Apache and mod_dav will allow the use of Basic
> authentication.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>

------_=_NextPart_001_01BF24FE.880F3C7A-- From w3c-dist-auth-request@w3.org Tue Nov 2 02:56:51 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27644 for ; Tue, 2 Nov 1999 02:56:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA06976; Tue, 2 Nov 1999 02:45:19 -0500 (EST) Resent-Date: Tue, 2 Nov 1999 02:45:19 -0500 (EST) Resent-Message-Id: <199911020745.CAA06976@www19.w3.org> Date: Mon, 1 Nov 1999 23:46:35 -0800 (PST) From: Greg Stein To: "Yaron Goland (Exchange)" cc: "Richard C." , "'WebDAV'" In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C9681F@STAY.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3565 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list All right... true... the spec is a bit different than I implied. Section 17.1 spells it out. Yes, it must be supported (as opposed to always required), and yes, you can use anything you want... *IF* you use a secure channel. Over plain old HTTP, the spec does state that Basic must not be used. Yes, I'm being picky here, but you were first :-) Cheers, -g On Mon, 1 Nov 1999, Yaron Goland (Exchange) wrote: > The spec says that digest MUST be supported. You can use anything you want, > including nothing. > > > -----Original Message----- > > From: Greg Stein [mailto:gstein@lyra.org] >... > > The WebDAV spec states that Digest authentication must be used. > > > > However, all clients and servers, that I'm aware of, are > > flexible in this > > regard. For example, Apache and mod_dav will allow the use of Basic > > authentication. -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Nov 2 10:17:47 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27393 for ; Tue, 2 Nov 1999 10:17:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA13189; Tue, 2 Nov 1999 10:09:15 -0500 (EST) Resent-Date: Tue, 2 Nov 1999 10:09:15 -0500 (EST) Resent-Message-Id: <199911021509.KAA13189@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525681D.00531DCE.00@d54mta03.raleigh.ibm.com> Date: Tue, 2 Nov 1999 10:07:57 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Jigsaw release Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3566 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Its not the DAV format, but DAV could store the whole frame as a Jigsaw property. Wouldn't work that well for DASL though. David Sussman on 11/01/99 11:09:08 AM To: "'w3c-dist-auth@w3.org'" cc: Subject: Jigsaw release I've just seen the details for the new release of the W3C server - Jigsaw and spotted the details of the XML format and the administration protocol (http://www.w3.org/Jigsaw/Doc/Programmer/JigXML.html). Is it just me or is this not in DAV format? Does this seem a bit strange? I'm generally just a snooper in the mailing list, but this confused me. Dave From w3c-dist-auth-request@w3.org Tue Nov 2 15:07:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17599 for ; Tue, 2 Nov 1999 15:07:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA19771; Tue, 2 Nov 1999 14:51:47 -0500 (EST) Resent-Date: Tue, 2 Nov 1999 14:51:47 -0500 (EST) Resent-Message-Id: <199911021951.OAA19771@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96824@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Greg Stein'" Cc: "Richard C." , "'WebDAV'" Date: Tue, 2 Nov 1999 11:51:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF256B.A5033A26" Subject: RE: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3567 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF256B.A5033A26 Content-Type: text/plain; charset="windows-1252" Yes the spec absolutely bans the use of basic over an unsecure connection. Frankly I hate language like this. If people want to do really stupid things that don't effect interoperability then that should be their business. However it was made clear to us that the absence of the previous language would cause problems in our standardization. So the language is in the spec. Personally I like requiring that everyone support Digest. This is important for interoperability. You have to have some minimum guaranteed level of security interoperability. However beyond that I think people should be allowed to be as stupid as they want. If they want to send Basic in the clear, if they want to avoid using authentication at all, that is their business. So long as people who do want to do the right thing can do the right thing then I'm happy. Yaron > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Monday, November 01, 1999 11:47 PM > To: Yaron Goland (Exchange) > Cc: Richard C.; 'WebDAV' > Subject: RE: Authentication in existing WebDAV servers > > > All right... true... the spec is a bit different than I > implied. Section > 17.1 spells it out. Yes, it must be supported (as opposed to always > required), and yes, you can use anything you want... *IF* you > use a secure > channel. > > Over plain old HTTP, the spec does state that Basic must not be used. > > Yes, I'm being picky here, but you were first :-) > > Cheers, > -g > > On Mon, 1 Nov 1999, Yaron Goland (Exchange) wrote: > > The spec says that digest MUST be supported. You can use > anything you want, > > including nothing. > > > > > -----Original Message----- > > > From: Greg Stein [mailto:gstein@lyra.org] > >... > > > The WebDAV spec states that Digest authentication must be used. > > > > > > However, all clients and servers, that I'm aware of, are > > > flexible in this > > > regard. For example, Apache and mod_dav will allow the > use of Basic > > > authentication. > > -- > Greg Stein, http://www.lyra.org/ > ------_=_NextPart_001_01BF256B.A5033A26 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: Authentication in existing WebDAV servers

Yes the spec absolutely bans the use of basic over an = unsecure connection. Frankly I hate language like this. If people want = to do really stupid things that don't effect interoperability then that = should be their business.

However it was made clear to us that the absence of = the previous language would cause problems in our = standardization.

So the language is in the spec.

Personally I like requiring that everyone support = Digest. This is important for interoperability. You have to have some = minimum guaranteed level of security interoperability. However beyond = that I think people should be allowed to be as stupid as they want. If = they want to send Basic in the clear, if they want to avoid using = authentication at all, that is their business.

So long as people who do want to do the right thing = can do the right thing then I'm happy.

        =         Yaron

> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, November 01, 1999 11:47 PM
> To: Yaron Goland (Exchange)
> Cc: Richard C.; 'WebDAV'
> Subject: RE: Authentication in existing WebDAV = servers
>
>
> All right... true... the spec is a bit = different than I
> implied. Section
> 17.1 spells it out. Yes, it must be supported = (as opposed to always
> required), and yes, you can use anything you = want... *IF* you
> use a secure
> channel.
>
> Over plain old HTTP, the spec does state that = Basic must not be used.
>
> Yes, I'm being picky here, but you were first = :-)
>
> Cheers,
> -g
>
> On Mon, 1 Nov 1999, Yaron Goland (Exchange) = wrote:
> > The spec says that digest MUST be = supported. You can use
> anything you want,
> > including nothing.
> >
> > > -----Original Message-----
> > > From: Greg Stein [mailto:gstein@lyra.org]
> >...
> > > The WebDAV spec states that Digest = authentication must be used.
> > >
> > > However, all clients and servers, = that I'm aware of, are
> > > flexible in this
> > > regard. For example, Apache and = mod_dav will allow the
> use of Basic
> > > authentication.
>
> --
> Greg Stein, http://www.lyra.org/
>

------_=_NextPart_001_01BF256B.A5033A26-- From w3c-dist-auth-request@w3.org Tue Nov 2 15:09:59 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18679 for ; Tue, 2 Nov 1999 15:09:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA19884; Tue, 2 Nov 1999 14:55:12 -0500 (EST) Resent-Date: Tue, 2 Nov 1999 14:55:12 -0500 (EST) Resent-Message-Id: <199911021955.OAA19884@www19.w3.org> From: Jim Whitehead To: WebDAV WG Cc: agenda@ietf.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Tue, 2 Nov 1999 11:54:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Agenda for WebDAV WG meeting in DC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3568 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Agenda WebDAV Working Group IETF-46, Washington, DC Monday, November 8, 1930-2200 * Advanced Collections specifications - Judy Slein - 1.5 hours "WebDAV Bindings" "WebDAV Redirect Reference Resources" "WebDAV Ordered Collections Protocol" - Solicitation of open issues from WG participants. - Discussion of known issues in drafts. Participants in the WebDAV WG meeting are expected to have read these drafts, and come prepared with comments based on their review. * Property extensions - Jim Amsden, John Stracke - 45 minutes "Proposed Extensions for WebDAV Properties" "WebDAV PROPFIND Extension to List Specified Namespaces" - Overview of each proposal (10 minutes each) - Discussion of each proposal (10 minutes each) - Develop send of the WG on whether these should be moved to proposed standard before WebDAV shuts down. * Discussion of access control - Jim Whitehead - 15 minutes "WebDAV Access Control Goals" "WebDAV ACL Protocol" - Brief overview of work to date - Solicitation of volunteers to continue working on these proposals (with eventual completion in a separate WG) If you would like to suggest an agenda item, please contact Jim Whitehead From w3c-dist-auth-request@w3.org Wed Nov 3 00:33:52 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04723 for ; Wed, 3 Nov 1999 00:33:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA02228; Wed, 3 Nov 1999 00:22:24 -0500 (EST) Resent-Date: Wed, 3 Nov 1999 00:22:24 -0500 (EST) Resent-Message-Id: <199911030522.AAA02228@www19.w3.org> From: "Larry Masinter" To: "'WebDAV'" Date: Tue, 2 Nov 1999 21:21:43 PST Message-ID: <000001bf25bb$5162ba40$8230fdcd@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C96824@STAY.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: RE: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3569 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > Personally I like requiring that everyone support Digest. > This is important for interoperability. You have to have some > minimum guaranteed level of security interoperability. > However beyond that I think people should be allowed to be > as stupid as they want. If they want to send Basic in the clear, > if they want to avoid using authentication at all, that is their > business. > > So long as people who do want to do the right thing can do the > right thing then I'm happy. The question is whether what's in the spec is actually strong enough to insure interoperability. In integrating network systems with WebDAV, seems that there is no guaranteed authentication mechanism that you can be insured of supplying credentials to that will work with most servers, even for servers that are technically compliant with the spec. Right now, it says "WebDAV applications MUST support the Digest authentication scheme [RFC2069]." But servers might "implement" digest, not allow digest authentication for access rights to any of the server's collections. Secondly, "Digest authentication" is itself may not be specific enough; do you want to specify a minimum algorithm & qop value? We've been having some difficulties finding interoperable authentication mechanisms for non-browser-based WebDAV use. There's no law that says "you must implement WebdAV", so people can always implement whatever they want, and do! The question is whether compliance guarantees interoperability. Right now, it doesn't seem like it does, and the spec might need to change. Larry -- http://www.parc.xerox.com/masinter From w3c-dist-auth-request@w3.org Wed Nov 3 18:18:56 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17420 for ; Wed, 3 Nov 1999 18:18:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA26668; Wed, 3 Nov 1999 18:07:05 -0500 (EST) Resent-Date: Wed, 3 Nov 1999 18:07:05 -0500 (EST) Resent-Message-Id: <199911032307.SAA26668@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525681E.007EF163.00@D51MTA03.pok.ibm.com> Date: Wed, 3 Nov 1999 18:08:54 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: 2518, proppatch example, responsedescription problem Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3570 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list It doesn't seem to be mentioned on the list, so I'll point it out... In 2518, the PROPPATCH example has a responsedescription tag outside the propstat. Although this is technically allowed by the DTD, this doesn't seem like the intended location. I believe it should go within that second propstat. Looking at the mailing list it sounds like it was there at one point though so someone probably moved it outside for a reason. Perhaps someone made the wrong correction to the following posting... http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0064.html ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Nov 3 21:19:17 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17227 for ; Wed, 3 Nov 1999 21:19:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA29742; Wed, 3 Nov 1999 21:06:02 -0500 (EST) Resent-Date: Wed, 3 Nov 1999 21:06:02 -0500 (EST) Resent-Message-Id: <199911040206.VAA29742@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525681F.000B82A8.00@d54mta03.raleigh.ibm.com> Date: Wed, 3 Nov 1999 21:05:43 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: 2518, proppatch example, responsedescription problem Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3571 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I don't have the spec in front of me, but isn't that the multistatus responsedescription for the method status as a whole? ccjason@us.ibm.com on 11/03/99 06:08:54 PM To: w3c-dist-auth@w3.org cc: Subject: 2518, proppatch example, responsedescription problem It doesn't seem to be mentioned on the list, so I'll point it out... In 2518, the PROPPATCH example has a responsedescription tag outside the propstat. Although this is technically allowed by the DTD, this doesn't seem like the intended location. I believe it should go within that second propstat. Looking at the mailing list it sounds like it was there at one point though so someone probably moved it outside for a reason. Perhaps someone made the wrong correction to the following posting... http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0064.html ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Nov 4 01:48:08 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16832 for ; Thu, 4 Nov 1999 01:48:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA03768; Thu, 4 Nov 1999 00:56:46 -0500 (EST) Resent-Date: Thu, 4 Nov 1999 00:56:46 -0500 (EST) Resent-Message-Id: <199911040556.AAA03768@www19.w3.org> From: Jim Whitehead To: Larry Masinter , "'WebDAV'" Date: Wed, 3 Nov 1999 21:55:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <000001bf25bb$5162ba40$8230fdcd@copper.parc.xerox.com> Subject: RE: Authentication in existing WebDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3572 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Larry Masinter writes: > The question is whether what's in the spec is actually strong > enough to insure interoperability. In integrating network systems > with WebDAV, seems that there is no guaranteed authentication > mechanism that you can be insured of supplying credentials to > that will work with most servers, even for servers that are > technically compliant with the spec. > > Right now, it says > "WebDAV applications MUST support the Digest authentication scheme > [RFC2069]." > > But servers might "implement" digest, not allow digest authentication > for access rights to any of the server's collections. It seems to me that since HTTP authentication is challenge-response, a client that implements Basic and Digest Auth should be able to interoperate against all HTTP/DAV servers. In HTTP/DAV, a client issues its request, receives back a challenge which specifies the kinds of authentication that can be used to satisfy the challenge, and in response the client reissues the request with the authentication credentials. If a server doesn't implement Digest, but does implement Basic, and sends a challenge asking for Basic, if the client implements Basic, it will be able to respond to the challenge. So, there is interoperability here, just not interoperability at the Digest Auth level. If the client must have Digest level auth., and only receives a Basic challenge, then it could abort the request and pop up a dialog explaining the problem (good luck making this meaningful to users, though :-). > Secondly, "Digest authentication" is itself may not be specific > enough; do you want to specify a minimum algorithm & qop value? Well, since the only algorithm specified in RFC 2617 is MD5, and I know of no other fielded Digest algorithms, specifying the Digest algorithm seems a bit of an overkill. But, it's undoubtedly prudent, and could certainly lead to less ambiguity in the future. As for qop value, this doesn't seem like something we should specify, since it appears to describe a per-message characteristic, and the DAV spec. cannot guarantee what the per-message security characteristics may be. > We've been having some difficulties finding interoperable > authentication mechanisms for non-browser-based WebDAV use. Hearing this I have two questions: a) what do you mean by "interoperable" in this case -- I'm genuinely unclear. b) could you give an example of the problems you're encountering? > Right now, > it doesn't seem like it does, and the spec might need to change. Certainly this is an area which hasn't been extensively interoperability tested, so it's possible there could be problems. On the other hand, I've heard no concrete problems yet. - Jim From w3c-dist-auth-request@w3.org Thu Nov 4 16:46:31 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00100 for ; Thu, 4 Nov 1999 16:46:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA22512; Thu, 4 Nov 1999 16:31:54 -0500 (EST) Resent-Date: Thu, 4 Nov 1999 16:31:54 -0500 (EST) Resent-Message-Id: <199911042131.QAA22512@www19.w3.org> Date: Thu, 4 Nov 1999 22:31:40 +0100 (MET) From: Yves Lafon X-Sender: ylafon@tarantula.inria.fr To: David Sussman cc: w3c-dist-auth@w3.org In-Reply-To: <8525681D.00531DCE.00@d54mta03.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Jigsaw release Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3573 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > I've just seen the details for the new release of the W3C server - > Jigsaw and spotted the details of the XML format and the administration > protocol (http://www.w3.org/Jigsaw/Doc/Programmer/JigXML.html). Is it > just me or is this not in DAV format? Does this seem a bit strange? > > I'm generally just a snooper in the mailing list, but this confused me. Jigsaw is not using DAV but a format that is more suited to a fast serialization/deserialization scheme. The fact that the admin protocol is using the same language is just legacy from the previous version and actually we are thinking about using it for the admin protocols. The 2.1 track is meant to change with the possibility to do incompatible changes like upgrading the admin protocol ;) /\ - Yves Lafon - World Wide Web Consortium - /\ / \ Architecture Domain - Jigsaw Activity Leader / \ \/\ / \ / \ http://www.w3.org/People/Lafon - ylafon@w3.org From w3c-dist-auth-request@w3.org Fri Nov 5 07:13:55 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17015 for ; Fri, 5 Nov 1999 07:13:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA05421; Fri, 5 Nov 1999 07:00:46 -0500 (EST) Resent-Date: Fri, 5 Nov 1999 07:00:46 -0500 (EST) Resent-Message-Id: <199911051200.HAA05421@www19.w3.org> Message-ID: <6253BCF3E25DD2118F0A00AA00AE6AAA03BE6D@tigger> From: David Sussman To: "'w3c-dist-auth@w3.org'" Date: Fri, 5 Nov 1999 10:24:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: Re: Jigsaw release Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3574 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Ahh, I see. I assumed there was some reason for it, and performance is a good enough one! My first thoughts were that it seemed odd that you were implementing something similar, and maybe duplicating effort. Thanks Dave Yves Lafon wrote in message news:<6553BCF3E25DD2118F0A00AA00AE6AAA178F10@tigger>... > > > I've just seen the details for the new release of the W3C server - > > Jigsaw and spotted the details of the XML format and the > administration > > protocol (http://www.w3.org/Jigsaw/Doc/Programmer/JigXML.html). Is it > > just me or is this not in DAV format? Does this seem a bit strange? > > > > I'm generally just a snooper in the mailing list, but this confused > me. > > Jigsaw is not using DAV but a format that is more suited to a fast > serialization/deserialization scheme. The fact that the admin protocol > is > using the same language is just legacy from the previous version and > actually we are thinking about using it for the admin protocols. The 2.1 > track is meant to change with the possibility to do incompatible changes > like upgrading the admin protocol ;) > > /\ - Yves Lafon - World Wide Web Consortium - > /\ / \ Architecture Domain - Jigsaw Activity Leader > / \ \/\ > / \ / \ http://www.w3.org/People/Lafon - ylafon@w3.org > From w3c-dist-auth-request@w3.org Sat Nov 6 22:44:16 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05282 for ; Sat, 6 Nov 1999 22:44:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA15663; Sat, 6 Nov 1999 22:28:23 -0500 (EST) Resent-Date: Sat, 6 Nov 1999 22:28:23 -0500 (EST) Resent-Message-Id: <199911070328.WAA15663@www19.w3.org> Date: Sat, 6 Nov 1999 19:30:01 -0800 (PST) From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: UNLOCK issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3575 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The UNLOCK method isn't documented very well with respect to its interaction with the Depth: header or how to return errors (generally, and in the case of a failed If: condition match). S9.2 states that a Depth: header is only supported if the method explicitly supports it. Am I to assume, then, that UNLOCK ignores the Depth: header? (or should it return an error if one is present?) Presuming the UNLOCK should always be treated as Depth: 0, then an If: failure is pretty easy. No multistatus is possible, so a 412 (Precondition Failed) would be the response from an UNLOCK? Note there is also a bit of weirdness in that UNLOCK is Depth: 0, but that a lock could have Depth: infinity. And that you can unlock the whole tree of locks by unlocking any of the locked resource. Also, how do you signify failure if the UNLOCK cannot be performed? For example, an unknown lock token or improper authorization? Let's say the lock token isn't found. Return a 400 (Bad Request)? Now, let's say the lock token *is* found but the authorization is wrong. Just keep returning 401 (Unauthorized) until they get it right? Well... this is somewhat rambling. To summarize: * I think S8.11 should be explicit that the Depth: header is not used. * There should be a summary of "typical" status codes like some of the other sections. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 8 05:04:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10121 for ; Mon, 8 Nov 1999 05:04:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA03898; Mon, 8 Nov 1999 04:48:21 -0500 (EST) Resent-Message-Id: <199911080948.EAA03898@www19.w3.org> X-Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by nebula.lyra.org (8.9.3/8.9.3) with ESMTP id IAA27395 for ; Sun, 7 Nov 1999 08:31:26 -0800 From: jamsden@us.ibm.com X-Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA153342 for ; Sun, 7 Nov 1999 11:28:42 -0500 X-Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA78362 for ; Sun, 7 Nov 1999 10:50:01 -0500 X-Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256822.0056F93C ; Sun, 7 Nov 1999 10:49:59 -0500 X-Lotus-FromDomain: IBMUS To: Greg Stein Message-ID: <85256822.0056F82C.00@d54mta03.raleigh.ibm.com> Date: Sun, 7 Nov 1999 10:50:27 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline ReSent-Date: Tue, 9 Nov 1999 02:48:03 -0800 (PST) ReSent-From: Greg Stein ReSent-To: w3c-dist-auth@w3.org ReSent-Subject: Re: UNLOCK issues Subject: Re: UNLOCK issues X-Mailing-List: archive/latest/3576 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Greg Stein on 11/06/99 10:30:01 PM To: w3c-dist-auth@w3.org cc: Subject: UNLOCK issues The UNLOCK method isn't documented very well with respect to its interaction with the Depth: header or how to return errors (generally, and in the case of a failed If: condition match). S9.2 states that a Depth: header is only supported if the method explicitly supports it. Am I to assume, then, that UNLOCK ignores the Depth: header? (or should it return an error if one is present?) All unused headers should be ignored. This wasn't specified for COPY which doesn't use the depth header, but if its specified, it must be infinity. Don't know why the inconsistency exists. Presuming the UNLOCK should always be treated as Depth: 0, then an If: failure is pretty easy. No multistatus is possible, so a 412 (Precondition Failed) would be the response from an UNLOCK? Actually, UNLOCK should always be treated as Depth: infinity. If you unlock a depth locked collection, all the locked resource with that lock token are unlocked. If you try to unlock a resource in a depth locked collection with the collection lock token, this should fail because of inherited locks. So a multistatus is always possible for UNLOCK because the method could fail to unlock many resources in a depth lock. Note there is also a bit of weirdness in that UNLOCK is Depth: 0, but that a lock could have Depth: infinity. And that you can unlock the whole tree of locks by unlocking any of the locked resource. I think depth should be ignored. The thing that determines what will be unlocked is the lock token. Also, how do you signify failure if the UNLOCK cannot be performed? For example, an unknown lock token or improper authorization? Let's say the lock token isn't found. Return a 400 (Bad Request)? Now, let's say the lock token *is* found but the authorization is wrong. Just keep returning 401 (Unauthorized) until they get it right? That's what I did. Well... this is somewhat rambling. To summarize: * I think S8.11 should be explicit that the Depth: header is not used. * There should be a summary of "typical" status codes like some of the other sections. Agreed. Why don't you write something up and we'll try to cover it this week. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Nov 10 20:12:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10282 for ; Wed, 10 Nov 1999 20:12:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA13271; Wed, 10 Nov 1999 19:58:01 -0500 (EST) Resent-Date: Wed, 10 Nov 1999 19:58:01 -0500 (EST) Resent-Message-Id: <199911110058.TAA13271@www19.w3.org> Date: Thu, 11 Nov 1999 16:58:06 -0800 (PST) From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: locknull resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3577 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Given the *current* spec :-), has anybody noticed that you can actually have a locknull resource that does not have any *direct* locks on it? For example: Establish a locknull as /a/b with a shared lock. Now, lock /a with a Depth: infinity lock, shared. Finally, unlock /a/b with the first locktoken. Just wanted to mention this to others, as it was pretty unexpected for me... Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Nov 11 14:43:45 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24307 for ; Thu, 11 Nov 1999 14:43:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05797; Thu, 11 Nov 1999 14:24:54 -0500 (EST) Resent-Date: Thu, 11 Nov 1999 14:24:54 -0500 (EST) Resent-Message-Id: <199911111924.OAA05797@www19.w3.org> Date: Thu, 11 Nov 1999 14:24:44 -0500 Message-Id: <9911111924.AA02486@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <85256822.0056F82C.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: UNLOCK issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3578 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: jamsden@us.ibm.com The UNLOCK method isn't documented very well with respect to its interaction with the Depth: header or how to return errors (generally, and in the case of a failed If: condition match). S9.2 states that a Depth: header is only supported if the method explicitly supports it. Am I to assume, then, that UNLOCK ignores the Depth: header? (or should it return an error if one is present?) All unused headers should be ignored. This wasn't specified for COPY which doesn't use the depth header, but if its specified, it must be infinity. Don't know why the inconsistency exists. I agree that unused headers should be ignored. The header will often be something that would make sense to a more advanced server. This does mean you lose the error check for clients that are issuing the wrong header but it's probably worth paying that price in order to simplify the life of client writers. Presuming the UNLOCK should always be treated as Depth: 0, then an If: failure is pretty easy. No multistatus is possible, so a 412 (Precondition Failed) would be the response from an UNLOCK? Actually, UNLOCK should always be treated as Depth: infinity. If you unlock a depth locked collection, all the locked resource with that lock token are unlocked. If you try to unlock a resource in a depth locked collection with the collection lock token, this should fail because of inherited locks. So a multistatus is always possible for UNLOCK because the method could fail to unlock many resources in a depth lock. I'd just say that the depth header is irrelevant to the UNLOCK command, rather than saying it should be treated as Depth:infinity. If you happen to be deleting a depth-infinity lock rooted at the request-URL, then the Depth:infinity header is redundant. If the request-URL is not the root of the lock, or if the lock is not depth-infinity, then the Depth:infinity header would either be ignored or generate an error. A header that must be either redundant, ignored, or wrong is not a useful header (:-). Note there is also a bit of weirdness in that UNLOCK is Depth: 0, but that a lock could have Depth: infinity. And that you can unlock the whole tree of locks by unlocking any of the locked resource. I think depth should be ignored. The thing that determines what will be unlocked is the lock token. I agree. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Nov 12 17:37:46 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08586 for ; Fri, 12 Nov 1999 17:37:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA15342; Fri, 12 Nov 1999 17:25:35 -0500 (EST) Resent-Date: Fri, 12 Nov 1999 17:25:35 -0500 (EST) Resent-Message-Id: <199911122225.RAA15342@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD244EA@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Fri, 12 Nov 1999 17:24:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: Notes on Advanced Collections from IETF 46 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3579 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Here are my notes on the advanced collections discussions from the IETF meetings. There were 2 unofficial breakout sessions devoted entirely to review of the advanced collections specifications, as well as an hour devoted to the redirect references specification in the official WebDAV working group meeting. (These are *not* the official minutes of the WebDAV working group meeting.) Advanced Collections First Breakout Present: Rohit Khare, Tyson Chihaya, Jason Crawford, Peter Carlson, Geoff Clemm, Judy Slein, Yaron Goland, James Hunt, Jim Whitehead, Kevin Wiggen, Jim Amsden 1 Bindings 1.1 Abstract Y: Don't mention the other specifications. Say more about what is in this specification. 1.2 Introduction Y: It's very difficult to understand the difference between bindings and URI mappings, and the motivation for distinguishing between them. It's difficult to understand how you would create a new URI mapping. Y: It's not clear why this is all presented as having something especially to do with collections. G: Adding a new binding to a collection allows you to add mappings to all children without an individual operation for each child Y: The spec makes assumptions about how things are implemented. This is bad. It should concern only what a client would perceive. G: We don't make assumptions about implementation. We do present a semantic model of bindings. This is needed to help you make sense of the protocol elements. Agreement that the model should be developed from the client point of view. G: A client needs to know what objects it needs lock in order to perform a given operation. For example, to MOVE /a/x.html, what object needs to be locked? It's the model that makes this clear. 1.2.1 Bindings and URI Mappings G: The state of a namespace is captured by collections; the states of the collections determine the namespace. Y: No. DAV allows a resource not to be a member of a collection. Only if an /a/ and /a/x.html are dav-compliant are they required to be collection / child. G: The bindings spec allows that mappings don't have to be induced by bindings. There can be mappings that are not induced by bindings. But bindings give you a way to control those mappings that are induced by bindings. Y: Wants a way to create mappings to anything, unrelated to collections. G: For versioning, it's not acceptable to have to lock the entire namespace in order to perform operations like MOVE. Also, you need a model where managing URI mappings is done through resources, because only resources can be checked out (a name is not a resource, and doesn't have state, and can't be checked out). You need a way to track the history of the namespace and get back to a previous state. There has to be some resource whose state captures the namespace state at a previous time. Y: The binding spec shouldn't force people to pay the price of versioning needs if they don't intend to support versioning. Y: It's not possible to implement the binding protocol on a file system. The applications that care most about bindings are document management systems and configuration management systems. Do file systems care? Yes, because they have links and need some way to model links. Bindings are similar to hard links in Unix. EJW: We could define a MAP method. We could also make it to automatically create the bindings we want if it's operating in a dav consistent namespace. EJW: The relation could be stored on the container or on the containee or neither. Y: The dav spec doesn't take a position on this. G: We need to know for versioning, in order to know what object to lock when we want to do a MOVE or DELETE. Consider the case where we want to delete one mapping to a single simple resource. Do we want to version the namespace or version the resource? Both. Versioning selection rules make it too complicated to try to track all the mappings to a resource over time. Direct refs are inherently unreliable. So we arrive at bindings, which are reliable and can be reasonably tracked because they are part of the state of a collection. To do a delete, you have to check out the collection. How do you version the root collection? You would have to create a versioned collection there. You would have to put "/" under version control. Versioning isn't compatible with inconsistent namespaces. You can't version a free-floating resource. If you deleted such a resource, you wouldn't be able to get back to a state of the namespace where the resource was present, because it's too difficult to track the state of the entire namespace. Y: Make it so that mappings induce mappings, as bindings do according to the current spec, if you are in a DAV consistent namespace, otherwise not. Geoff ok with that, though would make the protocol more complicated. We'd have to assess that. Moment of enlightenment about the difference between mappings and bindings: With bindings you are guaranteed that if /a1/ and /a2/ are bound to the same collection C, then if you DELETE /a1/x.html, then /a2/x.html will no longer be mapped to that resource. On the mapping model if you are in an inconsistent namespace this is not the case. If all you have are mappings, then the mapping of /a1/ is completely independent of the mapping of /a1/x.html. Even if /a1/ and /a2/ are mapped to the same collection C, there is no reason to expect that /a1/x.html and /a2/x.html are mapped to the same resource. If you PUT to /a1/x.html, you won't necessarily see the result at /a2/x.html. Y: There should be 2 separate specs, one for consistent namespaces, one for inconsistent namespaces. State explicitly that the binding spec is only for consistent namespaces. The other spec, for creating new mappings in inconsistent namespaces can be left TBD. G: Supporting non-versioned resources in versioned collections would require mapping semantics rather than binding semantics. Y: The explanation of why a straight mapping spec was not adequate needs to be written down in a separate document (rationale spec, for example), and make sure it beocmes an RFC. 1.3 Terminology Y: Definition of "resource": At the moment, the binding spec references the URI draft's definition. It should instead reference the HTTP spec's definition, which is more specific and is the one we (as an extension to HTTP) should reference. We'll look into this. 1.4 Section 6 (DELETE) Y: Don't make it look like the DELETE definition in HTTP was stupid. State clearly in the introduction that we are changing the definition of DELETE. Our definition is different from the one in HTTP and the one in 2518. Change the last sentence of Section 6 to say that servers that support bindings MUST NOT follow the definition in RFC 2518. 1.5 BIND Status Codes Y: Don't use new error codes - Only rely exclusively on the error code if a proxy server would have to look at it. But it's harder for a client to have to look at the entity response body as well as the code. EJW: We are far from exhausting status codes, and we don't need to address a general error code extension mechanism for HTTP. We would have to address the problem of different errors at source / destination, and some generic approach to depth operations. This is a Pandora's box. Y: There is not enough information in HTTP error codes for clients to do anything useful with it JA: Just use status codes, and let SOAP take care of this. Needs more discussion. 1.6 Loops Do we need the 507 Loop Forbidden status code (or equivalent)? Loops can be useful in some scenarios. They are needed for versioning. We'll say that servers MUST allow loops to be created. Any server that can support bindings to collections would support loops. The server would always allow creation of a loop, but it might have to fail some operations if it encounters a loop. 1.7 The All-Bindings Header The client doesn't know the state of the resource after the All-Bindings header has been applied. It's not the client's business whether or when garbage collection takes place. If the client can't see it, that's the end of it from client's point of view. The server doesn't know whether the intent was to get rid of all dav bindings or whether the client wanted to destroy the resource. G: Opposes All-Bindings. If the client wants to delete them all, it should be required to iterate through them all deleting one at a time. If we have All-Bindings, after a DELETE there could still be other mappings that were not dependent on any binding. HTTP and 2518 said DELETE would delete the resource, but we've changed the definition so that we don't have that any more. Some of us would like a way to get rid of the resource altogether, but it seems impossible to specify that. So the closest we could come to that is to say "Delete all the bindings". There are also security implications of All-Bindings. You should only be able to delete the bindings you are authorized to see. Agreed: Get rid of the All-Bindings header. 1.8 Atomicity of DELETE We say that DELETE is atomic, even when a collection is being deleted, because it is just the removal of a single binding. Y: An atomic DELETE can't be implemented on the Microsoft file systems. K: It turned out to be a lot of work for a transactioning system to implement it non-atomically. G: You could implement the atomicity in a layer above the file system. Y: This would be too complex and too costly in performance. Servers may make DELETE atomic if they like. Clients want delete and move to be atomic. G: We could say that DELETE SHOULD be atomic, as a statement of intent for servers, but admit that we couldn't do what clients want. We could include an Implementation Note: If the server can DELETE atomically, it should feel free to do so. 1.9 DELETE, access control, and locks Somewhere we need to say that acls and locks need to be checked. So even though DELETE is just removing a binding, when you are deleting a collection you have to check all the child nodes for access control and locks. Whether to say this in the spec, or just refer to access control and locking discussions elsewhere. Or maybe don't say anything here, but have an implementer's guide or other document that discusses the interactions between the WebDAV specifications. 1.10 Atomicity of MOVE Same as for DELETE. What should happen if you attempt a MOVE on a collection that contains bindings you are not authorized to know about? 1.11 Implementation Note on DELETE Y: Talking about copy + fixup + delete will just raise lots of unnecessary discussion. Agreed: Remove this section. It could be preserved somewhere else, either on the mailing list or in an implementer's guide. 1.12 Locking Y: Locks do not survive a MOVE. G: Can we say that a MOVE must fail if the resource is locked? Y: This is not really an issue about bindings. There needs to be a separate locking draft. Sections 8.2 and 9 should be removed. JA: It won't be possible to implement the binding spec if we don't understand the behavior of bindings with locks. [More discussion of locking models in general] JS: We addressed locks here because of our MOVE definition. Since we redefined MOVE to be rename, it was clear that you have the same resource before and after the move, so it should have the same state before and after. The lockdiscovery property is part of that state, and so the resource should still be locked after the MOVE. Agreed: Locking is a high priority issue, but shouldn't be addressed in this spec. Whatever is decided in general about locking, the implications for bindings should just fall out of that. 1.13 Section 10 Bindings and Other Methods Qualify what is said here. It applies only to successful operations. 1.14 DAV:guid Change the name of this property to something more informative, like DAV:resourceid. For the URI Scheme, copy the language from the UUID draft, not from RFC 2518. 1.15 DAV:bindings There is a potential security problem here. The client must only be able to see bindings it is authorized to know about. 1.16 Loop Detection Y: What if a resource is dynamic, and counts the number of requests against it? And the server applies a request to it multiple times before deciding that it's in a loop? Can we require servers to execute only once in a loop? No, this is too severe a constraint. 1.17 Loop Header This header is not needed. If you encountered a loop, you would be getting a multistatus response. 1.18 Capability Discovery Get rid of the "MUST". A resource is not required to advertise its capabilities. 1.19 IANA Considerations Add the new URI scheme to IANA considerations. 1.20 Acknowledgements Add James Hunt, Peter Carlson. 2 Redirect References Y: This specification has nothing to do with collections, so change the parts of the abstract and introduction that make it sound as if it does. WebDAV Working Group Meeting 2.1 MKRESOURCE K: If there's a resource at the location already and Overwrite: T, you have to delete the existing resource first. If the entire operation cannot be completed, you have to roll back. This is different (maybe) from the Overwrite behavior in RFC 2518. A file system might not be able to roll back. EJW: It was the intent of RFC 2518 that you would have to roll back if you couldn't create the new resource successfully. What should the response code be if you couldn't do the delete? 5xx? 4xx? 207? Y: It was the intent of RFC 2518 that the operation not be atomic. You could leave the file system in a state, e.g., where you had deleted the existing resource but not been able to create the new resource. K: MKRESOURCE should be consistent with MKCOL as to its body. K: The XML used in MKRESOURCE should be analogous to what you get in a response from a redirect reference. You provide DAV:resourcetype and DAV:reftarget in MKRESOURCE, but a 302 response has DAV:location and DAV:resourcetype. Maybe in both cases have the value of DAV:resourcetype be structured: . . . There are several things going on here. What you put in are the properties of the redirect reference resource to be created, so they are what you get back if you do PROPFIND with Passthrough: F. What you get back without the Passthrough header is a 302 response, and that's different. It tells you how to reach the target resource, and it's structured to be analogous to a normal HTTP 302 response. We wouldn't want to make location part of the resourcetype property, because when you change the location you are not changing the resource type. Location and reftarget are separate because we want reftarget to allow relative URIs, but location is defined in HTTP to be an absolute URI. 2.2 PUT and POST for Redirect References Y: PUT should succeed on a redirect reference (with Passthrough: F). It should be allowed for a redirect reference to have a body. Y: POST should also be allowed on a redirect reference with Passthrough: F. 2.3 Location Header Y: We need to allow multiple values in the location header. He has defined (in some internet draft) an AL header that is similar to location, but allows multiple values. The order of the values is significant. Use that instead of location. 2.4 509 (Dangling References Forbidden) EJW: Remove the 509 (Dangling References Forbidden) status code. Agreed. 2.5 Redirect References to Collections EJW: We need to think about whether redirect references to collections are reasonable to implement. We need to think about potential problems of redirect references to dynamic resources. 2.6 Passthrough Header JA: The behavior for Passthrough: T should be to pass the request on to the target resource. G: No, we want redirect references to be simple to implement. We don't want a server to have to have proxy capabilities to support redirect references. Besides, that would be to mix the characteristics of direct and redirect references. JS: We could change the name of the header. "Passthrough" came from the days when we planned to specify direct references. We could call the header "Apply-To-Redirect" and make its semantics specific to redirect references. Agreed. Second Breakout Present: Kevin Wiggen, Yaron Goland, Chris Kaler, Lisa Dusseault, Jim Whitehead, Geoff Clemm, Judy Slein 3 Ordered Collections 3.1 Locks and Collection Ordering Since the ordering is part of the state of the collection, it can't be changed while the collection is locked unless you are the lock owner. 3.2 Depth infinity PROPFIND and collection orderings K: Is there any requirement about what order you have to return things if you are doing a Depth: infinity PROPFIND and some of the collections in the hierarchy are ordered? Do you have to go depth first, or breadth first, or something else? Kevin implemented the first of each collection, then the second of each collection, etc., just for a lark. Is this compliant? Kevin's ordering is the most efficient for his implementation. It's certainly not what clients would want. We don't want to do anything that would require a server to spool all the results before sending them. No matter what we require, there will probably be some server implementation that will be forced to spool. Leave it up to the server, and if a client really cares, it should do Depth: 1 PROPFINDs. 3.3 Server-Maintained Orderings K: Server-maintained orderings are pointless. A client won't be able to pick a useful one unless client is designed for that server. Someone may standardize some orderings someday, and then it would be useful to support server-maintained orderings. We don't want to make it impossible to support server-maintained orderings if that ever happens, but for now we should not specify the support. Raise this again on the mailing list. 3.4 Including Ordering Semantics with All PROPFIND Responses K: The spec says that PROPFIND on an ordered collection SHOULD return ordering semantic. Make this MUST. If you cared, you would ask for that information. Make it either MUST or eliminate it. Clients often reorder unless they know the collection was ordered at the server. Y: Favors MUST. Windows Explorer would use the server's ordering if it knew the response was ordered. Otherwise it reorders in its own standard way. Explorer would not be willing to request DAV:orderingtype on every PROPFIND explicitly. We might want to provide a way to ask for a clump of special features - say "this is for display" -- that gets you a set of special features including the ordering semantics, what icon to use, etc. G: Don't return random stuff that you think should be interesting to a client without the client's asking for it. If it's to be useful, response must indicate that the collection is ordered. We may want a way to let a client turn off ordering for optimization. Discuss on mailing list. 3.5 Section 13.2 - 13.3 Body for OPTIONS Both the ordering spec and the versioning spec define ways to get additional information about capabilities using request / response bodies. This work needs to be coordinated so that both specs do it the same way. 3.6 Section 10.2 Position Header K: The spec wants before or after a Generic-Coded-url, but it would be better just to use the final path segment. Y: If you do that, you need language specifying how to resolve the segment to an absolute URI. Agreed. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Sat Nov 13 06:22:50 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02668 for ; Sat, 13 Nov 1999 06:22:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA03374; Sat, 13 Nov 1999 06:10:30 -0500 (EST) Resent-Date: Sat, 13 Nov 1999 06:10:30 -0500 (EST) Resent-Message-Id: <199911131110.GAA03374@www19.w3.org> X-Sender: dcarson@pop.toad.net Message-Id: In-Reply-To: <4.1.19991111204130.00ac1100@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 Nov 1999 06:05:12 -0500 To: Jim Davis , w3c-dist-auth@w3.org From: Dana Carson Cc: webdav@cyberteams.com Subject: Re: more interoperation: Cyberteams Webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3580 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 9:14 PM +0100 on 11/11/99, Jim Davis wrote: > Today I tested the Cyberteams webdav server. > 1) The server returns an invalid Content-Type for a PROPFIND. The >content type > is httpd/unix-directory but should be text/xml Fixed. Turns out if you ser the output header but not the r->content_type it overrides the header. > 2) The server ignores the Depth header (or at least it ignores Depth: 0) on > PROPFIND. > As a result, it returns a great deal more information that one desires Fixed. -- Dana Carson dcarson@cyberteams.com http://www.cyberteams.com/ dcarson@toad.net http://www.toad.net/~dcarson/ Lunar Resources Company http://www.tlrc.com/ Artemis Society International http://www.asi.org/ From w3c-dist-auth-request@w3.org Sun Nov 14 16:05:46 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24131 for ; Sun, 14 Nov 1999 16:05:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA09342; Sun, 14 Nov 1999 15:54:16 -0500 (EST) Resent-Date: Sun, 14 Nov 1999 15:54:16 -0500 (EST) Resent-Message-Id: <199911142054.PAA09342@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Sun, 14 Nov 1999 12:52:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: results of interoperability testing: tdav.py (client) vs five servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3581 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Tuesday, November 09, 1999 2:01 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] results of interoperability testing: tdav.py (client) vs five servers I tried this evening to use tdav.py to test five webdav servers for compliance with RFC 2518. www.hisdad.org.nz:80 webdav.zope.org:2518 kurgan.lyra.org:8080 www.sharemation.com:80 pydav (running locally) These represent every server that I believe to be accesible via the Internet I do not know of anyone running the MS server on an open machine, alas. 1. hisdad I am not sure what kind of server this is, except it's clearly using Apache. I was not able to authenticate. The server claims to support basic authentication. It may be an error in the authentication code of davlib, or perhaps the server's authentication is not configured correctly. I will try this after the server administrator gets back to me. 2. Zope This is a class 1 server. The DAV:getcontenttype appears to not be supported. A PROPFIND for this property returned no data. It appears that the server does not support any of the DAV properties. An attempt to get all properties of foo.html (which I created) produced exactly one result, for http://www.zope.org/propsets/defaulttitle. RFC 2518 13.1 and following list several properties that MUST be supported, among them DAV:getcontentlanguage, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag and DAV:getresourcetype, so it appears to me this server is not fully compliant. 3. Lyra *** basic tests Server claims to support locking Resource type of /dav/ is DAV:collection: PASS *** Testing error cases for MakeCollection Attempt to create collection that already exists should fail: PASS Attempt to create collection with no parent should fail: PASS *** Testing Delete Attempt to delete a non-existant resource should complain: PASS *** Testing Put /dav/foo.html PUT of a new resource is possible: PASS The media type used in PUT's Content-Type is returned by a PROPFIND FAIL GetProp of /dav/foo.html DAV:getcontenttype returned ['text/html'] not text/plain *** Testing Get Mime type in Header of GET is same as that used in PUT: FAIL, it was text/html but should have been text/plain Number of bytes returned by GET is same as the number PUT: PASS *** Testing Head HEAD header for content-type has same value as GET header: PASS HEAD header for content-length has same value as GET header: PASS *** Testing Properties The DAV:getcontenttype property is the same as that in the GET header: FAIL it was text/html not text/plain The getcontentlength property is the same as the value in the GET header: PASS PROPPATCH of dead property (http://parc.xerox.com/standards/burlap/foo) is possible: PASS PROPFIND retrieves same value : PASS Attempt to PROPPATCH a readonly property should fail PASS *** Testing LOCK with /dav/foo.html locked. Got token: opaquelocktoken:39a268f8-1dd2-11b2-959e-fb4938e57af8 Attempt to Lock resource already locked should fail: FAIL (it worked) It was not possible to continue beyond this point. 4. sharemation (aka Xythos) bash.exe-2.02$ python tdav.py -h www.sharemation.com -p 80 -collection /~jrd/ -verbose *** basic tests Server claims to support locking Resource type of /~jrd/ is DAV:collection: PASS *** Testing error cases for MakeCollection Attempt to create collection that already exists should fail: PASS Attempt to create collection with no parent should fail: PASS *** Testing Delete Attempt to delete a non-existant resource should complain: PASS *** Testing Put /~jrd/foo.html PUT of a new resource is possible: PASS The media type used in PUT's Content-Type is returned by a PROPFIND PASS *** Testing Get Mime type in Header of GET is same as that used in PUT: PASS Number of bytes returned by GET is same as the number PUT: PASS *** Testing Head HEAD header for content-type has same value as GET header: PASS HEAD header for content-length has same value as GET header: PASS *** Testing Properties The DAV:getcontenttype property is the same as that in the GET header: PASS The getcontentlength property is the same as the value in the GET header: PASS PROPPATCH of dead property (http://parc.xerox.com/standards/burlap/foo) is possible: PASS PROPFIND retrieves same value : PASS Attempt to PROPPATCH a readonly property (DAV:creationdate) should fail PASS dead property http://example.com/author was preserved across deletion of /~jrd/foo.html PropPatch failed with tagged-list production PUT could not create resource in a locked collection even with token Traceback (innermost last): File "tdav.py", line 679, in ? newcoll = test_coll + "newcoll/" File "davlib.py", line 157, in MakeCollection self.Invoke ('MKCOL', uri, h) File "davlib.py", line 369, in Invoke raise Locked Locked (it was not possible to continue automated testing beyond this point.) 5. Pydav The tests worked completely, but that is not surprising since I wrote both the test script and the server, so it does not show any true interoperation. Note that the list of tests run is only partial. (beyond a certain point, the automatic test script only reports problems, not successes, so you aren't seeing any indication of the more obscure and complex tests) bash.exe-2.02$ python tdav.py -h localhost -verbose *** basic tests Server claims to support locking Resource type of / is DAV:collection: PASS *** Testing error cases for MakeCollection Attempt to create collection that already exists should fail: PASS Attempt to create collection with no parent should fail: PASS *** Testing Delete Attempt to delete a non-existant resource should complain: PASS *** Testing Put /foo.html PUT of a new resource is possible: PASS The media type used in PUT's Content-Type is returned by a PROPFIND PASS *** Testing Get Mime type in Header of GET is same as that used in PUT: PASS Number of bytes returned by GET is same as the number PUT: PASS *** Testing Head HEAD header for content-type has same value as GET header: PASS HEAD header for content-length has same value as GET header: PASS *** Testing Properties The DAV:getcontenttype property is the same as that in the GET header: PASS The getcontentlength property is the same as the value in the GET header: PASS PROPPATCH of dead property (http://parc.xerox.com/standards/burlap/foo) is possible: PASS PROPFIND retrieves same value : PASS *** Getting all properties of /foo.html text/plain fish 1999-11-09T21:41:09Z 51 Tue, 09 Nov 1999 21:41:09 GMT Attempt to PROPPATCH a readonly property (DAV:creationdate) should fail PASS *** Testing LOCK with /foo.html *** Trying Unlock opaquelocktoken:942183673.149 *** More lock tests *** Trying creation and deletion *** Trying misc. tests *** Testing locks on null resource From w3c-dist-auth-request@w3.org Sun Nov 14 16:09:42 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26067 for ; Sun, 14 Nov 1999 16:09:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA09548; Sun, 14 Nov 1999 15:58:21 -0500 (EST) Resent-Date: Sun, 14 Nov 1999 15:58:21 -0500 (EST) Resent-Message-Id: <199911142058.PAA09548@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Sun, 14 Nov 1999 12:57:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: Learning WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3582 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Jaime Cerda Garza [mailto:jaimecerda@hotmail.com] Sent: Tuesday, November 09, 1999 4:19 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Learning WebDAV Hi I was wondering if anyone could tell me where could I learn WebDAV from the beggining. I working on an important project to use a WebDAV repository in connection with a customized interface. But I can't see anywhere some explanations about the examples given in all the documentation in the internet, and also I haven't found a book that talks about this protocol. Can anyone please help? Jaime Cerda jaimecerda@hotmail.com From w3c-dist-auth-request@w3.org Sun Nov 14 16:11:40 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27077 for ; Sun, 14 Nov 1999 16:11:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09659; Sun, 14 Nov 1999 16:00:04 -0500 (EST) Resent-Date: Sun, 14 Nov 1999 16:00:04 -0500 (EST) Resent-Message-Id: <199911142100.QAA09659@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Sun, 14 Nov 1999 12:58:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: more interoperation: Cyberteams Webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3583 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Also caught by the spam filter -- my apologies for not catching this sooner. - Jim -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Thursday, November 11, 1999 12:16 PM To: w3c-dist-auth@w3.org Cc: webdav@cyberteams.com Subject: [Moderator Action] more interoperation: Cyberteams Webdav Today I tested the Cyberteams webdav server. I regret to say that this web server is far from compliant with RFC 2518. I found two problems. 1) The server returns an invalid Content-Type for a PROPFIND. The content type is httpd/unix-directory but should be text/xml 2) The server ignores the Depth header (or at least it ignores Depth: 0) on PROPFIND. As a result, it returns a great deal more information that one desires There may be other problems, but I was not able to make any progress beyond this point. (In principle, my test code should recover from these two problems but it does not. I hope to make it more robust, but still both of these problems are violations of RFC 2518 and should be fixed.) telnet www.cyberteams.com 8080 Trying 209.68.7.109... Connected to cyberteams.com. Escape character is '^]'. PROPFIND / HTTP/1.1 Host: www.cyberteams.com Depth: 0 Authorization: Basic anJkOmYybGRzcDFy Content-Type: text/xml Content-Length: 107 HTTP/1.1 200 OK Date: Thu, 11 Nov 1999 19:41:23 GMT Server: Apache/1.3.6 (Unix) WSD/DAV 0.6.7 X-Powered-By: WSD (http://www.cyberteams.com/) Content-Length: 3060 Content-Type: httpd/unix-directory Content-Location: http://qs33.pair.com:8080// Ms-Author-Via: DAV / HTTP/1.1 200 OK http://qs33.pair.com:8080/Galaxy/ HTTP/1.1 200 OK etc From w3c-dist-auth-request@w3.org Sun Nov 14 16:14:43 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28598 for ; Sun, 14 Nov 1999 16:14:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA10028; Sun, 14 Nov 1999 16:03:14 -0500 (EST) Resent-Date: Sun, 14 Nov 1999 16:03:14 -0500 (EST) Resent-Message-Id: <199911142103.QAA10028@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Sun, 14 Nov 1999 13:01:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: ANN: Beta test of CyberTeams WebDAV module and new Test Server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3584 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit While this announcement made it out to the DeltaV and DAV-Announce lists, it unfortunately ws caught by the spam filter going to the DAV list... - Jim -----Original Message----- From: Randall Severy [mailto:severy@cyberteams.com] Sent: Wednesday, November 10, 1999 10:49 AM To: w3c-dist-auth@w3.org; ietf-dav-versioning@w3.org; dav-announce@lyra.org Subject: [Moderator Action] ANN: Beta test of CyberTeams WebDAV module and new Test Server Hello everyone! For almost a year now, CyberTeams has provided a WebDAV test server to the WebDAV community based on our WebSite Director Lite (WSDLite) web content management product. We are pleased to announce the availability of a new WebDAV test server that includes WebDAV access to our premier product, WebSite Director (WSD). In addition to the file management capabilities available in WSDLite, WebSite Director includes extensive workflow capabilities, approvals management, and version control. In a recent PC Week Shoot-Out review, WebSite Director was rated the best workflow product for web content management. By supporting the WebDAV protocol in WebSite Director, even the largest web maintenance teams can now take advantage of the seamless interface between WebDAV clients and WebSite Director. In addition to using our new test server, you can now try out our WebDAV-enabled products on your own web server by participating in the Beta Test of the CyberTeams WebDAV module. WebDAV support for the CyberTeams product line is currently available through a custom Apache add-on module that interfaces directly with our WSD and WSDLite products. Like the rest of the CyberTeams product line, the WebDAV module is available for the BSDI, FreeBSD, HP-UX, Linux, SGI, Solaris, SunOS, and Windows NT environments. To access our new WebDAV test server you will need a login username and password. You can request a login username and password using a request form available on our WebDAV test site page at: http://www.cyberteams.com/webdav Click on the "Request Demo Access" link on that page and fill in the form to request a username and password. We will activate the username and password you supply and send you a confirmation of access by return e-mail. Since the old WebDAV test server is no longer in operation, you will need to request a new username even if you have a username on the old server. To participate in the Beta Test of the WebDAV-enabled CyberTeams products on your own web server you will need to download the CyberTeams WebDAV add-on module as well as either WebSite Director or WebSite Director Lite. For details on the beta test, click on the "Request Download Access" link on the WebDAV test site page at: http://www.cyberteams.com/webdav In addition to access through the WebDAV protocol, all of the functionality of WebSite Director and WSDLite is available from any web browser, using the products as server-based CGI applications. Some of the workflow features of WebSite Director are not available through the WebDAV protocol, so you will need to log in to the product through a web browser to perform some operations. Both WSD and WSDLite can also be used to verify the results of WebDAV methods by using them to explore the contents of the web server filesystem after a series of WebDAV operations. If you are using our WebDAV test server, you can use the same username and password used for WebDAV access to access WSD or WSDLite by following the appropriate link on the WebDAV test site page at http://www.cyberteams.com/webdav . The latest version of the CyberTeams WebDAV add-on module includes full support for Microsoft's Web Folders capability, which is included in Office 2000 and Internet Explorer 5.0. Using Web Folders, new web content or content updates can be submitted directly into WebSite Director's workflow process using a simple drag and drop operation. Similar access to WSD and WSDLite should be possible from any WebDAV client, but we have only tested successful operation with Web Folders. We would like to hear any results of any testing you do with our WebDAV test server or our WebDAV add-on module installed on your own web server. Please send any testing feedback, problem reports, or suggestions to "webdav@cyberteams.com". If you would like more information about CyberTeams or our products, visit our web site at http://www.cyberteams.com or send e-mail to "info@cyberteams.com". Regards, Randall Severy President and CEO, CyberTeams, Inc. Randall Severy severy@cyberteams.com http://www.cyberteams.com/severy CyberTeams, Inc. info@cyberteams.com http://www.cyberteams.com Mt. Airy, MD (301) 829-6144 "Building effective teams in cyberspace" 1-888-832-5575 From w3c-dist-auth-request@w3.org Sun Nov 14 16:23:03 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02666 for ; Sun, 14 Nov 1999 16:23:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA10917; Sun, 14 Nov 1999 16:11:19 -0500 (EST) Resent-Date: Sun, 14 Nov 1999 16:11:19 -0500 (EST) Resent-Message-Id: <199911142111.QAA10917@www19.w3.org> From: Jim Whitehead To: WebDAV WG , jaimecerda@hotmail.com MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Sun, 14 Nov 1999 13:10:04 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: Learning WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3585 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi Jaime, First, sorry for the slow response. The WebDAV WG mailing list has a spam filtering feature turned on that thinks that any email not sent by a subscriber to the mailing list is spam. As list administrator, it's then up to me to forward any legitimate messages accidentally caught by the spam filter along to the mailing list. Since I was busy at the IETF meeting in Washington, DC last week, I wasn't able to forward your email as quickly as I would have liked. As for your question, there are currently no tutorials or books that cover the entire WebDAV protocol. There are some articles available on the WebDAV.org web site , in the papers section that provide good background on the protocol. Some of your questions might also be answered by the WebDAV list of frequently asked questions (FAQ), available at: http://www.webdav.org/other/faq.html The dav-dev mailing list, for WebDAV developers, is another good source of information on WebDAV: http://dav.lyra.org/mailman/listinfo/dav-dev - Jim > From: Jaime Cerda Garza [mailto:jaimecerda@hotmail.com] > Sent: Tuesday, November 09, 1999 4:19 PM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] Learning WebDAV > > > Hi I was wondering if anyone could tell me where could I learn WebDAV from > the beggining. I working on an important project to use a WebDAV > repository > in connection with a customized interface. But I can't see anywhere some > explanations about the examples given in all the documentation in the > internet, and also I haven't found a book that talks about this protocol. > Can anyone please help? > > Jaime Cerda > jaimecerda@hotmail.com > From w3c-dist-auth-request@w3.org Sun Nov 14 20:16:54 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05707 for ; Sun, 14 Nov 1999 20:16:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA16188; Sun, 14 Nov 1999 20:05:17 -0500 (EST) Resent-Date: Sun, 14 Nov 1999 20:05:17 -0500 (EST) Resent-Message-Id: <199911150105.UAA16188@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Sun, 14 Nov 1999 17:04:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Alternate DAV list archive Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3586 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi all, A fellow Ph.D. student here at UCI, Michael Kantor , is working on a project called "Knowledge Depot" for his dissertation. In short, Knowledge Depot stores email in a database, and then allows multiple views upon that database. Instead of the folders metaphor of existing mail tools where filters put mail messages into a folder when the email arrives, Knowledge Depot associates each view with a database query. Michael has set up Knowledge Depot on the WebDAV working group mailing list archives, and his database now has the complete set of archives. It's currently available for public use. To gain access to this site, go to http://kdepot.ics.uci.edu/users/kdepot/index.pl?webdav and create an account for yourself. You can use this site to subscribe to receive digests of all mailing list discussions that match specific constraints (such as being on a specific topic or from a specific user). You can also specify how detailed and how frequent those digests should be. I've pre-populated the archive with some potentially interesting views, such as "recent email about MOVE", or "recent email about BIND", and "meeting minutes". I'm sure you'll think of others, and can use the query interface to try them out. Since this is Michael's Ph.D. topic, and not mine, please send Michael your comments and questions, not me :-) DISCLAIMER ---------- This system is provided as part of a research project studying the impact of this type of technology, and as such, we may study usage logs to understand how the system was used and whether it was effective. Therefore you should understand that by using the system, you are agreeing to participate in this study. Participation contains no obligations, this disclaimer is simply to notify you that this is part of a study. - Jim From w3c-dist-auth-request@w3.org Mon Nov 15 06:05:01 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05891 for ; Mon, 15 Nov 1999 06:05:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA00260; Mon, 15 Nov 1999 05:56:02 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 05:56:02 -0500 (EST) Resent-Message-Id: <199911151056.FAA00260@www19.w3.org> Message-Id: <4.1.19991115115007.00ad4af0@pop.xs4all.nl> X-Sender: jdavis@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 Nov 1999 11:54:10 +0100 To: w3c-dist-auth@w3.org From: Jim Davis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: further interop testing: IIS Windows 2000 Beta 3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3587 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Worked perfectly, with two exceptions: 1) does not preserve the xml:lang attribute (12.13.2) 2) Does not support locking collections. Details below: ------------------------ detailed report ------------------------------------ python tdav.py -h dav.ics.uci.edu -p 80 -collection /jdavis/ Server claims to support locking Resource type of collection /jdavis/ is DAV:collection: PASS *** Testing error cases for MakeCollection Attempt to create collection that already exists should fail: PASS Attempt to create collection with no parent should fail: PASS *** Testing Delete Attempt to delete a non-existant resource should complain: PASS *** Testing Put /jdavis/foo.html PUT of a new resource is possible: PASS The media type used in PUT's Content-Type is returned by a PROPFIND: PASS *** Testing Get Mime type in Header of GET is same as that provided by PUT: PASS Number of bytes returned by GET is same as the number PUT: PASS *** Testing Head HEAD header for content-type has same value as GET header: PASS HEAD header for content-length has same value as GET header: PASS *** Testing Properties The DAV:getcontenttype property is the same as that in the GET header: PASS The getcontentlength property is the same as the value in the GET header: PASS PROPPATCH of dead property (http://parc.xerox.com/standards/burlap/foo) is possible: PASS PROPFIND retrieves same value : PASS *** Getting all properties of /jdavis/foo.html http://dav.ics.uci.edu/jdavis/foo.html HTTP/1.1 200 OK fish 51 1999-11-15T10:04:22.753Z foo.html "b0977b2542fbf1:c91" Mon, 15 Nov 1999 10:32:20 GMT 0 0 text/plain fish 51 1999-11-15T10:04:22.753Z foo.html "b0977b2542fbf1:c91" Mon, 15 Nov 1999 10:32:20 GMT 0 0 text/plain Attempt to PROPPATCH a readonly property (DAV:creationdate) should fail PASS A property may be set to an empty value: PASS A property may have an xml:lang attribute PASS The xml:lang attribute is returned by PROPFIND FAIL xml:lang attribute not returned in property value http://dav.ics.uci.edu/jdavis/foo.html HTTP/1.1 200 OK h van der kaas The Dead properties of a resource are deleted with the resource: PASS *** Testing locking Can lock /jdavis/foo.html (exclusive write lock, no timeout) PASS: (token: opaquelocktoken:DBE33E94-9ADC-11D3-B82A-00105A989226:214748364857) Lock discovery property returns same token as Lock did: PASS Lock prevents PROPPATCH from adding a property: PASS PROPPATCH on locked resource using tagged-list production: PASS PROPPATCH on locked resource using no-tag-list production: PASS lock prevents PROPPATCH from deleting a property: PASS PropPatch deletion allowed using no-tag-list production: PASS Can't PUT to a locked resource without token: PASS Can PUT to locked resource with token: PASS Can't LOCK a locked resourc: PASS Can UNLOCK a resource: PASS Server does something reasonable with unsupported timeouts: PASS: locked /jdavis/foo.html with Second-180 It is possible to lock a collection (/jdavis/): FAIL, Forbidden A severe error or problem occurred: Could not lock /jdavis/ Testing can't continue Last error entity

HTTP/1.1 403 Forbidden


LOCKing a collection is not allowed

1 error(s) bash.exe-2.02$ From w3c-dist-auth-request@w3.org Mon Nov 15 06:17:51 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08612 for ; Mon, 15 Nov 1999 06:17:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA01112; Mon, 15 Nov 1999 06:09:43 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 06:09:43 -0500 (EST) Resent-Message-Id: <199911151109.GAA01112@www19.w3.org> Date: Mon, 15 Nov 1999 03:09:02 -0800 (PST) From: Greg Stein To: Jim Davis cc: w3c-dist-auth@w3.org In-Reply-To: <4.1.19991115115007.00ad4af0@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: further interop testing: IIS Windows 2000 Beta 3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3588 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Mon, 15 Nov 1999, Jim Davis wrote: >... > > > > > > > > > > The lockentry elements are incorrect. There should be lockscope and locktype elements in there. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 15 08:18:49 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06609 for ; Mon, 15 Nov 1999 08:18:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA03612; Mon, 15 Nov 1999 08:02:47 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 08:02:47 -0500 (EST) Resent-Message-Id: <199911151302.IAA03612@www19.w3.org> Message-Id: <4.1.19991115135230.00ad6e20@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 Nov 1999 14:00:58 +0100 To: Kevin Wiggen From: Jim Davis Cc: w3c-dist-auth@w3.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: interoperability testing with Xythos/Sharemation server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3589 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 01:40 PM 11/14/99 -0800, Kevin Wiggen wrote: > >Jim, > >I don't know how to reproduce your findings, and I can't. Can you make your >test script be even more verbose and print out the Headers and XML you are >sending in the Request, and then what the headers and body that my server >gives you in the Response. This will make it easier for me (and you) to >track down issues, as I can see the series of Request/Response pairs for >your tests. >dead property http://example.com/author was preserved across deletion of >/~jrd/foo.html This was a bug in my test code. Xythos returns two propstat elements in this case. The first one had an empy prop element, and a status of 200. The second one had the prop I was looking for, and the appropriate status code 404. As far as I can tell it's perfectly legal for Xythos to return that first propstat, even though there were no props in it. but it confused my code. Now fixed. Xythos is not guilty. >PropPatch failed with tagged-list production here is more detail. The request is PROPPATCH /~jrd/foo.html If: () Content-Length: 185 Content-Type: text/xml 259 The reply is server: IBM_HTTP_Server/1.3.6 Apache/1.3.7-dev (Win32) ApacheJServ/1.0 content-type: text/xml; charset=UTF-8 content-length: 320 date: Mon, 15 Nov 1999 12:55:00 GMT http://www.sharemation.com/~jrd/foo.html HTTP/1.1 423 Locked Does the If header I am passing look wrong to you? From w3c-dist-auth-request@w3.org Mon Nov 15 08:22:47 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07645 for ; Mon, 15 Nov 1999 08:22:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA03761; Mon, 15 Nov 1999 08:14:37 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 08:14:37 -0500 (EST) Resent-Message-Id: <199911151314.IAA03761@www19.w3.org> Message-Id: <4.1.19991115140742.00ae16a0@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 Nov 1999 14:12:40 +0100 To: Brian Lloyd From: Jim Davis Cc: w3c-dist-auth@w3.org In-Reply-To: <613145F79272D211914B0020AFF6401914DD2D@gandalf.digicool.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Does zope mess with the body in a GET? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3590 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I did a PUT to foo.html. I sent 51 characters "Despite the name, this is a plain text file." when I did a GET I got back 71 characters, " Despite the name, this is a plain text file." Looks to me like Zope added those HTML elements for me. this seems undesirable. What is also bizarre is that if I do HEAD, I get back length of 51. So I think Zope must be adding them when I do then GET. For what it's worth, after the PUT I also did PROPPATCH to set the type to text/plain. But that seemed to have no effect From w3c-dist-auth-request@w3.org Mon Nov 15 08:32:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10090 for ; Mon, 15 Nov 1999 08:32:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA04070; Mon, 15 Nov 1999 08:24:11 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 08:24:11 -0500 (EST) Resent-Message-Id: <199911151324.IAA04070@www19.w3.org> Message-Id: <4.1.19991115141458.00ac9630@pop.xs4all.nl> X-Sender: jdavis@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 Nov 1999 14:22:22 +0100 To: w3c-dist-auth@w3.org From: Jim Davis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: can multiple propstat elements within response have same status Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3591 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The DTD allows a response for a given href to have multiple propstats. But is it required that each such propstat have a different status? Here's an example of a response frm Zope. It seems to have grouped the properties by XML namespace. So there are three propstats, each with status 200. From the RFC, this seems legal to me. it's a slight nuisance to process but nothing extreme. Just thought I'd ask for other opinions. It is legal, isn't it? /users/jdavis/foo.html HTTP/1.1 200 OK foo.html Mon, 15 Nov 1999 13:05:38 GMT 51 /users/jdavis/foo.html /users/jdavis/foo.html/document_src HTTP/1.1 200 OK fish HTTP/1.1 200 OK From w3c-dist-auth-request@w3.org Mon Nov 15 10:02:56 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01407 for ; Mon, 15 Nov 1999 10:02:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA05917; Mon, 15 Nov 1999 09:54:37 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 09:54:37 -0500 (EST) Resent-Message-Id: <199911151454.JAA05917@www19.w3.org> Date: Mon, 15 Nov 1999 06:53:50 -0800 (PST) From: Greg Stein To: Jim Davis cc: w3c-dist-auth@w3.org In-Reply-To: <4.1.19991115141458.00ac9630@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: can multiple propstat elements within response have same status Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3592 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Mon, 15 Nov 1999, Jim Davis wrote: > The DTD allows a response for a given href to have multiple propstats. > But is it required that each such propstat have a different status? Not as far as I know. I don't do it myself, but it doesn't seem to violate anything that I can think of. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 15 18:32:16 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13667 for ; Mon, 15 Nov 1999 18:32:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA18616; Mon, 15 Nov 1999 18:23:49 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 18:23:49 -0500 (EST) Resent-Message-Id: <199911152323.SAA18616@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: w3c-dist-auth@w3.org Message-ID: <8525682A.00807D82.00@D51MTA03.pok.ibm.com> Date: Mon, 15 Nov 1999 18:24:29 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: locknull resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3593 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Thanks Greg. I've added that scenario to the list of locking issues. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Nov 15 18:48:50 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21853 for ; Mon, 15 Nov 1999 18:48:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA19115; Mon, 15 Nov 1999 18:40:45 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 18:40:45 -0500 (EST) Resent-Message-Id: <199911152340.SAA19115@www19.w3.org> Date: Mon, 15 Nov 1999 15:30:04 -0800 From: Kevin Wiggen In-reply-to: <4.1.19991115135230.00ad6e20@pop.xs4all.nl> To: Jim Davis Cc: w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Priority: 3 (Normal) Subject: RE: interoperability testing with Xythos/Sharemation server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3594 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Header was fine, we were choking on the port (.com/ != .com:80/) Fixed, please continue your testing, Kevin -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Monday, November 15, 1999 5:01 AM To: Kevin Wiggen Cc: w3c-dist-auth@w3.org Subject: Re: interoperability testing with Xythos/Sharemation server At 01:40 PM 11/14/99 -0800, Kevin Wiggen wrote: > >Jim, > >I don't know how to reproduce your findings, and I can't. Can you make your >test script be even more verbose and print out the Headers and XML you are >sending in the Request, and then what the headers and body that my server >gives you in the Response. This will make it easier for me (and you) to >track down issues, as I can see the series of Request/Response pairs for >your tests. >dead property http://example.com/author was preserved across deletion of >/~jrd/foo.html This was a bug in my test code. Xythos returns two propstat elements in this case. The first one had an empy prop element, and a status of 200. The second one had the prop I was looking for, and the appropriate status code 404. As far as I can tell it's perfectly legal for Xythos to return that first propstat, even though there were no props in it. but it confused my code. Now fixed. Xythos is not guilty. >PropPatch failed with tagged-list production here is more detail. The request is PROPPATCH /~jrd/foo.html If: () Content-Length: 185 Content-Type: text/xml 259 The reply is server: IBM_HTTP_Server/1.3.6 Apache/1.3.7-dev (Win32) ApacheJServ/1.0 content-type: text/xml; charset=UTF-8 content-length: 320 date: Mon, 15 Nov 1999 12:55:00 GMT http://www.sharemation.com/~jrd/foo.html HTTP/1.1 423 Locked Does the If header I am passing look wrong to you? From w3c-dist-auth-request@w3.org Mon Nov 15 19:24:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09426 for ; Mon, 15 Nov 1999 19:24:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA20391; Mon, 15 Nov 1999 19:15:51 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 19:15:51 -0500 (EST) Resent-Message-Id: <199911160015.TAA20391@www19.w3.org> From: marjorie@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525682B.00016A26.00@d54mta04.raleigh.ibm.com> Date: Mon, 15 Nov 1999 19:13:05 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: locknull resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3595 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This isn't perhaps that unexpected. If one models the lifecycle of a resource as a finite state machine, then it goes from non-existant (i.e., a reference to resource whose current state is undefined) to lock-null on LOCK. More locks leave it in this state. It only leaves this state and goes back to non-existant if there are no more locks. A PUT moves it from the lock-null state to the existing-resource state, etc. Greg Stein on 11/11/99 07:58:06 PM To: w3c-dist-auth@w3.org cc: Subject: locknull resources Given the *current* spec :-), has anybody noticed that you can actually have a locknull resource that does not have any *direct* locks on it? For example: Establish a locknull as /a/b with a shared lock. Now, lock /a with a Depth: infinity lock, shared. Finally, unlock /a/b with the first locktoken. Just wanted to mention this to others, as it was pretty unexpected for me... Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 15 19:29:30 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11613 for ; Mon, 15 Nov 1999 19:29:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA20547; Mon, 15 Nov 1999 19:21:31 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 19:21:31 -0500 (EST) Resent-Message-Id: <199911160021.TAA20547@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 15 Nov 1999 16:20:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: RE: Does zope mess with the body in a GET? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3596 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Another message caught by the spam filter. - Jim -----Original Message----- From: Brian Lloyd [mailto:Brian@digicool.com] Sent: Monday, November 15, 1999 11:07 AM To: 'Jim Davis' Cc: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: Does zope mess with the body in a GET? > I did a PUT to foo.html. I sent 51 characters > "Despite the name, this is a plain text file." > > when I did a GET I got back 71 characters, > > " > Despite the name, this is a plain text file." > > Looks to me like Zope added those HTML elements for me. this seems > undesirable. > > What is also bizarre is that if I do HEAD, I get back length of 51. > > So I think Zope must be adding them when I do then GET. It is - this is a documented "feature" from a long time ago in Zope's evolution. Because Zope is a pretty dynamic multiprotocol object environment rather than a simple file server, there are a number of similar issues that boil down to an impedence mismatch between the expectations for dynamic vs. static resources and (in some cases) the need to maintain b/w compatibility :( This is especially true regarding "templatish" objects that may or may not be thought of as "content" depending on what you are doing with them. I suspect that this is also an issue with ASP, PHP, et. al. too - it would be great to be able to manage these things in a standards-based way, but currently DAV is very static-file centric in its approach. I'm not knocking that - but it makes the practical use of DAV pretty limited on sites that can't get by on just static files. I've been hoping that we can wrangle the time to make some contributions in this area. > For what it's worth, after the PUT I also did PROPPATCH to > set the type to > text/plain. > But that seemed to have no effect > I'll take a look at that. Thanks! Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com From w3c-dist-auth-request@w3.org Mon Nov 15 19:34:43 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14142 for ; Mon, 15 Nov 1999 19:34:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA20773; Mon, 15 Nov 1999 19:26:47 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 19:26:47 -0500 (EST) Resent-Message-Id: <199911160026.TAA20773@www19.w3.org> From: Jim Whitehead To: Brian Lloyd Cc: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Mon, 15 Nov 1999 16:25:22 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <613145F79272D211914B0020AFF6401914DD57@gandalf.digicool.com> Subject: RE: [Moderator Action] RE: Does zope mess with the body in a GET? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3597 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Brian Llyod writes: > This is especially true regarding "templatish" objects that may > or may not be thought of as "content" depending on what you are > doing with them. I suspect that this is also an issue with ASP, PHP, > et. al. too - it would be great to be able to manage these things > in a standards-based way, but currently DAV is very static-file > centric in its approach. I'm not knocking that - but it makes > the practical use of DAV pretty limited on sites that can't get > by on just static files. I've been hoping that we can wrangle > the time to make some contributions in this area. Well, I would certainly welcome work in this area. So far, people have not been taking to the "source link" approach, where to find the unprocessed source of an object, you look up a URL in the source link on the original resource (by performing a PROPFIND), then perform a GET on the destination URL of the source link. - Jim From w3c-dist-auth-request@w3.org Mon Nov 15 20:48:28 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18729 for ; Mon, 15 Nov 1999 20:48:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA22043; Mon, 15 Nov 1999 20:40:26 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 20:40:26 -0500 (EST) Resent-Message-Id: <199911160140.UAA22043@www19.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14384.46582.984172.951014@gilliam.users.flyingcroc.net> Date: Mon, 15 Nov 1999 17:40:06 -0800 (PST) From: Brett McCormick To: WebDAV WG In-Reply-To: References: X-Mailer: VM 6.74 under Emacs 19.34.1 Subject: Re: FW: RE: Does zope mess with the body in a GET? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3598 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Someone wrote: > This is especially true regarding "templatish" objects that may > or may not be thought of as "content" depending on what you are > doing with them. I suspect that this is also an issue with ASP, PHP, > et. al. too - it would be great to be able to manage these things > in a standards-based way, but currently DAV is very static-file > centric in its approach. I'm not knocking that - but it makes > the practical use of DAV pretty limited on sites that can't get > by on just static files. I've been hoping that we can wrangle > the time to make some contributions in this area. This situation has already been considered. Section 5.4 of RFC 2518 (the webdav spec) is titled "Source Resources and Output Resources." The content returned by zope would be considered the "output resource." Since it is dynamically generated, you shouldn't be able to PUT the new content at all. You need a separate URI to refer to the source resource. Frustrating, I know. I am having to deal with the same issues, since I'm modifying my HTML before its being sent out. The best solution I've come up with is to use another URI that is mapped directly to the filesystem. There's a way to link from the output resource to the source resource on webdav compliant servers, I would check the above section of the RFC for details. --brett From w3c-dist-auth-request@w3.org Mon Nov 15 20:55:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22039 for ; Mon, 15 Nov 1999 20:55:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA22258; Mon, 15 Nov 1999 20:47:39 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 20:47:39 -0500 (EST) Resent-Message-Id: <199911160147.UAA22258@www19.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14384.46750.280111.163532@gilliam.users.flyingcroc.net> Date: Mon, 15 Nov 1999 17:42:54 -0800 (PST) From: Brett McCormick To: Jim Whitehead Cc: Brian Lloyd , w3c-dist-auth@w3.org In-Reply-To: References: <613145F79272D211914B0020AFF6401914DD57@gandalf.digicool.com> X-Mailer: VM 6.74 under Emacs 19.34.1 Subject: RE: [Moderator Action] RE: Does zope mess with the body in a GET? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3599 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit When you say people have not "been taking" to that approach, does that mean they just don't like it, are not implementing it, or both? It seems like the best approach to me. There is no way to determine where the content is actually coming from without these links, any method we use for this is going to have them. Has anyone been using or seen any implementations of the source resource links? --brett On Monday, 15 November 1999, at 16:25:22, Jim Whitehead wrote: > Well, I would certainly welcome work in this area. So far, people have not > been taking to the "source link" approach, where to find the unprocessed > source of an object, you look up a URL in the source link on the original > resource (by performing a PROPFIND), then perform a GET on the destination > URL of the source link. > > - Jim From w3c-dist-auth-request@w3.org Mon Nov 15 21:40:30 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09677 for ; Mon, 15 Nov 1999 21:40:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA23115; Mon, 15 Nov 1999 21:32:27 -0500 (EST) Resent-Date: Mon, 15 Nov 1999 21:32:27 -0500 (EST) Resent-Message-Id: <199911160232.VAA23115@www19.w3.org> Date: Mon, 15 Nov 1999 18:31:50 -0800 (PST) From: Greg Stein To: w3c-dist-auth@w3.org cc: Brian Lloyd In-Reply-To: <14384.46750.280111.163532@gilliam.users.flyingcroc.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: DAV:source (was: Does zope mess with the body in a GET?) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3600 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list As a solution to this, on one of my DAV setups, I've created two Locations pointing to the same filesystem directory: Alias /users-go-here /some/path Alias /author-goes-here /some/path-source (where /some/path-source is a symlink to /some/path; I just realized I can probably drop the symlink and use the same filesystem target in both cases) I then force everything in the source directory to text/plain so that CGI, PHP, etc won't execute in there. This allows the author to interact with the source files: ForceType text/plain Of course, all of this is simply getting around the dynamic vs static stuff and providing access to the source of (dynamic) pages. It isn't a solution to the thing (yet). I haven't thought about it completely, but may create a new Apache directive that reads something like: DAVSource /users-go-here /author-goes-here This would apply to any resource under that namespace, creating a similar source URI into the target namespace. It would also set up an Alias and a ForceType record. The biggest thing that has stopped me is simply time :-) and researching on whether mod_dav can reach into the Alias and ForceType mechanism (or whether I'd have to reimplement). Cheers, -g On Mon, 15 Nov 1999, Brett McCormick wrote: > When you say people have not "been taking" to that approach, does that > mean they just don't like it, are not implementing it, or both? > > It seems like the best approach to me. There is no way to determine > where the content is actually coming from without these links, any > method we use for this is going to have them. > > Has anyone been using or seen any implementations of the source > resource links? > > --brett > > On Monday, 15 November 1999, at 16:25:22, Jim Whitehead wrote: > > > Well, I would certainly welcome work in this area. So far, people have not > > been taking to the "source link" approach, where to find the unprocessed > > source of an object, you look up a URL in the source link on the original > > resource (by performing a PROPFIND), then perform a GET on the destination > > URL of the source link. > > > > - Jim -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Nov 16 07:10:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19039 for ; Tue, 16 Nov 1999 07:10:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA01174; Tue, 16 Nov 1999 07:00:41 -0500 (EST) Resent-Date: Tue, 16 Nov 1999 07:00:41 -0500 (EST) Resent-Message-Id: <199911161200.HAA01174@www19.w3.org> Message-Id: <4.1.19991116104104.00acdde0@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 16 Nov 1999 10:51:11 +0100 To: Kevin Wiggen From: Jim Davis Cc: w3c-dist-auth@w3.org In-Reply-To: References: <4.1.19991115135230.00ad6e20@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: rules for comparing coded URL in If header? (was Xythos interop) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3601 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 03:30 PM 11/15/99 -0800, Kevin Wiggen wrote: > > >Header was fine, we were choking on the port (.com/ != .com:80/) I am glad you fixed it (and can verify that you have) but it occurs to me that just maybe it was not a bug in Xythos but rather a bug in tdav. I would like a second opinion. I was passing a coded URL that had an explicit port (80) Is there a rule about how to compare two coded URLs for identity, when one has an an explicit port and the other has no port (it was using the default port, in this case). Perhaps in RFC 2068? > >PROPPATCH /~jrd/foo.html >If: >(LockServeridu:977>) From w3c-dist-auth-request@w3.org Tue Nov 16 08:24:52 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24602 for ; Tue, 16 Nov 1999 08:24:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA02632; Tue, 16 Nov 1999 08:16:08 -0500 (EST) Resent-Date: Tue, 16 Nov 1999 08:16:08 -0500 (EST) Resent-Message-Id: <199911161316.IAA02632@www19.w3.org> X-Passed: MX on Ispra.WebWeaving.org Tue, 16 Nov 1999 13:04:08 GMT and masked X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Posted-Date: Tue, 16 Nov 1999 13:04:08 GMT Date: Tue, 16 Nov 1999 14:04:07 +0100 (CET) From: Dirk-Willem van Gulik X-Sender: dirkx@brunte.ispra.webweaving.org To: Brett McCormick cc: WebDAV WG In-Reply-To: <14384.46582.984172.951014@gilliam.users.flyingcroc.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: FW: RE: Does zope mess with the body in a GET? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3602 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Mon, 15 Nov 1999, Brett McCormick wrote: .... > > centric in its approach. I'm not knocking that - but it makes > > the practical use of DAV pretty limited on sites that can't get > > by on just static files. I've been hoping that we can wrangle > > the time to make some contributions in this area. > This situation has already been considered. Section 5.4 of RFC 2518 > (the webdav spec) is titled "Source Resources and Output Resources." But still, beside this as soon as you hit dynamic content you have two problem's hitting you; you cannot 'PUT' to the target URI so easily anymore as it has different semantics; which is more than just the content and something as simple as, say, renaming a top level directory reliably can in fact trigger locking on a virtually infinitive space of URI's deeper down. Dw From w3c-dist-auth-request@w3.org Tue Nov 16 09:11:50 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18057 for ; Tue, 16 Nov 1999 09:11:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA03904; Tue, 16 Nov 1999 09:02:42 -0500 (EST) Resent-Date: Tue, 16 Nov 1999 09:02:42 -0500 (EST) Resent-Message-Id: <199911161402.JAA03904@www19.w3.org> Date: Tue, 16 Nov 1999 09:02:25 -0500 Message-Id: <9911161402.AA04362@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (message from Dirk-Willem van Gulik on Tue, 16 Nov 1999 14:04:07 +0100 (CET)) Subject: Re: FW: RE: Does zope mess with the body in a GET? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3603 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: Dirk-Willem van Gulik ... as soon as you hit dynamic content you have two problem's hitting you; you cannot 'PUT' to the target URI so easily anymore as it has different semantics; When trying to author a dynamic resource, I believe that it makes much more sense to first do a GET to the source definition of that dynamic resource. And then the PUT would logically go back to that source definition, not to the dynamic resource. which is more than just the content and something as simple as, say, renaming a top level directory reliably can in fact trigger locking on a virtually infinitive space of URI's deeper down. I believe it makes much more sense to LOCK the source definition of a dynamic resource, rather than the dynamic resource itself. So lock checking would only be performed on the (finite) source definition space. In addition, it is likely that the location of the dynamic resource tree will be "frozen" at a specific URL, so you wouldn't be able to MOVE that tree anyway, irrespective of any locking behavior. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Nov 16 09:50:07 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06163 for ; Tue, 16 Nov 1999 09:50:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA04583; Tue, 16 Nov 1999 09:39:25 -0500 (EST) Resent-Date: Tue, 16 Nov 1999 09:39:25 -0500 (EST) Resent-Message-Id: <199911161439.JAA04583@www19.w3.org> Date: Tue, 16 Nov 1999 14:28:41 +0000 From: Joe Orton To: Jim Davis Cc: Kevin Wiggen , w3c-dist-auth@w3.org Message-ID: <19991116142841.C315@ankh.dunno.local> Mail-Followup-To: Jim Davis , Kevin Wiggen , w3c-dist-auth@w3.org References: <4.1.19991115135230.00ad6e20@pop.xs4all.nl> <4.1.19991116104104.00acdde0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <4.1.19991116104104.00acdde0@pop.xs4all.nl>; from jrd3@alum.mit.edu on Tue, Nov 16, 1999 at 10:51:11AM +0100 Subject: Re: rules for comparing coded URL in If header? (was Xythos interop) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3604 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 8bit > I was passing a coded URL that had an explicit port (80) Is there a rule > about how to compare two coded URLs for identity, when one has an an > explicit port and the other has no port (it was using the default port, in > this case). Perhaps in RFC 2068? RFC2616 section 3.2.3 has it...ž "A port that is empty or not given is equivalent to the default port for that URI-reference;" joe From w3c-dist-auth-request@w3.org Tue Nov 16 12:20:11 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13544 for ; Tue, 16 Nov 1999 12:20:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA10437; Tue, 16 Nov 1999 12:11:15 -0500 (EST) Resent-Date: Tue, 16 Nov 1999 12:11:15 -0500 (EST) Resent-Message-Id: <199911161711.MAA10437@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 16 Nov 1999 09:09:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: Does zope mess with the body in a GET? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3605 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Another message unfortunately caught by the spam filter. I have put in a request to have brian@digicool.com added to the accept2 list, but it must not have gone through yet. :-( - Jim -----Original Message----- From: Brian Lloyd [mailto:Brian@digicool.com] Sent: Tuesday, November 16, 1999 6:19 AM To: 'Brett McCormick'; Jim Whitehead Cc: Brian Lloyd; w3c-dist-auth@w3.org Subject: RE: Does zope mess with the body in a GET? > (about "source links")... > > When you say people have not "been taking" to that approach, does that > mean they just don't like it, are not implementing it, or both? > > It seems like the best approach to me. There is no way to determine > where the content is actually coming from without these links, any > method we use for this is going to have them. > > Has anyone been using or seen any implementations of the source > resource links? > > --brett Zope provides the src link in its PROPFIND response - but all current clients apparently ignore it :( Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com From w3c-dist-auth-request@w3.org Tue Nov 16 21:39:16 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17246 for ; Tue, 16 Nov 1999 21:39:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA22747; Tue, 16 Nov 1999 21:30:49 -0500 (EST) Resent-Date: Tue, 16 Nov 1999 21:30:49 -0500 (EST) Resent-Message-Id: <199911170230.VAA22747@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 16 Nov 1999 18:29:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FW: Does zope mess with the body in a GET? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3606 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Another caught by the spam filter. - Jim -----Original Message----- From: Brett McCormick [mailto:brett@sextracker.com] Sent: Tuesday, November 16, 1999 3:46 PM To: Brian Lloyd Cc: Jim Whitehead; w3c-dist-auth@w3.org Subject: RE: Does zope mess with the body in a GET? Bah, aren't they in violation of the standard then? Designated as non-compliant software? --brett On Tuesday, 16 November 1999, at 09:19:15, Brian Lloyd wrote: > > Zope provides the src link in its PROPFIND response - but all > current clients apparently ignore it :( > > > Brian Lloyd brian@digicool.com > Software Engineer 540.371.6909 > Digital Creations http://www.digicool.com > > From w3c-dist-auth-request@w3.org Wed Nov 17 13:09:54 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11652 for ; Wed, 17 Nov 1999 13:09:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA09155; Wed, 17 Nov 1999 13:00:27 -0500 (EST) Resent-Date: Wed, 17 Nov 1999 13:00:27 -0500 (EST) Resent-Message-Id: <199911171800.NAA09155@www19.w3.org> To: WebDAV WG cc: reuterj@ira.uka.de, jjh@ira.uka.de Date: Wed, 17 Nov 1999 18:56:29 +0100 From: Juergen Reuter Message-ID: <"iraun1.ira.486:17.11.99.17.56.42"@ira.uka.de> Subject: Syntax Issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3607 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hi all! While trying to implement a WebDAV/DeltaV based C/S application, some parsing related questions arose that I would like to have clarified, if possible. In the mailing archive with recent postings of this list, I did not find any related topic, but I may have overseen some posting and would also be grateful for any reference. N.B.: [WebDAV] means RFC 2518, [XML] REC-xml-19980210, [Namespaces] REC-xml-names-19990114, and [HTTP] RFC 2068. 1. [WebDAV] section 23.1 (appendix 1), and 12.12.1: As far as I understand [XML], the declaration is not a valid xml element declaration. The use of both, #PCDATA and children content href implies a mixed content declaration. For mixed content, [XML] section 3.2.2 defines [51] Mixed ::= '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*' | '(' S? '#PCDATA' S? ')'. Hence, element keepalive may be declared as which is a more general form and might need to be further restricted to its originally intended syntax on the semantic level of the specification. Alternatively, one could specify where element all would effectively replace the '"*"' PCDATA of the keepalive element. 2. At a first look, [WebDAV] section 23.1 seems to present the syntax in the style of a document type declaration as specified in [XML] section 2.8, rule [28] (doctypedecl definition). If this is intended, "the Name in the document type declaration must match the element type of the root element" (cited from [XML] validity constraint: root element type). Effectively, this would mean, that there must be an element named webdav-1.0 which serves as root element. However, I can not find an element declaration of the form . Instead, the examples in [WebDAV] seem to use elements propfind, multistatus, propertyupdate, propertybehaviour, lockinfo and prop as varying root elements. Hence, could an additional element declaration such as solve this problem? 3. The xml code in the examples in chapter 8 of [WebDAV] should, if I understand right, be compliant with the syntax specified in appendix 1. Section 2.8 of [XML] says: "An XML document is valid if it has an associated document type declaration and if the document complies with the constraints expressed in it." Without supplying a DTD, the document can only be checked for well-formedness, which does not seem to help very much for real-life applications. Hence, I would expect the xml code of the examples in chapter 8 of [WebDAV] to begin as follows or the like: According to the root element issue (see above), I would expect then followed by the lines as supplied in the examples in chapter 8, and then followed by which terminates the xml code. 4. The response in the example in section 8.1.1 [WebDAV] contains the line As far as I understand, R as an undeclared namespace prefix, as there is no declared R namespace in scope. The line should propably read as follows: 5. Section 9.1 of [WebDAV] defines the DAV header as follows: DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend] I could not find any syntax rule for extend, neither in [WebDAV], nor in [HTTP]. If extend may contain a ",", this may lead to ambigous parsing; e.g. the string "DAV:1,2,3" could be parsed with "2,3" representing the extend non-terminal. Hence, if extend has not been defined by now, it should at least be further restricted, e.g. by requiring extend = token or extend = quoted-string, with token and quoted-string being defined in [HTTP]. 6. Is there a specific reason for WebDAV not making use of xml element attributes? I think, using attributes could both, speed up parsing and simplify the grammar. For example, elements exclusive and shared could be replaced by a single enumerated attribute (see [XML] section 3.3.1, rule [57] EnumeratedType) for element lockscope. I hope I could present my issues clearly enough. Many thanks in advance! Bye, Juergen From w3c-dist-auth-request@w3.org Wed Nov 17 21:11:28 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29977 for ; Wed, 17 Nov 1999 21:11:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA27766; Wed, 17 Nov 1999 21:02:37 -0500 (EST) Resent-Date: Wed, 17 Nov 1999 21:02:37 -0500 (EST) Resent-Message-Id: <199911180202.VAA27766@www19.w3.org> From: Jim Whitehead To: Juergen Reuter , WebDAV WG Cc: jjh@ira.uka.de MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Wed, 17 Nov 1999 18:01:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <"iraun1.ira.486:17.11.99.17.56.42"@ira.uka.de> Importance: Normal Subject: RE: Syntax Issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3608 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Juergen Reuter writes: > While trying to implement a WebDAV/DeltaV based C/S application, > some parsing related questions arose that I would like to have > clarified, if possible. In the mailing archive with recent postings > of this list, I did not find any related topic, but I may have > overseen some posting and would also be grateful for any reference. > > N.B.: [WebDAV] means RFC 2518, [XML] REC-xml-19980210, > [Namespaces] REC-xml-names-19990114, and [HTTP] RFC 2068. > > 1. [WebDAV] section 23.1 (appendix 1), and 12.12.1: > As far as I understand [XML], the declaration > > is not a valid xml element declaration. The use of both, > #PCDATA and children content href implies a mixed content > declaration. For mixed content, [XML] section 3.2.2 defines > [51] Mixed ::= '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*' > | '(' S? '#PCDATA' S? ')'. > Hence, element keepalive may be declared as > > which is a more general form and might need to be further > restricted to its originally intended syntax on the semantic > level of the specification. > > Alternatively, one could specify > > > where element all would effectively replace the '"*"' > PCDATA of the keepalive element. Well, actually this one was caught on July 6, by Ashish Agrawal, http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0004.html It is also listed in the RFC 2518 issues list: http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html But, thanks for suggesting some alternate ways to rewrite the specification of this element! > 2. At a first look, [WebDAV] section 23.1 seems to present the > syntax in the style of a document type declaration as specified > in [XML] section 2.8, rule [28] (doctypedecl definition). > If this is intended, "the Name in the document type declaration > must match the element type of the root element" (cited from > [XML] validity constraint: root element type). Effectively, > this would mean, that there must be an element named webdav-1.0 > which serves as root element. However, I can not find an element > declaration of the form . Instead, > the examples in [WebDAV] seem to use elements propfind, > multistatus, propertyupdate, propertybehaviour, lockinfo and prop > as varying root elements. Hence, could an additional element > declaration such as > propertyupdate | propertybehaviour | lockinfo | prop) > > solve this problem? WebDAV applications are only required to send sequences of well formed XML back and forth, and are not required to adhere to XML validity rules. So, while you're correct that we don't have a top-level container object, this isn't a problem because we don't require validity. > 3. The xml code in the examples in chapter 8 of [WebDAV] should, if I > understand right, be compliant with the syntax specified in > appendix 1. Section 2.8 of [XML] says: > "An XML document is valid if it has an associated document type > declaration and if the document complies with the constraints > expressed in it." > Without supplying a DTD, the document can only be checked for > well-formedness, which does not seem to help very much for > real-life applications. Hence, I would expect the xml code of > the examples in chapter 8 of [WebDAV] to begin as follows or > the like: > > "http://www.w3.org/TR/1999/webdav-1.0.xml"> > According to the root element issue (see above), I would expect then > > followed by the lines as supplied in the examples in chapter 8, > and then followed by > > which terminates the xml code. See, there's that pesky validity acting up again. While validity is useful for sending documents around, where those documents can have widely varying DTDs, in the WebDAV protocol, both ends of the protocol better know both the syntax and semantics of the protocol, otherwise there will be no interoperation. Since there is a finite set of XML elements used within WebDAV, and since both ends of the protocol know them, and the rules for combining them, doing strict XML validity checking doesn't add much. On the other hand, DAV clients and servers are required to make sure that XML elements are nested correctly, and the nesting rules are given prescriptively in the XML DTD language. So, while DAV doesn't require XML validity, it does require elements to be correctly nested. By not requiring validity, we can ignore the parts of XML that don't make sense in a protocol setting like DAV, while keeping those parts that are useful (like nesting hierarchies). > > 4. The response in the example in section 8.1.1 [WebDAV] contains > the line > > As far as I understand, R as an undeclared namespace prefix, > as there is no declared R namespace in scope. The line should > propably read as follows: > > > > Good catch! This is definitely a bug in RFC 2518. I've added it to the issues list. > 5. Section 9.1 of [WebDAV] defines the DAV header as follows: > DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend] > I could not find any syntax rule for extend, neither in > [WebDAV], nor in [HTTP]. If extend may contain a ",", this > may lead to ambigous parsing; e.g. the string "DAV:1,2,3" could > be parsed with "2,3" representing the extend non-terminal. Hence, > if extend has not been defined by now, it should at least be > further restricted, e.g. by requiring extend = token or > extend = quoted-string, with token and quoted-string being > defined in [HTTP]. Good catch! We have, indeed, omitted a definition of the "extend" production. I have added this as well to the issues list. Our intent was to have the production be: extend = token ; token is defined in [HTTP]. > 6. Is there a specific reason for WebDAV not making use of xml > element attributes? I think, using attributes could both, speed > up parsing and simplify the grammar. > For example, elements exclusive and shared could be replaced by > a single enumerated attribute (see [XML] section 3.3.1, rule [57] > EnumeratedType) for element lockscope. Yaron Goland is the main proponent of never using XML attributes, and his rationale is presented here: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0084.html This is one of the "chapters" in the WebDAV Book of Why: http://www.webdav.org/papers/#misc - Jim From w3c-dist-auth-request@w3.org Thu Nov 18 03:27:05 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04031 for ; Thu, 18 Nov 1999 03:27:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA03212; Thu, 18 Nov 1999 03:07:03 -0500 (EST) Resent-Date: Thu, 18 Nov 1999 03:07:03 -0500 (EST) Resent-Message-Id: <199911180807.DAA03212@www19.w3.org> Date: Thu, 18 Nov 1999 00:06:19 -0800 (PST) From: Greg Stein To: Juergen Reuter cc: WebDAV WG , jjh@ira.uka.de In-Reply-To: <"iraun1.ira.486:17.11.99.17.56.42"@ira.uka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Syntax Issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3609 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Wed, 17 Nov 1999, Juergen Reuter wrote: >... > 3. The xml code in the examples in chapter 8 of [WebDAV] should, if I > understand right, be compliant with the syntax specified in > appendix 1. Section 2.8 of [XML] says: > "An XML document is valid if it has an associated document type > declaration and if the document complies with the constraints > expressed in it." > Without supplying a DTD, the document can only be checked for > well-formedness, which does not seem to help very much for > real-life applications. Hence, I would expect the xml code of > the examples in chapter 8 of [WebDAV] to begin as follows or > the like: Wow. I didn't realize that IE5 and Office 2000 were not "real-life applications." After all, they don't check against a DTD. I've been able to implement a DAV server without the "benefit" of a DTD. Works great. Many other people have done servers, too. There aren't so many clients, but they all work very well. All without the benefit of a DTD. The rest of your email was great.... But I had to say something about your supposition. It just isn't true that a DTD is required or even needed. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Nov 18 14:31:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17584 for ; Thu, 18 Nov 1999 14:31:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA16279; Thu, 18 Nov 1999 14:18:02 -0500 (EST) Resent-Date: Thu, 18 Nov 1999 14:18:02 -0500 (EST) Resent-Message-Id: <199911181918.OAA16279@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 18 Nov 1999 11:16:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: Clients using PROPPATCH? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3610 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Another email caught by the spam filter :-( I've put in a request for this email address to be added to the accept2 list, so future emails from David shouldn't get bounced. - Jim -----Original Message----- From: David Engberg [mailto:dave.engberg@driveway.com] Sent: Thursday, November 18, 1999 7:56 AM To: WebDAV WG Subject: [Moderator Action] Clients using PROPPATCH? We are working on a WebDAV server implementation, and have been testing it using MS WebFolders and cadaver, but I haven't seen either of these use 'PROPPATCH' for anything interesting. Does anyone know of a client that makes use of PROPPATCH? From w3c-dist-auth-request@w3.org Thu Nov 18 15:56:47 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27971 for ; Thu, 18 Nov 1999 15:56:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA19466; Thu, 18 Nov 1999 15:47:38 -0500 (EST) Resent-Date: Thu, 18 Nov 1999 15:47:38 -0500 (EST) Resent-Message-Id: <199911182047.PAA19466@www19.w3.org> Date: Thu, 18 Nov 1999 12:47:29 -0800 (PST) From: "Richard C." To: Jim Whitehead cc: WebDAV WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: FW: Clients using PROPPATCH? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3611 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list We are doing a project on WebDAV client program. We are using HTTPClient lib, use ExtensionMethod method, pass "PROPFIND" as param. We have a project home page at: http://www.ics.uci.edu/~posties1 Rich __ ` ` .^o ~\ ` ` ` ` `` ` Y /'~) } _____ ` `` ` ` l/ / / ,-~ ~~--.,_ ` ` `` ` ` ( ( / ~-._ ^. `` ` \ "--'--. "-._ \ ` ` ` ` "-.________ ~--.,__ ^. ` ` ` \"~r-.,___.-'-. ^. ` ` ` YI \\ ~-.\ ` ` ` ` || \\ `\ ` ` || // `Be on your guard; stand ` ` || // firm on the faith; be men ` ` ` () // of courage; be strong. ` ` || // ` ` ` || ( c 1 Corinthians 16:3 ` ___._ __ ___I|__`--__._ __ _ "~ ~ "~ "" ~~" ~ ~~ ICQ: 22864213 http://members.xoom.com/highpitch On Thu, 18 Nov 1999, Jim Whitehead wrote: > Another email caught by the spam filter :-( I've put in a request for this > email address to be added to the accept2 list, so future emails from David > shouldn't get bounced. > > - Jim > > -----Original Message----- > From: David Engberg [mailto:dave.engberg@driveway.com] > Sent: Thursday, November 18, 1999 7:56 AM > To: WebDAV WG > Subject: [Moderator Action] Clients using PROPPATCH? > > > We are working on a WebDAV server implementation, and have been testing it > using MS WebFolders and cadaver, but I haven't seen either of these use > 'PROPPATCH' for anything interesting. > > Does anyone know of a client that makes use of PROPPATCH? > > From w3c-dist-auth-request@w3.org Thu Nov 18 17:17:11 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07469 for ; Thu, 18 Nov 1999 17:17:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA21981; Thu, 18 Nov 1999 17:05:09 -0500 (EST) Resent-Date: Thu, 18 Nov 1999 17:05:09 -0500 (EST) Resent-Message-Id: <199911182205.RAA21981@www19.w3.org> Date: Thu, 18 Nov 1999 13:51:44 -0800 From: Kevin Wiggen In-reply-to: <4.1.19991118095403.00ade220@pop.xs4all.nl> To: Jim Davis Cc: w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Priority: 3 (Normal) Subject: RE: interoperability testing with Xythos/Sharemation server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3612 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Ahh I think this is one for the list.. The problem is not that you sent in two different tokens in the If Header (In fact Xythos does handle multiple ones), the problem is that you mixed No-tag-list w/ Tagged-list, which I believe is not legal. Any other thoughts??? The definition for If Header is If = "If" ":" (1*No-tag-list | 1*Tagged-list) In my mind (and I can be wrong here) this means 1 to many No-tag-lists OR 1 to many tagged lists. Thus what you sent is incorrect. Maybe I should give a better error. You seem to have If = "If" ":" (1*(No-tag-list | Tagged-list)) which I can do, but is not how Xythos read the spec. Thoughts??? Kevin -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Thursday, November 18, 1999 1:01 AM To: Kevin Wiggen Subject: RE: interoperability testing with Xythos/Sharemation server Wowie. Great. One last bug If a resource is locked and the parent is also locked (with a different lock) then must pass both to delete it: PASS Can delete using both tokens: FAIL DELETE /~jrd/foox.html If: () () None In other words, even if I pass both tokens, I still can't delete. (looks like in this case I am passing the token for the collection using tagged-list production and the token for the resource itself using no-tagged list) ps I have not tested authentication in any way with Xythos. pps I hope to test your DASL compliance real soon now. ppps great work. the xythos server is very impressive. From w3c-dist-auth-request@w3.org Thu Nov 18 17:45:30 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19992 for ; Thu, 18 Nov 1999 17:45:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA22645; Thu, 18 Nov 1999 17:35:19 -0500 (EST) Resent-Date: Thu, 18 Nov 1999 17:35:19 -0500 (EST) Resent-Message-Id: <199911182235.RAA22645@www19.w3.org> Date: Thu, 18 Nov 1999 14:34:27 -0800 (PST) From: Greg Stein To: Kevin Wiggen cc: Jim Davis , w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: interoperability testing with Xythos/Sharemation server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3613 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I agree that mixing the request types is incorrect. mod_dav catches the (improper) mixing of the two list types and will return a 400 (Bad Request). [I'm not sure how verbose the response body is, though] In this case, though, the request *is* well-formed. A tagged-list can have multiple lists. In other words, the second list is *also* tagged with the "/~jrd/" URI. Since the second lock token is on /~jrd/foox.html rather than /~jrd/, the request *should* fail. On a separate note: the "locktoken:" URI scheme isn't registered with the IANA, is it? Shouldn't the Xythos server use a registered scheme? Cheers, -g On Thu, 18 Nov 1999, Kevin Wiggen wrote: > > Ahh I think this is one for the list.. > > The problem is not that you sent in two different tokens in the If Header > (In fact Xythos does handle multiple ones), the problem is that you mixed > No-tag-list w/ Tagged-list, which I believe is not legal. Any other > thoughts??? > > The definition for If Header is > > If = "If" ":" (1*No-tag-list | 1*Tagged-list) > > In my mind (and I can be wrong here) this means 1 to many No-tag-lists OR 1 > to many tagged lists. Thus what you sent is incorrect. Maybe I should give > a better error. > > You seem to have > > If = "If" ":" (1*(No-tag-list | Tagged-list)) > > which I can do, but is not how Xythos read the spec. > > Thoughts??? > > Kevin > > -----Original Message----- > From: Jim Davis [mailto:jrd3@alum.mit.edu] > Sent: Thursday, November 18, 1999 1:01 AM > To: Kevin Wiggen > Subject: RE: interoperability testing with Xythos/Sharemation server > > > Wowie. Great. One last bug > > If a resource is locked and the parent is also locked (with a different > lock) then must pass both to delete it: PASS > Can delete using both tokens: FAIL > DELETE /~jrd/foox.html > If: () > () > None > > In other words, even if I pass both tokens, I still can't delete. (looks > like in this case I am passing the token for the collection using > tagged-list production and the token for the resource itself using > no-tagged list) > > ps I have not tested authentication in any way with Xythos. > > pps I hope to test your DASL compliance real soon now. > > ppps great work. the xythos server is very impressive. > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Nov 18 19:03:52 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26289 for ; Thu, 18 Nov 1999 19:03:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA24637; Thu, 18 Nov 1999 18:53:48 -0500 (EST) Resent-Date: Thu, 18 Nov 1999 18:53:48 -0500 (EST) Resent-Message-Id: <199911182353.SAA24637@www19.w3.org> Message-Id: <4.1.19991119005120.00ae13b0@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 19 Nov 1999 00:52:20 +0100 To: WebDAV WG From: Jim Davis Cc: dave.engberg@driveway.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: FW: Clients using PROPPATCH? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3614 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >-----Original Message----- >From: David Engberg [mailto:dave.engberg@driveway.com] >Sent: Thursday, November 18, 1999 7:56 AM >To: WebDAV WG >Subject: [Moderator Action] Clients using PROPPATCH? > > >We are working on a WebDAV server implementation, and have been testing it >using MS WebFolders and cadaver, but I haven't seen either of these use >'PROPPATCH' for anything interesting. > >Does anyone know of a client that makes use of PROPPATCH? The tdav.py client uses PROPPATCH, but only for testing servers. By the way when you get your server up, let me know, and I will test it for compliance. From w3c-dist-auth-request@w3.org Fri Nov 19 13:46:36 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19508 for ; Fri, 19 Nov 1999 13:46:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA17372; Fri, 19 Nov 1999 13:37:46 -0500 (EST) Resent-Date: Fri, 19 Nov 1999 13:37:46 -0500 (EST) Resent-Message-Id: <199911191837.NAA17372@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525682E.006649D2.00@d54mta03.raleigh.ibm.com> Date: Tue, 16 Nov 1999 16:14:46 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3615 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Although WebDAV is silent about dynamic content, it is clear that it will be used to author the source of such content in web application development. In the spirit of incremental development, content authors will want to test and debug their dynamic resource in a tight edit, execute, debug cycle. This implies that extra publish steps required to make authored resources available to the server runtime, and running multiple servers for authoring and testing are less than optimal. Even though specific support for dynamic content is currently out of scope for WebDAV, we should explore the issues and options to be sure there are no protocol consequences or opportunities that should be addressed now. This note is the beginning of a thread to do that. Dynamic content presents two fundamental problems for a WebDAV server: 1. How does the server distinguish between access to source and access to processed results 2. How are resources made available to server-side extensions that access them through the file system We'll explore each of these issues from the point of view of the client, and both non-versioning and versioning servers. Accessing the Source of Dynamic Resources For many dynamic resources, the dynamic content and the source resources are different MIME types and have different URLs. For example Java source resources end in .java while binary executable resources end in .class. These resources present no problem because the client can do a GET on the source URL to get the source, and a GET on the separate executable URL to get the processed results. The DAV:src property on the executable can be used to get the source resource URL. For other resources, the dynamic content and the source have the SAME URL. For example, Java Server Pages, Active Server Pages, server-side includes, server-side scripting, etc. This presents a problem because there's only one method to get both, GET. The DAV:src property doesn't help because it has the same URL as the executable. And, there's no header on GET that can be used to distinguish source from dynamic results. We could use the Accept header to specify what MIME type is desired, and use that to distinguish source from dynamic results, but that might now work either as they could have the same MIME type, and the dynamic resource might support multiple MIME types. The FrontPage extensions resolve this conflict by either using a method extension to get the source, or a new header. Could someone supply the details? They might be a useful model for how we should extend WebDAV. The current WebDAV doesn't provide any interoperable way to resolve this issue. However, advanced collections and binding does. Here is a list of possible solutions (assuming advanced collections), and their pros and cons: 1. Configure the WebDAV server to not process any dynamic content. Require the document author to publish the modified source to another server that is configured to process dynamic content, and not return source (might be another WebDAV server). The publish operation could be done with a cross server COPY. The web application developer uses two different URLs to two different servers to distinguish the source resource from the dynamic resource. A variant of this approach would be to use virtual hosts in a single server, but this is more server dependent. + works with existing WebDAV servers, doesn't even need advanced collections + also solves the second issue, how the runtime gets access to WebDAV resources through the file system - creates redundant resources consuming both developer and CPU time and disk space - results in the potential for stale copies of runtime resources introducing difficult to find bugs - requires an extra publish step after every update that's easy to forget - requires the administration of an extra Web server - user has to remember two URLs, one for the source and one for the dynamic results. However, they could differ only in the server name or port. 2. For every dynamic resource, create a binding from the dynamic resource to its source, and configure the server so that the URL for the source binding does not invoke dynamic content. For example, bind HelloWorld.jsps to HelloWorld.jsp and configure the server so that resources ending in .jsps are text/plain while resources ending in .jsp are processed Java Server Pages. + only need one server running + no duplicate resources + no need to copy, and therefore no possibility of forgetting and getting stale dynamic resources + no publish step, the BIND only has to be done once. - have to do the BIND for each dynamic resource, but only once - have to administer the server to not process some URLs (the ones bound to the dynamic resources for the purpose of accessing their source) - user has to remember two URLs 3. Extend WebDAV to include a Process-Source Boolean header. GET on a URL with Process-Source set to 'F' would return the dynamic content while 'T' would return the source. If the content is not dynamic, the header is effectively ignored as both 'T' and 'F' would have the same effect. + only need one server + no duplicate resources + no copy and no stale dynamic resources + no BIND step or publish + no administration required to distinguish source and dynamic content URLs + user only has to remember one URL - requires an extension/change to WebDAV - introduces another header 4. Add a GETSOURCE method. + no new header required + user only has to remember one URL - another method that usually does the same thing as GET Allowing dynamic resource to access resources using the file system Most dynamic resources, i.e., servlets, Java Server Pages, Active Server Pages, server-side scripting in HTML, CGI-BIN applications, etc. that are invoked by a Web server assume Web resources managed by the server are stored in the file system, often at specific locations relative to their own file system path. This is very unfortunate coupling between the server-side extensions, and the Web server implementation, but it is standard practice. For many WebDAV servers, and almost certainly versioning WebDAV servers, the resources are not stored in the file system, but rather are stored in some private repository. For the authoring environment, this is no problem because the authoring client just does GETs and PUTs and isn't aware of the server's implementation. However, any dynamic content processed by the Web server is free to open files on the server as it wishes, and if those files are Web resources authored through WebDAV, they might not be visible to the dynamic resource and its runtime environment. Ideally, the dynamic resource would reference other resources through a URL so it could access them through WebDAV with versioning support and proper access controls. But in cases where they just open files, we have to have some other solution. 1. Require the user to publish from the WebDAV store to the server runtime. + it works - introduces redundancy with associated system resource consumption and update anomalies. - requires a separate publish step for every update before it can be tested. Likely to cause lots of bugs 2. Mirror the resources in the file system. + makes them accessible to dynamic resources - introduces redundancy with associated system resource consumption and update anomalies. - what version of a versioned resource would be mirrored? Some published workspace? - requires users to do a publish step to control when the server cache is updated or requires servers to keep them up to date. 3. Build a file system device driver on top of WebDAV so that applications that access the file system will transparently access WebDAV resources. + eliminates the redundancy + eliminates the publish step - has performance implications - introduces OS dependencies, there's no standard file system access API. - file system APIs may not be capable of specifying enough information or parameters to support versioning, properties, locking, etc. From w3c-dist-auth-request@w3.org Fri Nov 19 14:17:16 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02595 for ; Fri, 19 Nov 1999 14:17:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA19155; Fri, 19 Nov 1999 14:08:53 -0500 (EST) Resent-Date: Fri, 19 Nov 1999 14:08:53 -0500 (EST) Resent-Message-Id: <199911191908.OAA19155@www19.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14389.41006.887807.396435@gilliam.users.flyingcroc.net> Date: Fri, 19 Nov 1999 11:08:30 -0800 (PST) From: Brett McCormick To: jamsden@us.ibm.com Cc: w3c-dist-auth@w3.org In-Reply-To: <8525682E.006649D2.00@d54mta03.raleigh.ibm.com> References: <8525682E.006649D2.00@d54mta03.raleigh.ibm.com> X-Mailer: VM 6.74 under Emacs 19.34.1 Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3616 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, 16 November 1999, at 16:14:46, jamsden@us.ibm.com wrote: > For many dynamic resources, the dynamic content and the source resources > are different MIME types and have different URLs. For example Java source > resources end in .java while binary executable resources end in .class. > These resources present no problem because the client can do a GET on the > source URL to get the source, and a GET on the separate executable URL to > get the processed results. The DAV:src property on the executable can be > used to get the source resource URL. These would not be examples of dynamic resources. Java source resources are manually compiled into class files. These aren't being generated dynamically. > For other resources, the dynamic content and the source have the SAME URL. > For example, Java Server Pages, Active Server Pages, server-side includes, > server-side scripting, etc. This presents a problem because there's only > one method to get both, GET. The DAV:src property doesn't help because it > has the same URL as the executable. And, there's no header on GET that can > be used to distinguish source from dynamic results. We could use the Accept > header to specify what MIME type is desired, and use that to distinguish > source from dynamic results, but that might now work either as they could > have the same MIME type, and the dynamic resource might support multiple > MIME types. This is normally how dynamic content works. Input file->code->output. Sometimes the input file is the code, sometimes its the output, sometimes its a little bit of both. Or there could be many input files, which is quite likely, or even multiple outputs. What does DAV do with multipart content? > > The FrontPage extensions resolve this conflict by either using a method > extension to get the source, or a new header. Could someone supply the > details? They might be a useful model for how we should extend WebDAV. It sounds shortsighted, as there can be multiple sources. Does the new method get all sources? What about PUTing the source back to server? --brett From w3c-dist-auth-request@w3.org Fri Nov 19 19:48:43 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03291 for ; Fri, 19 Nov 1999 19:48:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA28127; Fri, 19 Nov 1999 19:40:02 -0500 (EST) Resent-Date: Fri, 19 Nov 1999 19:40:02 -0500 (EST) Resent-Message-Id: <199911200040.TAA28127@www19.w3.org> Message-ID: From: "Tapas Nayak (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Fri, 19 Nov 1999 16:39:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Subject: RE: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3617 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > > > Allowing dynamic resource to access resources using the file system > > Most dynamic resources, i.e., servlets, Java Server Pages, > Active Server > Pages, server-side scripting in HTML, CGI-BIN applications, > etc. that are > invoked by a Web server assume Web resources managed by the server are > stored in the file system, often at specific locations > relative to their > own file system path. This is very unfortunate coupling between the > server-side extensions, and the Web server implementation, but it is > standard practice. For many WebDAV servers, and almost > certainly versioning > WebDAV servers, the resources are not stored in the file > system, but rather > are stored in some private repository. For the authoring > environment, this > is no problem because the authoring client just does GETs and PUTs and > isn't aware of the server's implementation. However, any > dynamic content > processed by the Web server is free to open files on the server as it > wishes, and if those files are Web resources authored through > WebDAV, they > might not be visible to the dynamic resource and its runtime > environment. > Ideally, the dynamic resource would reference other resources > through a URL > so it could access them through WebDAV with versioning > support and proper > access controls. But in cases where they just open files, we > have to have > some other solution. > Why do we have to have another way for an application which wants to open files? The application either knows that the resource it is trying to access is a file and that is why it is opening a file or it knows that it is a URL and then would access WebDAV to access the resource. Having a file system interface is good if one is available but one cannot ensure that for all WebDAV servers. If uniformity is the concern here then why not expose file systems as WebDAV instead of exposing WebDAV as file system? > 1. Require the user to publish from the WebDAV store to the > server runtime. > + it works > - introduces redundancy with associated system resource > consumption and > update anomalies. > - requires a separate publish step for every update before it can be > tested. Likely to cause lots of bugs > > 2. Mirror the resources in the file system. > + makes them accessible to dynamic resources > - introduces redundancy with associated system resource > consumption and > update anomalies. > - what version of a versioned resource would be mirrored? > Some published > workspace? > - requires users to do a publish step to control when the > server cache is > updated or requires servers to keep them up to date. > > 3. Build a file system device driver on top of WebDAV so that > applications > that access the file system will transparently access WebDAV > resources. > + eliminates the redundancy > + eliminates the publish step > - has performance implications > - introduces OS dependencies, there's no standard file system > access API. > - file system APIs may not be capable of specifying enough > information or > parameters to support versioning, properties, locking, etc. > > From w3c-dist-auth-request@w3.org Fri Nov 19 20:27:29 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20830 for ; Fri, 19 Nov 1999 20:27:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA28916; Fri, 19 Nov 1999 20:19:27 -0500 (EST) Resent-Date: Fri, 19 Nov 1999 20:19:27 -0500 (EST) Resent-Message-Id: <199911200119.UAA28916@www19.w3.org> Message-ID: <374273481D0CD94C8215359550FC1DFF7698CC@dino.dns.microsoft.com> From: "Sean Lyndersay (Exchange)" To: "'Brett McCormick'" , jamsden@us.ibm.com Cc: w3c-dist-auth@w3.org Date: Fri, 19 Nov 1999 17:18:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Subject: RE: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3618 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Funny you should bring this up. Exchange Server has had to deal with the problem in our implementation and decided to solve it with a new header, "Translate" on GET requests, which takes the values "t" and "f" and defaults to "t" if omitted. As defined, the translate header simply indicates if the Web Server should perform any sort of "translation" on the file -- generally in the form of an interpreter acting on it. For instance, a GET with "translate: f" on a .asp file will return the source of the file (assuming you have permission to access the source), while a "translate: t" (or an omitted translate header) will return the file after processing from the ASP interpreter. So a simple client (like a browser) will get the intended result (the processed page), while a DAV-aware editor can GET the source for editing. The header extends easily into several other scenarios that we come across. It is basically the simplest and most easily implemented solution to what can be a difficult problem. In answer to your concerns about "what if there are multiple sources" -- I'm afraid I don't understand the issue. In situations I'm familiar with, if there are multiple sources then they are "included" in some fashion into the main source file -- which makes them separate files with separate URLs which can be retrieved using the same method. There's no need to get more complex than this. If it was a file system, you wouldn't expect your fopen()/fread() calls to retrieve all included files as well. When our product cycle winds down a bit, we expect to publish this extension as an I-D. Sean Lyndersay Program Manager, WebDAV Microsoft Exchange Server > -----Original Message----- > From: Brett McCormick [mailto:brett@mail.flyingcroc.net] > Sent: Friday, November 19, 1999 11:09 AM > To: jamsden@us.ibm.com > Cc: w3c-dist-auth@w3.org > Subject: Re: WebDAV and Dynamic Content > > > On Tuesday, 16 November 1999, at 16:14:46, jamsden@us.ibm.com wrote: > > > For many dynamic resources, the dynamic content and the > source resources > > are different MIME types and have different URLs. For > example Java source > > resources end in .java while binary executable resources > end in .class. > > These resources present no problem because the client can > do a GET on the > > source URL to get the source, and a GET on the separate > executable URL to > > get the processed results. The DAV:src property on the > executable can be > > used to get the source resource URL. > > These would not be examples of dynamic resources. Java source > resources are manually compiled into class files. These aren't being > generated dynamically. > > > For other resources, the dynamic content and the source > have the SAME URL. > > For example, Java Server Pages, Active Server Pages, > server-side includes, > > server-side scripting, etc. This presents a problem because > there's only > > one method to get both, GET. The DAV:src property doesn't > help because it > > has the same URL as the executable. And, there's no header > on GET that can > > be used to distinguish source from dynamic results. We > could use the Accept > > header to specify what MIME type is desired, and use that > to distinguish > > source from dynamic results, but that might now work either > as they could > > have the same MIME type, and the dynamic resource might > support multiple > > MIME types. > > This is normally how dynamic content works. Input file->code->output. > Sometimes the input file is the code, sometimes its the output, > sometimes its a little bit of both. Or there could be many input > files, which is quite likely, or even multiple outputs. What does DAV > do with multipart content? > > > > > The FrontPage extensions resolve this conflict by either > using a method > > extension to get the source, or a new header. Could someone > supply the > > details? They might be a useful model for how we should > extend WebDAV. > > It sounds shortsighted, as there can be multiple sources. Does the > new method get all sources? What about PUTing the source back to > server? > > --brett > From w3c-dist-auth-request@w3.org Sat Nov 20 01:46:28 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02215 for ; Sat, 20 Nov 1999 01:46:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA02341; Sat, 20 Nov 1999 01:34:46 -0500 (EST) Resent-Date: Sat, 20 Nov 1999 01:34:46 -0500 (EST) Resent-Message-Id: <199911200634.BAA02341@www19.w3.org> To: "Sean Lyndersay (Exchange)" cc: w3c-dist-auth@w3.org In-reply-to: Your message of "Fri, 19 Nov 1999 17:18:10 PST." <374273481D0CD94C8215359550FC1DFF7698CC@dino.dns.microsoft.com> Date: Fri, 19 Nov 1999 22:34:34 -0800 From: "Roy T. Fielding" Message-ID: <199911192234.aa18066@gremlin-relay.ics.uci.edu> Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3619 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Funny you should bring this up. Exchange Server has had to deal with the >problem in our implementation and decided to solve it with a new header, >"Translate" on GET requests, which takes the values "t" and "f" and >defaults to "t" if omitted. Well, congratulations, you chose the worst possible design choice. By using a header field, you have excessively complicated the caching algorithm for all resources on your server. If it isn't sending "Vary: Translate" on every response, your server is not HTTP/1.1 compliant. Next time, use a "source" property that contains a list of URI that make up the sources for a particular resource. Authoring requests are of negligible significance for round-trip latency concerns, so spend the round-trip where it has the least performance impact rather than constipating the normal operation of your server. ....Roy From w3c-dist-auth-request@w3.org Sat Nov 20 02:08:03 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19793 for ; Sat, 20 Nov 1999 02:08:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA02541; Sat, 20 Nov 1999 01:56:54 -0500 (EST) Resent-Date: Sat, 20 Nov 1999 01:56:54 -0500 (EST) Resent-Message-Id: <199911200656.BAA02541@www19.w3.org> To: jamsden@us.ibm.com cc: w3c-dist-auth@w3.org In-reply-to: Your message of "Tue, 16 Nov 1999 16:14:46 EST." <8525682E.006649D2.00@d54mta03.raleigh.ibm.com> Date: Fri, 19 Nov 1999 22:56:40 -0800 From: "Roy T. Fielding" Message-ID: <199911192256.aa18708@gremlin-relay.ics.uci.edu> Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3620 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Dynamic content presents two fundamental problems for a WebDAV server: >1. How does the server distinguish between access to source and access to >processed results Different URI. >2. How are resources made available to server-side extensions that access >them through the file system By authoring the server-side extension configuration (a different URI, or maybe a property of the URI or the immediate collection, but most definitely not part of the WebDAV standard). In most cases this is just automatic based on some characteristic (known to the human author) of the source URI on that particular server's namespace. >... >For other resources, the dynamic content and the source have the SAME URL. That is never true. Do not equate filenames to resources. Every filename in Apache can correspond to many different resources, and many resources have no corresponding filename. The server just maps some imaginary namespace onto the filename space. >The current WebDAV doesn't provide any interoperable way to resolve this >issue. However, advanced collections and binding does. Here is a list of >possible solutions (assuming advanced collections), and their pros and >cons: > >1. Configure the WebDAV server to not process any dynamic content. Require Not an option. >2. For every dynamic resource, create a binding from the dynamic resource >to its source, and configure the server so that the URL for the source >binding does not invoke dynamic content. For example, bind HelloWorld.jsps >to HelloWorld.jsp and configure the server so that resources ending in >.jsps are text/plain while resources ending in .jsp are processed Java >Server Pages. The answer. >+ only need one server running >+ no duplicate resources >+ no need to copy, and therefore no possibility of forgetting and getting >stale dynamic resources >+ no publish step, the BIND only has to be done once. >- have to do the BIND for each dynamic resource, but only once The binding may be implicit based on the server's configuration. The server can tell you what the source URL is after the resource is created (or, more likely, what the normal GET URL is after the source is PUT to its own URL). >- have to administer the server to not process some URLs (the ones bound to >the dynamic resources for the purpose of accessing their source) The server already does that. >- user has to remember two URLs Or do a PROPFIND for the source URLs (there can be many more than one). >3. Extend WebDAV to include a Process-Source Boolean header. GET on a URL >with Process-Source set to 'F' would return the dynamic content while 'T' >would return the source. If the content is not dynamic, the header is >effectively ignored as both 'T' and 'F' would have the same effect. >+ only need one server >+ no duplicate resources >+ no copy and no stale dynamic resources >+ no BIND step or publish >+ no administration required to distinguish source and dynamic content URLs >+ user only has to remember one URL >- requires an extension/change to WebDAV >- introduces another header Absolutely not. It doesn't work for multi-source resources and completely bolloxes caching. >4. Add a GETSOURCE method. >+ no new header required >+ user only has to remember one URL >- another method that usually does the same thing as GET A derived resource (the resource that you are calling dynamic) has by its nature a set of URI that make up its source. It is far more natural, and much easier for the server, to treat a natural property of a resource as a WebDAV property on a WebDAV resource. >Allowing dynamic resource to access resources using the file system This has no relevance to WebDAV, aside from the need for access control to specify whether the user has the right to create resources that include other resources on the server. ....Roy From w3c-dist-auth-request@w3.org Sat Nov 20 02:36:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05590 for ; Sat, 20 Nov 1999 02:36:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA02777; Sat, 20 Nov 1999 02:25:13 -0500 (EST) Resent-Date: Sat, 20 Nov 1999 02:25:13 -0500 (EST) Resent-Message-Id: <199911200725.CAA02777@www19.w3.org> Message-ID: <38364BA9.BE087017@lokitech.com> Date: Sat, 20 Nov 1999 02:20:09 -0500 From: Serge Knystautas X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Roy T. Fielding" CC: jamsden@us.ibm.com, w3c-dist-auth@w3.org References: <199911192256.aa18708@gremlin-relay.ics.uci.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3621 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I'm very interested in better understanding the pros and cons of using the same URI for viewing dynamic content, and editing it's source. For Perl scripts, TCL scripts, JSPs, ASPs, and eventually XML documents using XSLT and more advanced stuff, I would think WebDAV could really benefit from consideration of this usage. Comments below... "Roy T. Fielding" wrote: > >2. How are resources made available to server-side extensions that access > >them through the file system > > By authoring the server-side extension configuration (a different URI, > or maybe a property of the URI or the immediate collection, but most > definitely not part of the WebDAV standard). In most cases this is > just automatic based on some characteristic (known to the human author) > of the source URI on that particular server's namespace. I would prefer to not have to educate each human author (probably frequently different for each web server) to be able to use WebDAV in this context. Surely the software and protocol could realize and indicate when it wants processed content and when it wants source content. > >... > >For other resources, the dynamic content and the source have the SAME URL. > > That is never true. Do not equate filenames to resources. Every filename > in Apache can correspond to many different resources, and many resources > have no corresponding filename. The server just maps some imaginary > namespace onto the filename space. Again, Me see /folder/foo.bar. Me want edit /folder/foo.bar. Why me must edit /folder/foo.bars? > >1. Configure the WebDAV server to not process any dynamic content. Require > > Not an option. Um, could you complete this thought and explain why you do not consider this an adequate option? > >- user has to remember two URLs > > Or do a PROPFIND for the source URLs (there can be many more than one). > I think of a user as a human (who must remember). Then there's the client software that does a PROPFIND. I'm not sure how your comment relates to his point. Could you expand on it? > >3. Extend WebDAV to include a Process-Source Boolean header. GET on a URL > >with Process-Source set to 'F' would return the dynamic content while 'T' > >would return the source. If the content is not dynamic, the header is > >effectively ignored as both 'T' and 'F' would have the same effect. > >+ only need one server > >+ no duplicate resources > >+ no copy and no stale dynamic resources > >+ no BIND step or publish > >+ no administration required to distinguish source and dynamic content URLs > >+ user only has to remember one URL > >- requires an extension/change to WebDAV > >- introduces another header > > Absolutely not. It doesn't work for multi-source resources and completely > bolloxes caching. Well, I need to read up on WebDAV-related caching and multi-source resources, but could you expand on how this doesn't work and how caching is bolloxed up? Serge Knystautas Loki Technologies http://www.lokitech.com From w3c-dist-auth-request@w3.org Sat Nov 20 03:43:58 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05943 for ; Sat, 20 Nov 1999 03:43:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA03328; Sat, 20 Nov 1999 03:32:41 -0500 (EST) Resent-Date: Sat, 20 Nov 1999 03:32:41 -0500 (EST) Resent-Message-Id: <199911200832.DAA03328@www19.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14390.23710.250512.721165@gilliam.users.flyingcroc.net> Date: Sat, 20 Nov 1999 00:32:30 -0800 (PST) From: Brett McCormick To: Serge Knystautas Cc: "Roy T. Fielding" , jamsden@us.ibm.com, w3c-dist-auth@w3.org In-Reply-To: <38364BA9.BE087017@lokitech.com> References: <199911192256.aa18708@gremlin-relay.ics.uci.edu> <38364BA9.BE087017@lokitech.com> X-Mailer: VM 6.74 under Emacs 19.34.1 Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3622 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I'm not exactly sure why we're having this thread, there is an established mechanism for this in the webdav spec. But, in my view: A URI refers to a distinct resource. A URI cannot simultaneously refer to the source and output of a dynamic resource. That's what the source element is for. To say that you should be able to access the source *and* output of a dynamic resource is to say that one uri does not equal another, when that is clearly not true. The source(s) and output are different resources. Therefore, access to them should be via distinct URIs. More comments below... On Saturday, 20 November 1999, at 02:20:09, Serge Knystautas wrote: > I'm very interested in better understanding the pros and cons of using > the same URI for viewing dynamic content, and editing it's source. For > Perl scripts, TCL scripts, JSPs, ASPs, and eventually XML documents > using XSLT and more advanced stuff, I would think WebDAV could really > benefit from consideration of this usage. > > Comments below... > > "Roy T. Fielding" wrote: > > >2. How are resources made available to server-side extensions that access > > >them through the file system > > > > By authoring the server-side extension configuration (a different URI, > > or maybe a property of the URI or the immediate collection, but most > > definitely not part of the WebDAV standard). In most cases this is > > just automatic based on some characteristic (known to the human author) > > of the source URI on that particular server's namespace. > > I would prefer to not have to educate each human author (probably > frequently different for each web server) to be able to use WebDAV in > this context. Surely the software and protocol could realize and > indicate when it wants processed content and when it wants source > content. The education of each author is already required. You have to tell them that what they need to edit is at /foo/bar/baz/, and you can also tell them at the same time that to access the source they should use /source/foo/bar/baz. The client doesn't get to choose if they get processed content or not, they get what they requested: the content of the given URI. > > >... > > >For other resources, the dynamic content and the source have the SAME URL. > > > > That is never true. Do not equate filenames to resources. Every filename > > in Apache can correspond to many different resources, and many resources > > have no corresponding filename. The server just maps some imaginary > > namespace onto the filename space. > > Again, Me see /folder/foo.bar. Me want edit > /folder/foo.bar. Why me must edit /folder/foo.bars? That's why webdav compliant editors/publishers should pay attention to the established mechanism for resolving this problem (?). > > > >1. Configure the WebDAV server to not process any dynamic content. Require > > > > Not an option. > > Um, could you complete this thought and explain why you do not consider > this an adequate option? It's a little hard to sum up. In has to do with the fact that: 1) DAV functionality is often an add-on to existing, functional http servers. 2) the dav implementation more than likely has no control over whether other parts of the http server perform their requested function 3) the dav implementation will also not likely know all the actual source(s) of the dynamic content For instance: I have an apache module which dynamically generates GIF files based on the request URI. How do you suggest adding functionality to DAV (mod_dav, in this case) that would prevent me from returning the dynamic content and instead return the "source" of the dynamic content. I do not know how mod_dav would behave if I tried to PUT to one of the urls, I would hope that it would complain appropriately. I may try this. > > > >- user has to remember two URLs > > > > Or do a PROPFIND for the source URLs (there can be many more than one). > > > > I think of a user as a human (who must remember). Then there's the > client software that does a PROPFIND. I'm not sure how your comment > relates to his point. Could you expand on it? His point is that there is already a way of doing all this, why not use it? > > >3. Extend WebDAV to include a Process-Source Boolean header. GET on a URL > > >with Process-Source set to 'F' would return the dynamic content while 'T' > > >would return the source. If the content is not dynamic, the header is > > >effectively ignored as both 'T' and 'F' would have the same effect. > > >+ only need one server > > >+ no duplicate resources > > >+ no copy and no stale dynamic resources > > >+ no BIND step or publish > > >+ no administration required to distinguish source and dynamic content URLs > > >+ user only has to remember one URL > > >- requires an extension/change to WebDAV > > >- introduces another header > > > > Absolutely not. It doesn't work for multi-source resources and completely > > bolloxes caching. > > Well, I need to read up on WebDAV-related caching and multi-source > resources, but could you expand on how this doesn't work and how caching > is bolloxed up? Ok. You request http://foo.com/bar/. Your browser is configured to use a proxy, so it requests it. You then attempt to publish to this url. Your DAV client also makes a GET request to the same URI, except this time attaching the appropriate proprietary header. The proxy has no idea what that header means, and of course returns the cached dynamic content of the URI, which you edit and accidentally publish to the source. It all comes down to the fact that you can't use one URI to refer to two separate resources. --brett From w3c-dist-auth-request@w3.org Sat Nov 20 13:07:40 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14112 for ; Sat, 20 Nov 1999 13:07:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA08076; Sat, 20 Nov 1999 12:56:41 -0500 (EST) Resent-Date: Sat, 20 Nov 1999 12:56:41 -0500 (EST) Resent-Message-Id: <199911201756.MAA08076@www19.w3.org> Date: Sat, 20 Nov 1999 12:56:29 -0500 Message-Id: <9911201756.AA07125@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (tapasnay@Exchange.Microsoft.com) Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3623 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: "Tapas Nayak (Exchange)" > Allowing dynamic resource to access resources using the file system: > 1. Require the user to publish from the WebDAV store to the > file system. > 2. Automatically mirror the resources in the file system. > 3. Build a file system device driver on top of WebDAV. Why do we have to have another way for an application which wants to open files? The application either knows that the resource it is trying to access is a file and that is why it is opening a file or it knows that it is a URL and then would access WebDAV to access the resource. Having a file system interface is good if one is available but one cannot ensure that for all WebDAV servers. If uniformity is the concern here then why not expose file systems as WebDAV instead of exposing WebDAV as file system? Jim is concerned about the case where an application (i.e. the one producing the dynamic content) only knows about files (not resources and URL's). The web server invokes the application to produce the dynamic content, but the application will be looking into the file system to find its input data. He's looking for standardizing a way for a client to tell the server to instantiate a set of resources into the file system so that they are accessible to the file-based tool. This feels to me like something that is outside of the scope of an HTTP protocol, since this is so application implementation dependent. In particular, it depends both on the file system mappings that are expected by the applications, and on how resources are instantiated in the file system. So if we do decide to formalize authoring of resources with dynamic content, I'm more inclined to do so in a pure resource context, and not try to fold in file-based behavior. Cheers, Geoff -- Geoffrey M. Clemm Chief Engineer, Configuration Management Business Unit Rational Software Corporation (781) 676-2684 geoffrey.clemm@rational.com http://www.rational.com From w3c-dist-auth-request@w3.org Sun Nov 21 11:35:46 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04624 for ; Sun, 21 Nov 1999 11:35:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA18932; Sun, 21 Nov 1999 11:26:26 -0500 (EST) Resent-Date: Sun, 21 Nov 1999 11:26:26 -0500 (EST) Resent-Message-Id: <199911211626.LAA18932@www19.w3.org> Message-Id: <4.1.19991121160439.00af07d0@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 21 Nov 1999 16:15:46 +0100 To: w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: <38364BA9.BE087017@lokitech.com> References: <199911192256.aa18708@gremlin-relay.ics.uci.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3624 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 02:20 AM 11/20/99 -0500, Serge Knystautas wrote: Serge, I take the point of your remarks to be that, all things being equal, you would prefer a definition of the protocol such that it is very easy to use, so that even "gorillas" (as in your example) can use it. I guess we all would, but it seems to not be possible. I regret that I do not see any way to make WebDAV that simple. As Einstein said "Everything should be made as simple as possible, but not more so". There is an understandable temptation to hope (or at least wish) that somehow the software agent or server can be make smart enough to "guess" whether a URL is being used to refer to the "source" of dynamic resource or the result of executing it. But I do not think this is possible. Others have proposed adding a proprietary header that controls the processing. But as Roy as explained, this is a bad approach. Really the simplest thing is to use two distinct URLs for two objects. If you don't find Roy's explaination (and Brett's elaboration) sufficient, I will try myself to make the case. But perhaps you (and others) are now convinced? By the way have you been tracking the design discussions around the BIND method? As for Exchange, it's really too bad that you guys made the choice you did without raising it in this forum first. you could have gotten a lot of good advice for a very low price. Well, I suppose it's too late to change Exchange's behavior. I just hope no one decided to follow their example. From w3c-dist-auth-request@w3.org Sun Nov 21 14:45:14 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23340 for ; Sun, 21 Nov 1999 14:45:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA20959; Sun, 21 Nov 1999 14:35:24 -0500 (EST) Resent-Date: Sun, 21 Nov 1999 14:35:24 -0500 (EST) Resent-Message-Id: <199911211935.OAA20959@www19.w3.org> Message-ID: <38384814.4B7E79D2@lokitech.com> Date: Sun, 21 Nov 1999 14:29:24 -0500 From: Serge Knystautas X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Davis CC: w3c-dist-auth@w3.org References: <199911192256.aa18708@gremlin-relay.ics.uci.edu> <4.1.19991121160439.00af07d0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3625 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Jim, You're right that I would like a gorilla to be able to edit these resources. :) I think fundamentally that if the WebDAV group decides to only support editing static resources and not dynamic resources, it will be a limited protocol. Roy and Brett raised some of the technical challenges, but I believe the challenges are just that... challenges, and not unconquerable obstacles. Comments below... Jim Davis wrote: > There is an understandable temptation to hope (or at least wish) that > somehow the software agent or server can be make smart enough to "guess" > whether a URL is being used to refer to the "source" of dynamic resource or > the result of executing it. But I do not think this is possible. Ok, I'm making the assumption that a client using WebDAV to retrieve a resource could be knowledgeable enough to request either the source or processed version of the code (because of added functionality in the WebDAV protocol). For static content, this would be the same. The client could therefore know not to let a user edit the processed results and store those back over the source code. I'm suggesting we add something to WebDAV to make it aware of the difference between processed and source, and NOT force clients guess. > Others have proposed adding a proprietary header that controls the > processing. But as Roy as explained, this is a bad approach. This is probably using your words other than how you meant them, so I apologize in advance. To me proprietary header means an individual or organization owns/invents/only they use that header. To which I would respond that if the WebDAV group added a specific header to control processing, it would no longer be proprietary. > If you don't find Roy's explaination (and Brett's elaboration) sufficient, > I will try myself to make the case. But perhaps you (and others) are now > convinced? Well, you can probably guess I'm not convinced. I'm just hoping to point out to the group is that this is very, very useful functionality, and I consider it short-sighted to limit WebDAV to only support static resources, especially with the proliferation of server scripting languages where code is embedded within content (typically HTML). The WebDAV group can decide they do not wish to support dynamic content (as it seems to have already been decided). To that I'll add that I think vendors implementing WebDAV (such as Microsoft and others as WebDAV grows in acceptance) will end up supplying this functionality outside of the WebDAV standard if the standard will not grow to support it. This will lead to proprietary headers, or other short-sighted and limited ways of doing this (that Roy and Brett and you and many others will be able to point out the flaws to). I think it's in WebDAV's best interest to put it's bright minds towards this problem rather than deciding "not my problem" or "we don't support that." I hope I haven't ruffled too many feathers. I'm normally just a lurker here and will shortly return to that. Again, I think this is needed functionality, and if we don't figure out how to support it, others will, and you'll get splintered efforts with poorly implemented approaches. Serge Knystautas Loki Technologies http://www.lokitech.com From w3c-dist-auth-request@w3.org Sun Nov 21 18:23:33 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16321 for ; Sun, 21 Nov 1999 18:23:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA22917; Sun, 21 Nov 1999 18:15:21 -0500 (EST) Resent-Date: Sun, 21 Nov 1999 18:15:21 -0500 (EST) Resent-Message-Id: <199911212315.SAA22917@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Serge Knystautas cc: w3c-dist-auth@w3.org Message-ID: <85256830.007FB3C7.00@D51MTA03.pok.ibm.com> Date: Sun, 21 Nov 1999 18:15:17 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3626 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list You're right that I would like a gorilla to be able to edit these resources. :) I think fundamentally that if the WebDAV group decides to only support editing static resources and not dynamic resources, it will be a limited protocol. Roy and Brett raised some of the technical challenges, but I believe the challenges are just that... challenges, and not unconquerable obstacles. Serge. I think we all want to see WebDAV support dynamic resources. And I think a few folks would say we already do. I don't quite agree. I think we haven't really flushed them out well enough to be fully interoperabile. But I and I believe a few others believe that there are only a few more improvements we can make before we start getting to the "harder" parts to spec out carefully. Right now most of the movers and shakers on the list are pretty tied up on other parts of WebDAV and their jobs. They can't take on another task without sacreficing something(s) else. And although dynamic resources aren't defined as fully as they should, I don't think we've defined anything in regard to them that will prevent us from defining them more completely later. That being said anyone is free to clarify the behavior of dynamic resources. You included. Whoever(s) does it should read up on the history of them on the mailing list. That should provide an understanding why a source property is used. I can also provide a document/email I started to write that might provide a framework for looking at clarifying, classifying, discussing and understanding dynamic resources. I don't have the time to follow through with this or even track it myself though. Just one last meta'ish comment. I think the folks that settled on the source property felt that a gorilla client *would* be able to use them as defined. They aren't conceptually complicated. I agree. But I think some clarification will also be needed before they can pass the gorilla test. And unless someone investigating dynamic resources finds something in the base spec that is likely to negatively impact the spec'ing of dynamic resources, I wouldn't hold up the base WebDAV spec for this. I'd make it a follow-up proposal that builds/clarifies the base WebDAV spec. This is both to insure that the main spec gets out in a timely fashion... and to make the main WebDAV spec less intimidating. We've already done this for several other issues. J. From w3c-dist-auth-request@w3.org Sun Nov 21 21:57:01 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04875 for ; Sun, 21 Nov 1999 21:57:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA25319; Sun, 21 Nov 1999 21:48:25 -0500 (EST) Resent-Date: Sun, 21 Nov 1999 21:48:25 -0500 (EST) Resent-Message-Id: <199911220248.VAA25319@www19.w3.org> Message-ID: <3838AD85.AC19D066@lokitech.com> Date: Sun, 21 Nov 1999 21:42:13 -0500 From: Serge Knystautas X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett McCormick CC: ccjason@us.ibm.com, w3c-dist-auth@w3.org References: <85256830.007FB3C7.00@D51MTA03.pok.ibm.com> <14392.41409.765915.273192@gilliam.users.flyingcroc.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3627 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Brett McCormick wrote: > I guess I haven't heard any reasons why the current scheme wouldn't > satisfy your requirements in a fully interoperable way. I've only heard that you need different URIs to edit source. If there is a way to do what I was talking about, then that's great. > I feel strongly that the webdav spec should not provide a facility for > obtaining the source content using the actual uri of the output > resource. I feel that this extra mechanism is non interoperable. The > DAV server may not even be able to fufill the request for the > unprocessed source, and the client must then fall back to the existing > mechanism. If the DAV server cannot fulfill the request, then it wouldn't be qualify as "WebDAV class XXX compliant." If someone is running an older WebDAV implementation, they could support editing source the way you talked about it. I don't think that should restrict us from defining new functionality in a new version of WebDAV. > It isn't functionality that is extensible enough for our needs > (assumes one source document) nor can it be uniformly provided across > DAV server implementations. I think we should worry about how to grow the spec to handle the needs of users and admins, and then separately worry about how to implement the spec as a vendor (either open source or proprietary). HTTP/1.0 had very limited caching capabilities, and even though most proxy servers would have to be rewritten to support more advanced caching, the W3C still defined more advanced caching in HTTP/1.1. But rather than belabor my argument ad naseum, I'd like to suggest two alternatives (that were already raised I believe): 1. GETSOURCE request method This approach suggests using GETSOURCE to retrieve the source for a URI. As a different HTTP request method, I would think that even older proxies might just pass this through. This doesn't address how you would ensure a lock or a put (or anything else) isn't sending/locking the processed content. You would need to indicate somehow that the client is aware it is working with source code vs. processed code in these other methods. 2. New header in the request (and response) This approach suggests using an additional header to the request that indicates the client wants to work "at the source version" resource. The server could return this header (or a directly related one) to indicate that the client is receiving/working with a source version of the URI. (the lack of this header would indicate it is a processed version, or the server does not support editing source this way). This header could be passed with all necessary requests, and ensure the source is not overwritten with processed content. Apparently there are problems with the proxy when relying on headers, but I think that if the client expected an appropriate header in response, it could see that a proxy was returning the processed version instead of the source version and deal accordingly. This (I believe) is similar to how keep alive connections work... the server has to return an appropriate header, so both client and server know that the other is compliant with this new functionality. Other alternatives might be to add parameters in the XML that is passed back and forth, but I think most of the difficulty surrounds the actual content retrieval request, which is something that (I don't think) involves XML meta data. Serge Knystautas Loki Technologies http://www.lokitech.com From w3c-dist-auth-request@w3.org Sun Nov 21 22:24:01 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17481 for ; Sun, 21 Nov 1999 22:24:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA25620; Sun, 21 Nov 1999 22:15:36 -0500 (EST) Resent-Date: Sun, 21 Nov 1999 22:15:36 -0500 (EST) Resent-Message-Id: <199911220315.WAA25620@www19.w3.org> To: Serge Knystautas cc: w3c-dist-auth@w3.org In-reply-to: Your message of "Sun, 21 Nov 1999 14:29:24 EST." <38384814.4B7E79D2@lokitech.com> Date: Sun, 21 Nov 1999 19:15:24 -0800 From: "Roy T. Fielding" Message-ID: <199911211915.aa06909@gremlin-relay.ics.uci.edu> Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3628 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >You're right that I would like a gorilla to be able to edit these >resources. :) I think fundamentally that if the WebDAV group decides >to only support editing static resources and not dynamic resources, it >will be a limited protocol. Roy and Brett raised some of the technical >challenges, but I believe the challenges are just that... challenges, >and not unconquerable obstacles. I think you are missing the point. There are no challenges in what I described, just choices -- the ability to edit dynamic resources is already present in the protocol. The challenge you are describing is how to represent the protocol actions to the user, which I just don't think is relevant. A "smart" client can represent the protocol actions however it wants, including as if the client were "editing" the dynamic resource, but this does not change the protocol one bit. The protocol must perform operations on static content because that is the only way it can be done. You don't edit the output of a C program; you edit the static content of the code that becomes that program. One way or another, the client must be informed that the content via GET is from a derived source and thus must be edited at the source(s). But what the client sees and the user sees are two entirely different concepts. A smart client will understand the meaning of a "you can't edit me, go over there to my source" response and present it to the user in such a way that an author will understand. If they don't understand it, then they really aren't the author of that resource and the right thing to do is to tell them to piss off rather than mistakenly replace a derived resource with the wrong content. >Ok, I'm making the assumption that a client using WebDAV to retrieve a >resource could be knowledgeable enough to request either the source or >processed version of the code (because of added functionality in the >WebDAV protocol). For static content, this would be the same. The >client could therefore know not to let a user edit the processed results >and store those back over the source code. I'm suggesting we add >something to WebDAV to make it aware of the difference between processed >and source, and NOT force clients guess. That is already present in the protocol, as the source property. The reason that the source isn't advertized as a external link on every GET response is because some people don't like to publish how their resources are generated, and it doesn't make an efficient tradeoff given that a typical resource is going to be GET'd millions of more times than it will be PUT. >Well, you can probably guess I'm not convinced. I'm just hoping to >point out to the group is that this is very, very useful functionality, >and I consider it short-sighted to limit WebDAV to only support static >resources, especially with the proliferation of server scripting >languages where code is embedded within content (typically HTML). The >WebDAV group can decide they do not wish to support dynamic content (as >it seems to have already been decided). To that I'll add that I think >vendors implementing WebDAV (such as Microsoft and others as WebDAV >grows in acceptance) will end up supplying this functionality outside of >the WebDAV standard if the standard will not grow to support it. This >will lead to proprietary headers, or other short-sighted and limited >ways of doing this (that Roy and Brett and you and many others will be >able to point out the flaws to). I think it's in WebDAV's best interest >to put it's bright minds towards this problem rather than deciding "not >my problem" or "we don't support that." You can rest assured that WebDAV would not have been published as an RFC if I had even the slightest belief that it didn't support the authoring of all types of resources present on the Web today, either within the main draft or as part of collections. You just have to remember that a resource does not always map to a singular file, but all resources that are not static are derived from some other resources, and by following the derivation tree you will eventually find all of the static things that must be edited in order to modify the content of a resource. A server cannot "abstract away" those actions because the server doesn't know what the user is trying to do. Assuming that the user is just a dumb browser-editor would eliminate the ability of the Web to support more sophisticated clients, thus artificially restricting the variety of Web applications. A user agent, on the other hand, knows its own intended purpose (e.g., web editor, file editor, folder manager, maintenance spider, etc.) and is capable of presenting the raw WebDAV protocol actions in a way that can be understood by its own user, at whatever level of sophistication you deem appropriate. The same principles that apply to dynamic content also apply equally to content negotiation, scripts, servlets, configurations, versioning, etc. This is why the Web works. ....Roy From w3c-dist-auth-request@w3.org Sun Nov 21 23:42:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20764 for ; Sun, 21 Nov 1999 23:42:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA26235; Sun, 21 Nov 1999 23:32:12 -0500 (EST) Resent-Date: Sun, 21 Nov 1999 23:32:12 -0500 (EST) Resent-Message-Id: <199911220432.XAA26235@www19.w3.org> Message-ID: <3838C5DA.EFF56F11@lokitech.com> Date: Sun, 21 Nov 1999 23:26:02 -0500 From: Serge Knystautas X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Roy T. Fielding" CC: w3c-dist-auth@w3.org References: <199911211915.aa06909@gremlin-relay.ics.uci.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3629 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit "Roy T. Fielding" wrote: > That is already present in the protocol, as the source property. > The reason that the source isn't advertized as a external link on every > GET response is because some people don't like to publish how their > resources are generated, and it doesn't make an efficient tradeoff given > that a typical resource is going to be GET'd millions of more times > than it will be PUT. Thanks for the tip (and for your patience). I will look into the source property. Do most client/servers implement this, or is this relatively unsupported right now (is this class 1 or class 2 feature, if that question makes sense)? Serge Knystautas Loki Technologies http://www.lokitech.com From w3c-dist-auth-request@w3.org Mon Nov 22 00:50:56 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21707 for ; Mon, 22 Nov 1999 00:50:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA26915; Mon, 22 Nov 1999 00:40:39 -0500 (EST) Resent-Date: Mon, 22 Nov 1999 00:40:39 -0500 (EST) Resent-Message-Id: <199911220540.AAA26915@www19.w3.org> Date: Sun, 21 Nov 1999 21:40:17 -0800 (PST) From: Greg Stein To: Serge Knystautas cc: w3c-dist-auth@w3.org In-Reply-To: <3838C5DA.EFF56F11@lokitech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3630 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Sun, 21 Nov 1999, Serge Knystautas wrote: > "Roy T. Fielding" wrote: > > That is already present in the protocol, as the source property. > > The reason that the source isn't advertized as a external link on every > > GET response is because some people don't like to publish how their > > resources are generated, and it doesn't make an efficient tradeoff given > > that a typical resource is going to be GET'd millions of more times > > than it will be PUT. > > Thanks for the tip (and for your patience). I will look into the source > property. Do most client/servers implement this, or is this relatively > unsupported right now (is this class 1 or class 2 feature, if that > question makes sense)? mod_dav supports it as a "dead" property and depends on the server admin to set up the appropriate structures on the server. Some future version of mod_dav (sooner or later... I dunno) will support a directive to automatically set up DAV:source properites, aliases, and content-type settings. I posted a note a couple days ago about how mod_dav might handle the property. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 22 14:20:02 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04112 for ; Mon, 22 Nov 1999 14:20:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA22987; Mon, 22 Nov 1999 13:59:34 -0500 (EST) Resent-Date: Mon, 22 Nov 1999 13:59:34 -0500 (EST) Resent-Message-Id: <199911221859.NAA22987@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 22 Nov 1999 10:57:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Re: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3631 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've send in a request to have Brett's email address added to the accept2 list for the WebDAV mailing list. - Jim -----Original Message----- From: Brett McCormick [mailto:brett@sextracker.com] Sent: Sunday, November 21, 1999 5:52 PM To: ccjason@us.ibm.com Cc: Serge Knystautas; w3c-dist-auth@w3.org Subject: [Moderator Action] Re: WebDAV and Dynamic Content On Sunday, 21 November 1999, at 18:15:17, ccjason@us.ibm.com wrote: > Serge. I think we all want to see WebDAV support dynamic resources. > And I think a few folks would say we already do. I don't quite agree. > I think we haven't really flushed them out well enough to be > fully interoperabile. I guess I haven't heard any reasons why the current scheme wouldn't satisfy your requirements in a fully interoperable way. I feel strongly that the webdav spec should not provide a facility for obtaining the source content using the actual uri of the output resource. I feel that this extra mechanism is non interoperable. The DAV server may not even be able to fufill the request for the unprocessed source, and the client must then fall back to the existing mechanism. It isn't functionality that is extensible enough for our needs (assumes one source document) nor can it be uniformly provided across DAV server implementations. --brett From w3c-dist-auth-request@w3.org Mon Nov 22 23:49:32 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16414 for ; Mon, 22 Nov 1999 23:49:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA12851; Mon, 22 Nov 1999 23:37:53 -0500 (EST) Resent-Date: Mon, 22 Nov 1999 23:37:53 -0500 (EST) Resent-Message-Id: <199911230437.XAA12851@www19.w3.org> Message-ID: <374273481D0CD94C8215359550FC1DFF75C881@dino.dns.microsoft.com> From: "Sean Lyndersay (Exchange)" To: w3c-dist-auth@w3.org Date: Mon, 22 Nov 1999 16:33:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Subject: RE: WebDAV and Dynamic Content Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3632 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Believe it or not, caching was considered when deciding on this implementation. Bascially, we do not allow public caching of dynamic data. To this end, we place a "Cache-control: private" header on responses from dynamic resources. Since most of the resources in the Exchange WebStore require authentication to access, this doesn't make much difference -- we wouldn't want a public cache caching it anyway. An application that does use the translate header will be able to cache intelligently. This is approximately analogous to the way that an application that uses one of the Accept headers must cache carefully with respect to that header, but may ignore the others. An application (like a browser) that is unaware of the translate header will not have any need to worry about it since it will only ever see the one view of it. Our concerns with the DAV:source property are basically administrative ones. Since we, by design, have no differentiation between our URI namespace and the contents of the store (i.e. a one-to-one mapping between URIs and items in the store), this makes it extremely tricky to design an automatic mechanism whereby each dynamic resource has a corresponding source resource. In an environment where one desires to give as much freedom as possible to the Administrator, it is difficult to mandate that the administrator must essentially reserve some namespace (be it an additional virtual server, or special URIs for each resource) for accessing source files. Sean -----Original Message----- From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU] Sent: Friday, November 19, 1999 10:35 PM To: Sean Lyndersay (Exchange) Cc: w3c-dist-auth@w3.org Subject: Re: WebDAV and Dynamic Content >Funny you should bring this up. Exchange Server has had to deal with the >problem in our implementation and decided to solve it with a new header, >"Translate" on GET requests, which takes the values "t" and "f" and >defaults to "t" if omitted. Well, congratulations, you chose the worst possible design choice. By using a header field, you have excessively complicated the caching algorithm for all resources on your server. If it isn't sending "Vary: Translate" on every response, your server is not HTTP/1.1 compliant. Next time, use a "source" property that contains a list of URI that make up the sources for a particular resource. Authoring requests are of negligible significance for round-trip latency concerns, so spend the round-trip where it has the least performance impact rather than constipating the normal operation of your server. ....Roy From w3c-dist-auth-request@w3.org Tue Nov 23 03:56:05 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02451 for ; Tue, 23 Nov 1999 03:56:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA16869; Tue, 23 Nov 1999 03:39:17 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 03:39:17 -0500 (EST) Resent-Message-Id: <199911230839.DAA16869@www19.w3.org> Date: Tue, 23 Nov 1999 00:39:12 -0800 (PST) From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: LOCK request body? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3633 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Section 8.10.1 states that a LOCK request "SHOULD" have a request body. However, it does not state what the server should use as a default if the client does not supply a body. What should a server do? Create a lock of its own choosing? The text does state "unless this is a refresh request", but the parsing of the sentence is not entirely clear. I believe the intent is probably that it MUST have a body for asserting a lock, and that it MUST NOT have a body for refreshing a lock. On a slightly different topic: why is a refresh done using locktokens gathered from the If: header, rather than the more obvious Lock-Token: header? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Nov 23 12:42:15 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26304 for ; Tue, 23 Nov 1999 12:42:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA07546; Tue, 23 Nov 1999 12:26:08 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 12:26:08 -0500 (EST) Resent-Message-Id: <199911231726.MAA07546@www19.w3.org> Date: Tue, 23 Nov 1999 09:18:00 -0800 From: Kevin Wiggen In-reply-to: To: Greg Stein , w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Priority: 3 (Normal) Subject: RE: LOCK request body? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3634 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I agree with Greg. The wording from 8.10.1 should be a "MUST". Currently the Xythos Storage Server will give an error back if no body is sent. We make no assumptions about what the client desires and thus simply fail it. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein Sent: Tuesday, November 23, 1999 12:39 AM To: w3c-dist-auth@w3.org Subject: LOCK request body? Section 8.10.1 states that a LOCK request "SHOULD" have a request body. However, it does not state what the server should use as a default if the client does not supply a body. What should a server do? Create a lock of its own choosing? The text does state "unless this is a refresh request", but the parsing of the sentence is not entirely clear. I believe the intent is probably that it MUST have a body for asserting a lock, and that it MUST NOT have a body for refreshing a lock. On a slightly different topic: why is a refresh done using locktokens gathered from the If: header, rather than the more obvious Lock-Token: header? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Nov 23 13:54:32 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04127 for ; Tue, 23 Nov 1999 13:54:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10910; Tue, 23 Nov 1999 13:39:31 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 13:39:31 -0500 (EST) Resent-Message-Id: <199911231839.NAA10910@www19.w3.org> Date: Tue, 23 Nov 1999 10:35:03 -0800 From: Kevin Wiggen To: jrd3@alum.mit.edu, w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/alternative; boundary="----=_NextPart_000_0000_01BF359E.66AECD60" Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Priority: 3 (Normal) Subject: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3635 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BF359E.66AECD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jim Davis and I are having a discussion on what the appropriate behavior of a write lock on a collection should be. Re 7.5 A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. What does this mean when a collection is locked via a Depth 0 lock: 1) When a new resource is added to the collection, the resource is added without a lock as the parent has only a Depth 0 lock. 2) When a new resource is added to the collection, the resource is added and inherits the lock from above (via the second paragraph above) I will keep my ideas off this post (as this will just be the question), but will send a follow up with my ideas. Thanks, Kevin ------=_NextPart_000_0000_01BF359E.66AECD60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jim = Davis and I are=20 having a discussion on what the appropriate behavior of a write lock on = a=20 collection should be. 
 

Re 7.5

A write lock on a collection, whether = created by a=20 "Depth: 0" or "Depth: infinity" = lock=20 request, prevents the addition or removal of=20 member URIs of the collection by non-lock owners.

If a lock owner causes the URI of a = resource to be=20 added as an internal member URI = of a=20 locked collection then the new resource MUST=20 be automatically added to the lock.

What = does this mean=20 when a collection is locked via a Depth 0 lock:

1)  = When a new=20 resource is added to the collection, the resource is added without a = lock as the=20 parent has only a Depth 0 lock.

2)  = When a new=20 resource is added to the collection, the resource is added and inherits = the lock=20 from above (via the second paragraph above)

I will = keep my ideas=20 off this post (as this will just be the question), but will send a = follow up=20 with my ideas. 

Thanks,

Kevin

------=_NextPart_000_0000_01BF359E.66AECD60-- From w3c-dist-auth-request@w3.org Tue Nov 23 16:33:21 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27021 for ; Tue, 23 Nov 1999 16:33:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA20049; Tue, 23 Nov 1999 16:20:07 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 16:20:07 -0500 (EST) Resent-Message-Id: <199911232120.QAA20049@www19.w3.org> Date: Tue, 23 Nov 1999 16:19:42 -0500 Message-Id: <9911232119.AA08625@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (message from Kevin Wiggen on Tue, 23 Nov 1999 10:35:03 -0800) Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3636 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: Kevin Wiggen Jim Davis and I are having a discussion on what the appropriate behavior of a write lock on a collection should be. Re 7.5 A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. I believe it says "internal member". If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. I believe this statement should only apply to non-Depth:0 locks. Otherwise, this results in the inability to independently lock a collection and members of the collection. This should be clarified/fixed in the next draft of 2518. What does this mean when a collection is locked via a Depth 0 lock: 1) When a new resource is added to the collection, the resource is added without a lock as the parent has only a Depth 0 lock. That's what I believe it should mean. 2) When a new resource is added to the collection, the resource is added and inherits the lock from above (via the second paragraph above) That would be a very bad thing, if the collection lock is depth:0. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Nov 23 17:13:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18038 for ; Tue, 23 Nov 1999 17:13:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21461; Tue, 23 Nov 1999 16:42:18 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 16:42:18 -0500 (EST) Resent-Message-Id: <199911232142.QAA21461@www19.w3.org> Date: Tue, 23 Nov 1999 13:41:32 -0800 (PST) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <9911232119.AA08625@tantalum> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3637 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Tue, 23 Nov 1999, Geoffrey M. Clemm wrote: > From: Kevin Wiggen >... > Re 7.5 > > A write lock on a collection, whether created by a "Depth: 0" or "Depth: > infinity" lock request, prevents the addition or removal of member URIs of > the collection by non-lock owners. > > I believe it says "internal member". Nope. It just says "member". > If a lock owner causes the URI of a resource to be added as an internal > member URI of a locked collection then the new resource MUST be > automatically added to the lock. > > I believe this statement should only apply to non-Depth:0 locks. > Otherwise, this results in the inability to independently lock > a collection and members of the collection. This should be clarified/fixed > in the next draft of 2518. I completely agree. > What does this mean when a collection is locked via a Depth 0 lock: > > 1) When a new resource is added to the collection, the resource is added > without a lock as the parent has only a Depth 0 lock. > > That's what I believe it should mean. Same here. mod_dav implements collection locks this way. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Nov 23 17:40:21 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01293 for ; Tue, 23 Nov 1999 17:40:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA24351; Tue, 23 Nov 1999 17:28:38 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 17:28:38 -0500 (EST) Resent-Message-Id: <199911232228.RAA24351@www19.w3.org> Message-Id: <4.1.19991123232148.00b0b440@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 23 Nov 1999 23:26:13 +0100 To: w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: <9911232119.AA08625@tantalum> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3638 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 04:19 PM 11/23/99 -0500, Geoffrey M. Clemm wrote: > > From: Kevin Wiggen > > Re 7.5 > > A write lock on a collection, whether created by a "Depth: 0" or "Depth: > infinity" lock request, prevents the addition or removal of member URIs of > the collection by non-lock owners. > If a lock owner causes the URI of a resource to be added as an internal > member URI of a locked collection then the new resource MUST be > automatically added to the lock. > >I believe this statement should only apply to non-Depth:0 locks. Why do you believe this? >Otherwise, this results in the inability to independently lock >a collection and members of the collection. How so? please provide a sequence of operations that would be impossible under this interpretation. > > What does this mean when a collection is locked via a Depth 0 lock: > > 1) When a new resource is added to the collection, the resource is added > without a lock as the parent has only a Depth 0 lock. > >That's what I believe it should mean. > > 2) When a new resource is added to the collection, the resource is added > and inherits the lock from above (via the second paragraph above) > >That would be a very bad thing, if the collection lock is depth:0. Why would it be bad? What bad thing would occur, or what good thing would be prevented? sorry, but I just can't invent one my self. best regards Jim From w3c-dist-auth-request@w3.org Tue Nov 23 18:36:02 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27775 for ; Tue, 23 Nov 1999 18:36:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA26326; Tue, 23 Nov 1999 18:24:34 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 18:24:34 -0500 (EST) Resent-Message-Id: <199911232324.SAA26326@www19.w3.org> Date: Tue, 23 Nov 1999 15:20:30 -0800 From: Kevin Wiggen In-reply-to: To: w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/alternative; boundary="----=_NextPart_000_0037_01BF35C6.4737CFE0" Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Priority: 3 (Normal) Subject: RE: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3639 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0037_01BF35C6.4737CFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Xythos will currently only add a resource to a collection lock if its depth is infinity. Depth 0 locks will always only be on one resource. Kevin Jim Davis and I are having a discussion on what the appropriate behavior of a write lock on a collection should be. Re 7.5 A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. What does this mean when a collection is locked via a Depth 0 lock: 1) When a new resource is added to the collection, the resource is added without a lock as the parent has only a Depth 0 lock. 2) When a new resource is added to the collection, the resource is added and inherits the lock from above (via the second paragraph above) I will keep my ideas off this post (as this will just be the question), but will send a follow up with my ideas. Thanks, Kevin ------=_NextPart_000_0037_01BF35C6.4737CFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Xythos will currently only add a resource to = a=20 collection lock if its depth is infinity.  Depth 0 = locks will=20 always only be on one resource.
 
Kevin 
Jim = Davis and I=20 are having a discussion on what the appropriate behavior of a write = lock on a=20 collection should be. 
 

Re 7.5

A write lock on a collection, whether = created by a=20 "Depth: 0" or "Depth: = infinity" lock=20 request, prevents the addition or removal of=20 member URIs of the collection by non-lock owners.

If a lock owner causes the URI of a = resource to be=20 added as an internal member = URI of a=20 locked collection then the new resource MUST=20 be automatically added to the lock.

What = does this mean=20 when a collection is locked via a Depth 0 lock:

1)  When a new=20 resource is added to the collection, the resource is added without a = lock as=20 the parent has only a Depth 0 lock.

2)  When a new=20 resource is added to the collection, the resource is added and = inherits the=20 lock from above (via the second paragraph above)

I will = keep my ideas=20 off this post (as this will just be the question), but will send a = follow up=20 with my ideas. 

Thanks,

Kevin

------=_NextPart_000_0037_01BF35C6.4737CFE0-- From w3c-dist-auth-request@w3.org Tue Nov 23 18:56:13 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07092 for ; Tue, 23 Nov 1999 18:56:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA27109; Tue, 23 Nov 1999 18:42:11 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 18:42:11 -0500 (EST) Resent-Message-Id: <199911232342.SAA27109@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Kevin Wiggen cc: Greg Stein , w3c-dist-auth@w3.org Message-ID: <85256832.008228CD.00@D51MTA03.pok.ibm.com> Date: Tue, 23 Nov 1999 18:42:07 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: LOCK request body? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3640 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I agree. I've added it to the locking issues list just to be sure it doesn't get overlooked. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Nov 23 22:08:49 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14525 for ; Tue, 23 Nov 1999 22:08:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA01805; Tue, 23 Nov 1999 21:55:57 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 21:55:57 -0500 (EST) Resent-Message-Id: <199911240255.VAA01805@www19.w3.org> Reply-To: <5chandlers@home.com> From: "David M. Chandler" <5chandlers@home.com> To: Date: Tue, 23 Nov 1999 20:59:04 -0800 Message-ID: <000501bf3638$a21755d0$d6f00218@c786448-a.cdrrpd1.ia.home.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: Integrated XML browser/editor and WebDAV BOF at XML '99 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3641 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit There a couple of talks on structured document management at XML/MT '99 (www.gca.org/attend/1999_conferences/xml_99/default.htm), including one which specifically mentions WebDAV (abstract below). WebDAV seems like a natural fit for this application with its support for hierarchical collections. My personal interest is an XML browser/editor which can edit in place objects within a document (vs. the whole document) using WebDAV. Is anyone working on this? If anyone is planning to attend in Philadelphia and would like to get together informally to discuss current WebDAV-related initiatives, please send me e-mail and I'll help coordinate a time and place. David M. Chandler Web Applications Developer National Computer Systems 5chandlers@home.com Approaches for structured document management Timothy Arnold-Moore, Michael Fuller, and Ron Sacks-Davis, Royal Melbourne Institute of Technology (Australia) Document Management Systems (DMS) are tools to manage centralized repositories of documents, providing controlled access to documents and tracking the changes made to the documents. This presentation compares traditional DMS functionality with more recent DMS functional extensions and the even greater functionality available with structured document support through SGML or XML, and then summarizes the architectural differences among the three approaches. It also discusses relevant standards and initiatives, including ODMA, WEBDAV, and WAPI. From w3c-dist-auth-request@w3.org Tue Nov 23 22:43:13 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00651 for ; Tue, 23 Nov 1999 22:43:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA02879; Tue, 23 Nov 1999 22:31:42 -0500 (EST) Resent-Date: Tue, 23 Nov 1999 22:31:42 -0500 (EST) Resent-Message-Id: <199911240331.WAA02879@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Tue, 23 Nov 1999 19:29:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: LOCK request body? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3642 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Greg Stein writes: > Section 8.10.1 states that a LOCK request "SHOULD" have a request body. > However, it does not state what the server should use as a default if the > client does not supply a body. > > What should a server do? Create a lock of its own choosing? Uhhhhhhh... > The text does state "unless this is a refresh request", but the parsing of > the sentence is not entirely clear. I believe the intent is probably that > it MUST have a body for asserting a lock, and that it MUST NOT have a body > for refreshing a lock. This makes sense to me. > On a slightly different topic: why is a refresh done using locktokens > gathered from the If: header, rather than the more obvious Lock-Token: > header? I can't recall our original rationale. We might have been thinking that, since the lock had to exist for the request to be honored, this effectively made the locks existence a precondition, and preconditions are expressed using the If header. - Jim From w3c-dist-auth-request@w3.org Wed Nov 24 03:35:02 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06731 for ; Wed, 24 Nov 1999 03:35:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA09155; Wed, 24 Nov 1999 03:23:29 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 03:23:29 -0500 (EST) Resent-Message-Id: <199911240823.DAA09155@www19.w3.org> Message-Id: <4.1.19991124084257.00ae3980@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 24 Nov 1999 09:08:03 +0100 To: w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: References: <9911232119.AA08625@tantalum> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3644 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list A followup question for clarification Suppose I have a collection locked (at depth infinity), and I LOCK a null resource (7.4) within it. Does this action constitute adding a resource "as an internal member URI of a locked collection " as in 7.5? If so, then the locked-null resource now has two locks on it, right? From w3c-dist-auth-request@w3.org Wed Nov 24 03:35:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06927 for ; Wed, 24 Nov 1999 03:35:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA09003; Wed, 24 Nov 1999 03:17:41 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 03:17:41 -0500 (EST) Resent-Message-Id: <199911240817.DAA09003@www19.w3.org> Date: Wed, 24 Nov 1999 00:13:50 -0800 (PST) From: Greg Stein To: "David M. Chandler" <5chandlers@home.com> cc: w3c-dist-auth@w3.org In-Reply-To: <000501bf3638$a21755d0$d6f00218@c786448-a.cdrrpd1.ia.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Integrated XML browser/editor and WebDAV BOF at XML '99 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3643 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I think you missed one of the talks at XML '99 :-) ... WebDAV: Web-Based Distributed Authoring and Versioning WebDAV is an exciting new technology for the World Wide Web. WebDAV stands for Web-Based Distributed Authoring and Versioning, and provides a way to remotely author and manage your web servers (whether you are an author or an adminstrator). The WebDAV protocol is specified by RFC 2518 as an extension to the HTTP protocol, utilizing XML for client/server interactions and communication of metadata. This talk will present an overview of WebDAV, its benefits for users, and scenarios for effective deployment. It will continue with a discussion of the available tools, applications, and programmatic APIs available for working in WebDAV-enabled environments. In closing, the session will detail the future direction of the WebDAV protocol and how it could drive the next step in the evolution of the Web. by Greg Stein, Independent Software Developer (Wednesday, 9:45am) You might surmise that I'll be there, too :-). Yes, I'd be interested in getting together. It might make sense to put something on webdav.org. Should I direct people at you, for setting up a BOF? Re: editor. WebDAV provides no specific facilities for editing pieces of a document. Standard HTTP can do a GET/PUT using ranges, but WebDAV has avoided things like range locks. Cheers, -g On Tue, 23 Nov 1999, David M. Chandler wrote: > There a couple of talks on structured document management at XML/MT '99 > (www.gca.org/attend/1999_conferences/xml_99/default.htm), including one > which specifically mentions WebDAV (abstract below). WebDAV seems like a > natural fit for this application with its support for hierarchical > collections. My personal interest is an XML browser/editor which can edit in > place objects within a document (vs. the whole document) using WebDAV. Is > anyone working on this? > > If anyone is planning to attend in Philadelphia and would like to get > together informally to discuss current WebDAV-related initiatives, please > send me e-mail and I'll help coordinate a time and place. > > David M. Chandler > Web Applications Developer > National Computer Systems > 5chandlers@home.com > > Approaches for structured document management > Timothy Arnold-Moore, Michael Fuller, and Ron Sacks-Davis, Royal Melbourne > Institute of Technology (Australia) > Document Management Systems (DMS) are tools to manage centralized > repositories of documents, providing controlled access to documents and > tracking the changes made to the documents. This presentation compares > traditional DMS functionality with more recent DMS functional extensions and > the even greater functionality available with structured document support > through SGML or XML, and then summarizes the architectural differences among > the three approaches. It also discusses relevant standards and initiatives, > including ODMA, WEBDAV, and WAPI. > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Nov 24 04:10:43 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24034 for ; Wed, 24 Nov 1999 04:10:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA09922; Wed, 24 Nov 1999 03:59:06 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 03:59:06 -0500 (EST) Resent-Message-Id: <199911240859.DAA09922@www19.w3.org> Date: Wed, 24 Nov 1999 00:58:57 -0800 (PST) From: Greg Stein To: Jim Davis cc: w3c-dist-auth@w3.org In-Reply-To: <4.1.19991124084257.00ae3980@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3645 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Wed, 24 Nov 1999, Jim Davis wrote: > A followup question for clarification > > Suppose I have a collection locked (at depth infinity), and I LOCK a null > resource (7.4) within it. > > Does this action constitute adding a resource "as an internal member URI > of a locked collection " as in 7.5? > > If so, then the locked-null resource now has two locks on it, right? Yup. That's what mod_dav does. Note that both locks must be shared. And here is something that is really whacky: now remove the new lock -- the lock-null resource should still stick around since it had inherited the lock from its parent collection. It will remain until that parent collection's lock has been removed. Fun, eh? :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Nov 24 08:57:04 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11220 for ; Wed, 24 Nov 1999 08:57:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA14584; Wed, 24 Nov 1999 08:31:10 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 08:31:10 -0500 (EST) Resent-Message-Id: <199911241331.IAA14584@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: Jim Davis , w3c-dist-auth@w3.org Message-ID: <85256833.004A378E.00@D51MTA03.pok.ibm.com> Date: Wed, 24 Nov 1999 08:30:58 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3646 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Just in case you were looking for consensus, I agree with Greg. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Nov 24 09:07:57 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17006 for ; Wed, 24 Nov 1999 09:07:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA15057; Wed, 24 Nov 1999 08:56:03 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 08:56:03 -0500 (EST) Resent-Message-Id: <199911241356.IAA15057@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Jim Whitehead cc: w3c-dist-auth@w3.org Message-ID: <85256833.004C805F.00@D51MTA03.pok.ibm.com> Date: Wed, 24 Nov 1999 08:55:56 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: LOCK request body? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3647 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > On a slightly different topic: why is a refresh done using locktokens > gathered from the If: header, rather than the more obvious Lock-Token: > header? I can't recall our original rationale. We might have been thinking that, since the lock had to exist for the request to be honored, this effectively made the locks existence a precondition, and preconditions are expressed using the If header. So do we need to define server behavior if more than one lock is specified in the If header? From w3c-dist-auth-request@w3.org Wed Nov 24 09:42:45 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04172 for ; Wed, 24 Nov 1999 09:42:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA15823; Wed, 24 Nov 1999 09:27:09 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 09:27:09 -0500 (EST) Resent-Message-Id: <199911241427.JAA15823@www19.w3.org> Date: Wed, 24 Nov 1999 06:27:11 -0800 (PST) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <85256833.004C805F.00@D51MTA03.pok.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: LOCK request body? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3648 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Wed, 24 Nov 1999 ccjason@us.ibm.com wrote: > > On a slightly different topic: why is a refresh done using locktokens > > gathered from the If: header, rather than the more obvious Lock-Token: > > header? > > I can't recall our original rationale. We might have been thinking that, > since the lock had to exist for the request to be honored, this > effectively > made the locks existence a precondition, and preconditions are expressed > using the If header. > > So do we need to define server behavior if more than one lock is specified > in the If header? fyi: mod_dav refreshes all of them. -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Nov 24 09:52:22 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09059 for ; Wed, 24 Nov 1999 09:52:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA16218; Wed, 24 Nov 1999 09:33:14 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 09:33:14 -0500 (EST) Resent-Message-Id: <199911241433.JAA16218@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Jim Davis , w3c-dist-auth@w3.org Message-ID: <85256833.004FE8AE.00@D51MTA03.pok.ibm.com> Date: Wed, 24 Nov 1999 09:33:09 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3649 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > If a lock owner causes the URI of a resource to be added as an internal > member URI of a locked collection then the new resource MUST be > automatically added to the lock. > >I believe this statement should only apply to non-Depth:0 locks. >Otherwise, this results in the inability to independently lock >a collection and members of the collection. > How so? please provide a sequence of operations that would be impossible > under this interpretation. This really sounds like you are misunderstanding us since it's difficult to believe that you think a singleton lock could be inherited. You do seem to believe that it's not inherited on creation of the lock, only with addition of new members. /a/b.html exists. LOCK /a/ is invoked, depth:0 I think we agree that /a/ is locked and that /a/b.html is not. And that the lock on /a/ prevents anyone except the lock owner from changing the membership of /a/. Now the owner does a BIND to /a/c/ and adds a whole new tree below /a/. I think you're saying that despite the fact that /a/ is only singleton (aka depth:0) locked, the whole new tree should be added to the lock. IOW... /a/c/, /a/c/d.html, /a/c/s/t.html all become part of the singleton lock. I think the rest of us are expecting those resources not to be added to the lock because we expect a singleton lock to only lock one resource. I think this is where the disagreement or misunderstanding lies. So what does it prevent? It prevents adding /a/c/ without locking /a/c/ and the rest of the tree. And this might prevent a BIND/MOVE if there is a incompatible lock within that tree. What does what you propose ENABLE? It does enable a lock-null like behavior without all the dissonance of a null resource and without some of the disadvantages of the depth lock workaround that some folks might use in the absense of lock null resource support. My opinion, this is interesting and deserves further consideration, but it can't *replace* the default notion that singleton locks only lock a single resource. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Nov 24 10:12:34 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17640 for ; Wed, 24 Nov 1999 10:12:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA17162; Wed, 24 Nov 1999 09:57:11 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 09:57:11 -0500 (EST) Resent-Message-Id: <199911241457.JAA17162@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: w3c-dist-auth@w3.org Message-ID: <85256833.00521745.00@D51MTA03.pok.ibm.com> Date: Wed, 24 Nov 1999 09:57:00 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3650 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > > On a slightly different topic: why is a refresh done using locktokens > > gathered from the If: header, rather than the more obvious Lock-Token: > > header? > > I can't recall our original rationale. We might have been thinking that, > since the lock had to exist for the request to be honored, this > effectively > made the locks existence a precondition, and preconditions are expressed > using the If header. > > So do we need to define server behavior if more than one lock is specified > in the If header? > fyi: mod_dav refreshes all of them. Interesting. And what type of body do you use for success? Do you only support it if the locks are on the same resource? And how do you respond if some of the refreshes failed? From w3c-dist-auth-request@w3.org Wed Nov 24 10:47:06 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01579 for ; Wed, 24 Nov 1999 10:47:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA18887; Wed, 24 Nov 1999 10:29:21 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 10:29:21 -0500 (EST) Resent-Message-Id: <199911241529.KAA18887@www19.w3.org> To: Jim Whitehead cc: WebDAV WG , reuterj@ira.uka.de, jjh@ira.uka.de In-reply-to: Your message of "Wed, 17 Nov 1999 18:01:00 PST." Date: Wed, 24 Nov 1999 16:28:51 +0100 From: Juergen Reuter Message-ID: <"iraun1.ira.780:24.11.99.15.28.59"@ira.uka.de> Subject: Re: Syntax Issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3651 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Many thanks for your detailed and constructive answer! Still some issues are left... On Wed, 17 Nov 1999 18:01:00 -0800, Jim Whitehead wrote: > WebDAV applications are only required to send sequences of well formed XML > back and forth, and are not required to adhere to XML validity rules. So, > while you're correct that we don't have a top-level container object, this > isn't a problem because we don't require validity. Ok, on the [WebDAV] issues list, I found the XML_NOT_VALID issue stating that the specification should explicitly note that the XML is not valid (although, I finally found that, in fact, [WebDAV] already explicitly notes this in section 17.7; but it should also be noted in the introduction). > See, there's that pesky validity acting up again. While validity is useful > for sending documents around, where those documents can have widely varying > DTDs, in the WebDAV protocol, both ends of the protocol better know both the > syntax and semantics of the protocol, otherwise there will be no > interoperation. > Since there is a finite set of XML elements used within > WebDAV, and since both ends of the protocol know them, and the rules for > combining them, doing strict XML validity checking doesn't add much. As far as I understand, WebDAV's DTD itself is fixed; but the examples in chapter 8 use a namespace identified by the external entity reference URI "http://www.foo.bar/boxschema", which, effectively, extends the syntax. > On the > other hand, DAV clients and servers are required to make sure that XML > elements are nested correctly, and the nesting rules are given > prescriptively in the XML DTD language. Then it should not be too difficult to apply those small changes that should make WebDAV validatable? > So, while DAV doesn't require XML > validity, it does require elements to be correctly nested. By not requiring > validity, we can ignore the parts of XML that don't make sense in a protocol > setting like DAV, while keeping those parts that are useful (like nesting > hierarchies). Ok, I understand that there might be reasons for some implementors not to use validation. On the other hand, I think validating xml could be implicitly introduced into [WebDAV], thereby allowing each implementor to decide on his own whether to use validation or not. The current syntax, however, makes it impossible to use validation, unless an additional input filter is supplied that patches the input data, or a validating parser is patched to accept even [WebDAV]'s syntax. On Thu, 23 Jul 1998 19:04:28 PDT, Jim Davis (jdavis@parc.xerox.com) wrote: > And lest you have any doubt, the spec contains examples of invalid > (although well-formed) XML. For example the prop XML element is defined as > ANY, and the XML spec (section 3.2) says that ANY means "any declared > element type", but in general, client properties will not have been > declared in the DTD, hence this XML will be well formed but not valid. However, this is not a problem, because in section 2.8 [XML] says: "The document type declaration can point to an external subset ..., or contain the markup declarations directly ..., or can do both." This means client properties do not need to be declared in the DTD, but can also be declared directly as markup declarations in the submitted document. > It's also a pity that there's no way in XML (that I see) to declare an > element's contents to truly be "any". This would allow you to validate > WebDAV XML in those places that mattered (e.g. propertybehavior) and not in > those places that are open ended (resourcetype). But this can't be helped. With the above said, there is no reason to declare an element's contents to truly be "any". On Wed, 17 Nov 1999 18:01:00 -0800, Jim Whitehead wrote: > extend = token ; token is defined in [HTTP]. Ok. Probably extend should be further restricted to be any other token than the string "2". > > 6. Is there a specific reason for WebDAV not making use of xml > > element attributes? I think, using attributes could both, speed > > up parsing and simplify the grammar. > > For example, elements exclusive and shared could be replaced by > > a single enumerated attribute (see [XML] section 3.3.1, rule [57] > > EnumeratedType) for element lockscope. > > Yaron Goland is the main proponent of never using XML attributes, and his > rationale is presented here: > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0084.html Ok. When regarding extensibility of the specification, not using element attributes might be the better choice, even if parsing might become slower and more memory exhausting (at least for my current implementation). Bye, Juergen From w3c-dist-auth-request@w3.org Wed Nov 24 10:52:13 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04091 for ; Wed, 24 Nov 1999 10:52:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA19166; Wed, 24 Nov 1999 10:33:02 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 10:33:02 -0500 (EST) Resent-Message-Id: <199911241533.KAA19166@www19.w3.org> To: Greg Stein cc: WebDAV WG , reuterj@ira.uka.de, jjh@ira.uka.de In-reply-to: Your message of "Thu, 18 Nov 1999 00:06:19 PST." Date: Wed, 24 Nov 1999 16:32:38 +0100 From: Juergen Reuter Message-ID: <"iraun1.ira.043:24.11.99.15.32.49"@ira.uka.de> Subject: Re: Syntax Issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3652 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > Wow. I didn't realize that IE5 and Office 2000 were not "real-life > applications." After all, they don't check against a DTD. > > I am rather using Netscape for surfing and emacs/LaTeX for word processing; hence I do not know much about the products that you mentioned, and therefore I do not feel authorized to classify them as being anything. ;-) > I've been able to implement a DAV server without the "benefit" of a DTD. > Works great. Many other people have done servers, too. There aren't so > many clients, but they all work very well. All without the benefit of a > DTD. How do you know? I suppose, you did not proof their correctness... Actually, I found the invalid xml element declaration, which I reported in my preceding mail, by using a validating parser to parse WebDAV's DTD. Though I notice, that validation can not guarantee correctness, I think that a validiating parser, if sensibly applied, can reduce the risk of introducing implementation (and possibly specification) bugs. Bye, Juergen From w3c-dist-auth-request@w3.org Wed Nov 24 11:51:25 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03019 for ; Wed, 24 Nov 1999 11:51:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA21283; Wed, 24 Nov 1999 11:35:29 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 11:35:29 -0500 (EST) Resent-Message-Id: <199911241635.LAA21283@www19.w3.org> Date: Wed, 24 Nov 1999 11:35:06 -0500 Message-Id: <9911241635.AA09030@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (message from Greg Stein on Tue, 23 Nov 1999 13:41:32 -0800 (PST)) Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3653 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: Greg Stein On Tue, 23 Nov 1999, Geoffrey M. Clemm wrote: > From: Kevin Wiggen >... > Re 7.5 > > A write lock on a collection, whether created by a "Depth: 0" or "Depth: > infinity" lock request, prevents the addition or removal of member URIs of > the collection by non-lock owners. > > I believe it says "internal member". Nope. It just says "member". Greg is correct. I must have been been misled by what I *wanted* it to say. But the next sentence in 7.5 says: As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection. which leads one to believe that the intent was to talk about internal members. In any case, whatever the original intent may have been, I would propose that the statement in question be modified to explicitly state "internal member", since depth:0 locks should only affect the addition and removal of internal members. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Nov 24 12:02:41 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09035 for ; Wed, 24 Nov 1999 12:02:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA21617; Wed, 24 Nov 1999 11:46:15 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 11:46:15 -0500 (EST) Resent-Message-Id: <199911241646.LAA21617@www19.w3.org> Date: Wed, 24 Nov 1999 11:46:06 -0500 Message-Id: <9911241646.AA09038@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <4.1.19991123232148.00b0b440@pop.xs4all.nl> (message from Jim Davis on Tue, 23 Nov 1999 23:26:13 +0100) Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3654 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 23 Nov 1999 23:26:13 +0100 From: Jim Davis References: Mime-Version: 1.0 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3638 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Length: 1426 At 04:19 PM 11/23/99 -0500, Geoffrey M. Clemm wrote: > A write lock on a collection, whether created by a "Depth: 0" or "Depth: > infinity" lock request, prevents the addition or removal of member URIs of > the collection by non-lock owners. > If a lock owner causes the URI of a resource to be added as an internal > member URI of a locked collection then the new resource MUST be > automatically added to the lock. > >I believe this statement should only apply to non-Depth:0 locks. >Otherwise, this results in the inability to independently lock >a collection and members of the collection. How so? please provide a sequence of operations that would be impossible under this interpretation. I lock a collection, because I'm going to be adding members to that collection. If a depth:0 lock applies to all the immediate members of a collection as well, then I have prevented anyone from updating the state of one of the existing internal members of that collection. If I'd wanted that behavior, I would have issued a depth:1 lock. And quoting from the definition of what depth means: The Depth header is used with methods executed on resources which could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its immediate children, ("Depth: 1"), or the resource and all its progeny ("Depth: infinity"). Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Nov 24 15:03:31 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00416 for ; Wed, 24 Nov 1999 15:03:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA00482; Wed, 24 Nov 1999 14:51:48 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 14:51:48 -0500 (EST) Resent-Message-Id: <199911241951.OAA00482@www19.w3.org> Date: Wed, 24 Nov 1999 11:47:35 -0800 From: Kevin Wiggen To: w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/alternative; boundary="----=_NextPart_000_005C_01BF3671.B31A1AA0" Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Priority: 3 (Normal) Subject: getlastmodified and ISO8601 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3655 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_005C_01BF3671.B31A1AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit At the last IETF in Was DC, it was suggested (by me I think) that we should change the property from using HTTP-Date to ISO-8601 dates. I would like to do this now before to many clients and servers exist, and we can never change it. Many people at the meeting agreed with me, but we did not know what problems this might cause existing clients and servers. So here is the question, can we make this change. Xythos currently uses HTTP-Date, but we will have no problem updating to ISO-8601 (and then patching our client's servers). Thanks, Kevin ------=_NextPart_000_005C_01BF3671.B31A1AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At the = last IETF in=20 Was DC, it was suggested (by me I think) that we should change the=20 <d:getlastmodified> property from using HTTP-Date to ISO-8601=20 dates.   I would like to do this now before to many clients = and=20 servers exist, and we can never change it.
 
Many = people at the=20 meeting agreed with me, but we did not know what problems this might = cause=20 existing clients and servers.
 
So = here is the=20 question, can we make this change.
 
Xythos = currently=20 uses HTTP-Date, but we will have no problem updating to ISO-8601 (and = then=20 patching our client's servers).
 
Thanks,
Kevin
------=_NextPart_000_005C_01BF3671.B31A1AA0-- From w3c-dist-auth-request@w3.org Wed Nov 24 17:52:36 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20114 for ; Wed, 24 Nov 1999 17:52:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06402; Wed, 24 Nov 1999 17:36:04 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 17:36:04 -0500 (EST) Resent-Message-Id: <199911242236.RAA06402@www19.w3.org> Date: Wed, 24 Nov 1999 14:35:56 -0800 (PST) From: Greg Stein To: ccjason@us.ibm.com cc: w3c-dist-auth@w3.org In-Reply-To: <85256833.00521745.00@D51MTA03.pok.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3656 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Wed, 24 Nov 1999 ccjason@us.ibm.com wrote: >... > > So do we need to define server behavior if more than one lock is > specified > > in the If header? > > > fyi: mod_dav refreshes all of them. > > Interesting. And what type of body do you use for success? Do you only > support > it if the locks are on the same resource? > > And how do you respond if some of the refreshes failed? We return a DAV:lockdiscovery element (as defined) which contains multiple DAV:activelock elements (as defined). We refresh any locks that are extent on that resource and that we find in the If: header. In other words, we'll refresh direct locks and those inherited from Depth:infinity locks further up in the namespace. On error, we return a single status code (not a multistatus). That's because a refresh is not being applied to multiple resources -- just multiple locks on *one* resource. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Nov 24 18:28:32 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07398 for ; Wed, 24 Nov 1999 18:28:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA07409; Wed, 24 Nov 1999 18:13:43 -0500 (EST) Resent-Date: Wed, 24 Nov 1999 18:13:43 -0500 (EST) Resent-Message-Id: <199911242313.SAA07409@www19.w3.org> Date: Wed, 24 Nov 1999 15:13:47 -0800 (PST) From: Greg Stein To: Kevin Wiggen cc: w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: getlastmodified and ISO8601 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3657 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Wed, 24 Nov 1999, Kevin Wiggen wrote: > At the last IETF in Was DC, it was suggested (by me I think) that we should > change the property from using HTTP-Date to ISO-8601 > dates. I would like to do this now before to many clients and servers > exist, and we can never change it. > > Many people at the meeting agreed with me, but we did not know what problems > this might cause existing clients and servers. > > So here is the question, can we make this change. > > Xythos currently uses HTTP-Date, but we will have no problem updating to > ISO-8601 (and then patching our client's servers). One line change for me. Not a problem. -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Nov 25 12:50:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13091 for ; Thu, 25 Nov 1999 12:50:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA27351; Thu, 25 Nov 1999 12:36:07 -0500 (EST) Resent-Date: Thu, 25 Nov 1999 12:36:07 -0500 (EST) Resent-Message-Id: <199911251736.MAA27351@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: w3c-dist-auth@w3.org Message-ID: <85256834.0060A466.00@D51MTA03.pok.ibm.com> Date: Thu, 25 Nov 1999 12:35:47 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3658 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list We return a DAV:lockdiscovery element (as defined) which contains multiple DAV:activelock elements (as defined). We refresh any locks that are extent on that resource and that we find in the If: header. In other words, we'll refresh direct locks and those inherited from Depth:infinity locks further up in the namespace. On error, we return a single status code (not a multistatus). That's because a refresh is not being applied to multiple resources -- just multiple locks on *one* resource. And what about if the if header references several locks on different resources? From w3c-dist-auth-request@w3.org Thu Nov 25 19:19:49 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00048 for ; Thu, 25 Nov 1999 19:19:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA03081; Thu, 25 Nov 1999 19:05:23 -0500 (EST) Resent-Date: Thu, 25 Nov 1999 19:05:23 -0500 (EST) Resent-Message-Id: <199911260005.TAA03081@www19.w3.org> Message-Id: <4.1.19991125192837.00b04650@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 26 Nov 1999 00:22:33 +0100 To: ccjason@us.ibm.com From: Jim Davis Cc: w3c-dist-auth@w3.org In-Reply-To: <85256833.004FB7EF.00@D51MTA03.pok.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3659 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 09:31 AM 11/24/99 -0500, ccjason@us.ibm.com wrote: > Jim Davis wrote: >> ... please provide a sequence of operations that would be impossible >> [if a depth 0 lock on a colllection is inherited by newly created internal members of that collection, as in 7.5]... > >LOCK /a/ is invoked, depth:0 > >...Now the owner does a BIND to /a/c/ and adds a whole new >tree below /a/. Oh now I get it. You are thinking about the consequences for BIND. But BIND is not part of RFC 2518. But my question was about the behavior of plain old RFC 2518. My intention is to try to finish a WebDAV testing tool tdav.py that tests compliance and interoperability of WebDAV servers according to RFC 2518, not according to the work of the advanced collections group. RFC 2518 is on its way to a Standard, but the advanced collection work is not yet there. it may be part of WebDAV someday, but it is not, yet. I have not proposed or argued against anything. I am just trying to get a clear understanding of RFC 2518. We all agree that a depth infinity lock on a collection is inherited by newly created internal members. The only point of disagreement is about a depth zero lock. I read 7.5 as saying that even a depth zero lock is inherited, because it does not say "only depth infinity". You and others have asserted that this is bad. When I asked why, you said it causes problems for BIND. But BIND is not in RFC 2518, so let me ask, just for clarity's sake, does it cause problems for a server compliant with RFC 2518, but ignorant of BIND? If so, what is it? If not, then we can take up the problem with BIND, and see whether it really is a problem, and if so, what to do about it. it's perfectly fine with me to rule out certain behaviors that might be lawful under plain old RFC 2518 in order to leave room for future expansion. But if that's the reason, we should say so. So can we clear up this question first, and then take on the question of whether there's a problem for BIND? With all best wishes Jim From w3c-dist-auth-request@w3.org Thu Nov 25 19:20:15 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00216 for ; Thu, 25 Nov 1999 19:20:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA03343; Thu, 25 Nov 1999 19:06:13 -0500 (EST) Resent-Date: Thu, 25 Nov 1999 19:06:13 -0500 (EST) Resent-Message-Id: <199911260006.TAA03343@www19.w3.org> Message-Id: <4.1.19991126002911.00b1bc50@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 26 Nov 1999 00:30:50 +0100 To: w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: <9911241635.AA09030@tantalum> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3660 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 11:35 AM 11/24/99 -0500, Geoffrey M. Clemm wrote: >... propose that the statement in question be modified to explicitly >state "internal member", since depth:0 locks should only affect the >addition and removal of internal members. internal members, as opposed to those added by, say, BIND? Fine with me. From w3c-dist-auth-request@w3.org Thu Nov 25 19:20:25 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00276 for ; Thu, 25 Nov 1999 19:20:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA03361; Thu, 25 Nov 1999 19:06:18 -0500 (EST) Resent-Date: Thu, 25 Nov 1999 19:06:18 -0500 (EST) Resent-Message-Id: <199911260006.TAA03361@www19.w3.org> Message-Id: <4.1.19991126003117.00b1add0@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 26 Nov 1999 00:37:56 +0100 To: w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: <9911241646.AA09038@tantalum> References: <4.1.19991123232148.00b0b440@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3661 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 11:46 AM 11/24/99 -0500, Geoffrey M. Clemm wrote: > How so? please provide a sequence of operations that would be impossible > under this interpretation. > >I lock a collection, because I'm going to be adding members >to that collection. If a depth:0 lock applies to all the >immediate members of a collection as well, then I have prevented >anyone from updating the state of one of the existing internal members of >that collection. But that's not what I asked about, or at least not what I thought I asked about. If I lock a collection with depth infinity lock, then create a new interrnal member of that collection (e.g. with PUT) I have to provide the lock token to do the PUT, and the new internal member is added to the lock. We all agree on this, right? Now suppose the lock were depth 0 not depth infinity. 1) to add a new internal member, I still have to provide the lock token, right? 2) Previously exising members are not affected. I can PUT or PROPPATCH to them at my whim, right? 3) However, I can't DELETE them without the lock token, right? So where we seem to disagree is: If I add a new internal member, is it added to the lock, or not? I interpret 7.5 as saying Yes. You seem to think that the answer is, or should be, no. Can you please explain this? I don't see how this depth 0 lock would prevent anyone from updating the state of existing members. with all best wishes Jim From w3c-dist-auth-request@w3.org Fri Nov 26 03:40:57 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14326 for ; Fri, 26 Nov 1999 03:40:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA08645; Fri, 26 Nov 1999 03:22:26 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 03:22:26 -0500 (EST) Resent-Message-Id: <199911260822.DAA08645@www19.w3.org> Date: Fri, 26 Nov 1999 00:22:21 -0800 (PST) From: Greg Stein To: ccjason@us.ibm.com cc: w3c-dist-auth@w3.org In-Reply-To: <85256834.0060A466.00@D51MTA03.pok.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3662 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Thu, 25 Nov 1999 ccjason@us.ibm.com wrote: > We return a DAV:lockdiscovery element (as defined) which contains > multiple > DAV:activelock elements (as defined). > > We refresh any locks that are extent on that resource and that we find > in > the If: header. In other words, we'll refresh direct locks and those > inherited from Depth:infinity locks further up in the namespace. > > On error, we return a single status code (not a multistatus). That's > because a refresh is not being applied to multiple resources -- just > multiple locks on *one* resource. > > And what about if the if header references several locks on different > resources? A = the set of locktokens found in the If: header B = the set of locktokens found on the resource (directly and/or through inherited locks) mod_dav refreshes the intersection. By "on different resources", if you mean the Request-URI and the resource locked with a Depth:infinity lock (implied by the inherited lock on the Request-URI), then yes. If you mean locks implied by a Tagged-List in the If: header, then that just doesn't make sense :-) Happy Thanksgiving, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Nov 26 14:24:40 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12298 for ; Fri, 26 Nov 1999 14:24:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA21747; Fri, 26 Nov 1999 14:12:52 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 14:12:52 -0500 (EST) Resent-Message-Id: <199911261912.OAA21747@www19.w3.org> Date: Fri, 26 Nov 1999 11:12:38 -0800 (PST) From: Greg Stein To: Jim Davis cc: w3c-dist-auth@w3.org In-Reply-To: <4.1.19991125192837.00b04650@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3663 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Fri, 26 Nov 1999, Jim Davis wrote: >... > I read 7.5 as saying that even a depth zero lock is inherited, because it > does not say "only depth infinity". You and others have asserted that this > is bad. When I asked why, you said it causes problems for BIND. That's being a bit pedantic, don't you think? All right, so the RFC is missing three words. Put them in and interpret it that way. We know what the state of a Depth:0 lock on a collection is after one has been applied (just the collection is locked), and we know the state after a Depth:infinity has been applied (a bunch of stuff is locked). Your "interpretation" would create situations that just don't match normal behavior. With the simple insertion of three words, you get behavior that matches for the PUT/MKCOL case and the LOCK case. What I don't understand is how you could arrive at a reasonable interpretation that the lock *should* be inherited. Could you explain? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Nov 26 14:28:43 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13715 for ; Fri, 26 Nov 1999 14:28:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA22025; Fri, 26 Nov 1999 14:17:48 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 14:17:48 -0500 (EST) Resent-Message-Id: <199911261917.OAA22025@www19.w3.org> Date: Fri, 26 Nov 1999 11:17:40 -0800 (PST) From: Greg Stein To: Jim Davis cc: w3c-dist-auth@w3.org In-Reply-To: <4.1.19991126003117.00b1add0@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3664 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Fri, 26 Nov 1999, Jim Davis wrote: >... > If I lock a collection with depth infinity lock, then create a new > interrnal member of that collection (e.g. with PUT) I have to provide the > lock token to do the PUT, and the new internal member is added to the lock. > > We all agree on this, right? Yes. > Now suppose the lock were depth 0 not depth infinity. > > 1) to add a new internal member, I still have to provide the lock > token, right? Right. > 2) Previously exising members are not affected. I can PUT or PROPPATCH to > them at my whim, right? Right. > 3) However, I can't DELETE them without the lock token, right? Right. You must supply the locktoken because you are altering the collection (on the theory that the set of names of internal members is part of its state). > So where we seem to disagree is: > > If I add a new internal member, is it added to the lock, or not? It is not. > I interpret 7.5 as saying Yes. You seem to think that the answer is, or > should be, no. > > Can you please explain this? I don't see how this depth 0 lock would > prevent anyone from updating the state of existing members. The depth:0 lock does not prevent people from updating existing members. It prevents you from altering the collections state: the set of names of internal members. Therefore, you cannot add or remove internal members. This means you must supply a locktoken with PUT, MKCOL, or a DELETE. Note that you shouldn't be able to create a locknull resource either(!) without supplying a locktoken. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Nov 26 14:46:05 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21578 for ; Fri, 26 Nov 1999 14:46:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA22979; Fri, 26 Nov 1999 14:35:04 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 14:35:04 -0500 (EST) Resent-Message-Id: <199911261935.OAA22979@www19.w3.org> From: Lars-Gunnar.F.Fallman@telia.se X-OpenMail-Hops: 1 Date: Fri, 26 Nov 1999 20:34:44 +0100 Message-Id: MIME-Version: 1.0 TO: w3c-dist-auth@w3.org Content-Type: text/plain; charset=US-ASCII; name="Office" Content-Disposition: inline; filename="Office" Content-Transfer-Encoding: 7bit Subject: Office 2000 and properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3665 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Does anyone know if it's possible to configure the Ms office 2000 applications and ms webfolders to use webdav properties instead of just embed them in the document ? /Lars-Gunnar From w3c-dist-auth-request@w3.org Fri Nov 26 14:48:02 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22401 for ; Fri, 26 Nov 1999 14:48:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA23338; Fri, 26 Nov 1999 14:36:51 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 14:36:51 -0500 (EST) Resent-Message-Id: <199911261936.OAA23338@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Jim Davis cc: w3c-dist-auth@w3.org Message-ID: <85256835.006BAE79.00@D51MTA03.pok.ibm.com> Date: Fri, 26 Nov 1999 14:36:31 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3666 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 11:46 AM 11/24/99 -0500, Geoffrey M. Clemm wrote: > How so? please provide a sequence of operations that would be impossible > under this interpretation. > >I lock a collection, because I'm going to be adding members >to that collection. If a depth:0 lock applies to all the >immediate members of a collection as well, then I have prevented >anyone from updating the state of one of the existing internal members of >that collection. > But that's not what I asked about, or at least not what I thought I asked > about. But that's what it sounded like you were asking about. That's why I think we have a misunderstanding.... If I lock a collection with depth infinity lock, then create a new interrnal member of that collection (e.g. with PUT) I have to provide the lock token to do the PUT, and the new internal member is added to the lock. We all agree on this, right? Ummm. We agree that a token is needed to add to the collection, but we need to define "added". The new resource isn't "added" to the lock, but it's membership is protected by the lock. It's the difference between a binding to a resource... and the resource itself. More in a sec... Now suppose the lock were depth 0 not depth infinity. 1) to add a new internal member, I still have to provide the lock token, right? 2) Previously exising members are not affected. I can PUT or PROPPATCH to them at my whim, right? 3) However, I can't DELETE them without the lock token, right? Yup, yup, yup. So where we seem to disagree is: If I add a new internal member, is it added to the lock, or not? I interpret 7.5 as saying Yes. You seem to think that the answer is, or should be, no. Yes, I think this it's just a matter of the definition of "added". I suspect we actually agree on the semantics. More in a sec... Can you please explain this? I don't see how this depth 0 lock would prevent anyone from updating the state of existing members. And we don't think it would. That's why I think this is just a misunderstanding. We basically agree with everything except for the phrase "is added to the lock"... or it might actually be with the definition of "internal member". I'm actually vague on that term. If it means binding, then I agree with you. The child resource isn't added to the lock... but the binding to the child resource is added to the state of the collection, so is therefore locked with the rest of the collection's state and could be said to have been added to the lock. That means if /a/b.html exists. And someone locks /a/ with depth:0, B can still be modified by PUT and PROPPATCH. It can't be MOVE'd, DELETE'd, or overwriten in a fashion that destroys it's binding. Now if the lock owner does the PUT that you mentioned on /a/c.html and provides the token, then a new resource is created. Anyone can modify that resource (PUT/PROPPATCH), but only the lock owner can DELETE it or MOVE it or in any way break the binding to it from the /a/ collection. We don't say that /a/c.html is locked or at least not the resource at that URI. You could say that the binding from /a/ to the /a/c.html is locked. And depending on our definitions of "internal member" we might actually be able to say that the internal member was added to the lock. We should probably more clearly define "internal member"... or get rid of the term. J. From w3c-dist-auth-request@w3.org Fri Nov 26 15:05:38 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00253 for ; Fri, 26 Nov 1999 15:05:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA23931; Fri, 26 Nov 1999 14:54:53 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 14:54:53 -0500 (EST) Resent-Message-Id: <199911261954.OAA23931@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: w3c-dist-auth@w3.org Message-ID: <85256835.006D514C.00@D51MTA03.pok.ibm.com> Date: Fri, 26 Nov 1999 14:54:22 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3667 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list If you mean locks implied by a Tagged-List in the If: header, then that just doesn't make sense :-) That's what I meant. I don't know if it makes sense or not, but I'm perfectly willing to say that "it" is not supported. And I agree that it seems somewhat odd that we use the IF header to determine what locks are to be refreshed. I would think this should work just as UNLOCK does. That's not to say people can't use an IF header, but that's not how they specify which of the locks is to be refreshed. The IF header would only be for consistancy checking if the client wanted the refresh to be contingent on the presence of a specified lock on some specified resource. Now I also recognize that changing this might break some clients/servers. Before we could change this, we'd have to come to a consensus that we're willing to change our implementations. J. From w3c-dist-auth-request@w3.org Fri Nov 26 15:09:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01996 for ; Fri, 26 Nov 1999 15:09:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA24149; Fri, 26 Nov 1999 14:58:22 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 14:58:22 -0500 (EST) Resent-Message-Id: <199911261958.OAA24149@www19.w3.org> Date: Fri, 26 Nov 1999 11:58:36 -0800 (PST) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <85256835.006BAE79.00@D51MTA03.pok.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3668 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Fri, 26 Nov 1999 ccjason@us.ibm.com wrote: >... > We don't say that /a/c.html is locked or at least not the resource > at that URI. You could say that the binding from /a/ to the /a/c.html > is locked. And depending on our definitions of "internal member" we > might actually be able to say that the internal member was added to > the lock. Depending on language like this in a spec is simply going to ensure that nobody truly understands the thing. Can't we step back from all this pedantic, theoretical stuff? Sure, it helps to rigorously define semantics, but (IMO) at the cost of most mortals' understanding of the result. Maybe plainer English can't do the job, but we ought to try, or questions like this will continue to come up. People reading the spec ought to be using their noggin, too. Missing three words from the spec shouldn't trap somebody. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Nov 26 15:17:03 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05209 for ; Fri, 26 Nov 1999 15:17:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA24773; Fri, 26 Nov 1999 15:06:17 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 15:06:17 -0500 (EST) Resent-Message-Id: <199911262006.PAA24773@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Jim Davis cc: w3c-dist-auth@w3.org Message-ID: <85256835.006E6218.00@D51MTA03.pok.ibm.com> Date: Fri, 26 Nov 1999 15:06:02 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3669 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Just noticed this note from you. You pointed out that you are talking about the pre-AdvColl behavior In light of this, please add the following to my previous note... Although this note uses the term "binding", what I'm saying is not contingent on the Adv.Coll. spec. BINDING is just an unambiguous term that I am using to distinguish the child resource from the parent's connection to it. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Nov 26 15:24:48 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08455 for ; Fri, 26 Nov 1999 15:24:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA25112; Fri, 26 Nov 1999 15:13:46 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 15:13:46 -0500 (EST) Resent-Message-Id: <199911262013.PAA25112@www19.w3.org> Date: Fri, 26 Nov 1999 12:13:50 -0800 (PST) From: Greg Stein To: ccjason@us.ibm.com cc: w3c-dist-auth@w3.org In-Reply-To: <85256835.006D514C.00@D51MTA03.pok.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3670 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Fri, 26 Nov 1999 ccjason@us.ibm.com wrote: > If you mean locks implied by a Tagged-List in the If: header, then that > just doesn't make sense :-) > > That's what I meant. I don't know if it makes sense or not, but I'm > perfectly willing to say that "it" is not supported. Hrm; I guess it could make some sense to impute the URIs in a tagged-list as some kind of input parameter. We do with the locktokens, after all :-) > And I agree that it seems somewhat odd that we use the IF header to > determine > what locks are to be refreshed. I would think this should work just as > UNLOCK > does. That's not to say people can't use an IF header, but that's not how > they specify which of the locks is to be refreshed. The IF header would > only > be for consistancy checking if the client wanted the refresh to be > contingent > on the presence of a specified lock on some specified resource. IMO, this would have been the clearest way to do this. It's that pedantic trap again. As JimW explained "well, we saw it as a precondition, and preconditions are specified with the If: header, and ..." > Now I also recognize that changing this might break some clients/servers. > Before we could change this, > we'd have to come to a consensus that we're willing to change our > implementations. Well, Office 2000 uses LOCKs and could be argued as one of the more popular clients :-). If it doesn't send a Lock-Token header, then we're out of luck. The spec would then need to specify behavior in the absence of the Lock-Token header. Anybody know if it sends a Lock-Token header when it refreshes its lock? Personally: I'd be fine changing mod_dav. Simply a lot of stuff, and I really think its the clearest mechanism for the protocol. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Nov 26 16:57:27 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19563 for ; Fri, 26 Nov 1999 16:57:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA27344; Fri, 26 Nov 1999 16:43:31 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 16:43:31 -0500 (EST) Resent-Message-Id: <199911262143.QAA27344@www19.w3.org> X-Lotus-FromDomain: I2TECH From: "Viktor Lioutyi" To: w3c-dist-auth@w3.org cc: "Lee Boal" Message-ID: <86256835.00774951.00@smtpmta2.i2.com> Date: Fri, 26 Nov 1999 16:42:14 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Lost with links ... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3671 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list In our project we want to support persistency of our meta-data in a repository, based on WebDAV. We'd like to avoid fine-grain repositories because there is no a product of this type, running on different platforms. We'd like to use different WebDAV servers depending on our requirements and to protect ourselves from their differences via WebDAV protocol. We found that the following services from WebDAV are crucial for us: - naming service, properties, etc. (the whole WebDAV level-2) - versioning (Delta-V) - query service (DASL) - transactions - relationships In WebDAV level-2 there is something called links. In RFC2518 links are defined in paragraph 4.6 "Media Independent Links" "A WebDAV link is a special type of property value, formally defined in section 12.4, that allows typed connections to be established between resources of any media type." From 12.4 "Link XML Element" We suppose that these links are the closest notion in WebDAV that may be used to map relationships between models, but there are a lot of questions in respect to Delta-V and DASL. 1) Does a link include version information for "src" and "dsc" or "src" and "dst" will be resolved in a context of a workspace? 2) Can I get part of the whole link back as result of a DASL query? For example, I'd like to know all destinations for particular source for particular kind of a link. 3) Is there any intention to provide special operations for links? For example, I'd like to modify link. Is it required to download the whole link, change, then save or may I do incremental modifications (add/remove pairs (src, dst) from a link without downloading it)? Thanks, Viktor From w3c-dist-auth-request@w3.org Fri Nov 26 19:28:37 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24407 for ; Fri, 26 Nov 1999 19:28:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA29475; Fri, 26 Nov 1999 19:16:54 -0500 (EST) Resent-Date: Fri, 26 Nov 1999 19:16:54 -0500 (EST) Resent-Message-Id: <199911270016.TAA29475@www19.w3.org> Date: Fri, 26 Nov 1999 23:58:45 +0000 From: Joe Orton To: Kevin Wiggen Cc: w3c-dist-auth@w3.org Message-ID: <19991126235845.F812@ankh.dunno.local> Mail-Followup-To: Kevin Wiggen , w3c-dist-auth@w3.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from wiggs@xythos.com on Wed, Nov 24, 1999 at 11:47:35AM -0800 Subject: Re: getlastmodified and ISO8601 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3672 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > At the last IETF in Was DC, it was suggested (by me I think) that we should > change the property from using HTTP-Date to ISO-8601 > dates. I would like to do this now before to many clients and servers > exist, and we can never change it. > > Many people at the meeting agreed with me, but we did not know what problems > this might cause existing clients and servers. I'm happy to make this change in sitecopy+cadaver. joe From w3c-dist-auth-request@w3.org Mon Nov 29 10:07:12 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06875 for ; Mon, 29 Nov 1999 10:07:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA20722; Mon, 29 Nov 1999 09:48:26 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 09:48:26 -0500 (EST) Resent-Message-Id: <199911291448.JAA20722@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256838.005149F8.00@d54mta03.raleigh.ibm.com> Date: Mon, 29 Nov 1999 09:47:44 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3673 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I read 7.5 as saying that even a depth zero lock is inherited, because it does not say "only depth infinity". You and others have asserted that this is bad. When I asked why, you said it causes problems for BIND. I think this is assuming too much from missing information. I do not draw this conclusion given the inheritance of depth locks on existing resources. Locking a collection with depth:0 does not lock any of the members of the collection. So why would adding a new member inherit the lock? From w3c-dist-auth-request@w3.org Mon Nov 29 10:31:27 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18348 for ; Mon, 29 Nov 1999 10:31:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA22364; Mon, 29 Nov 1999 10:20:29 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 10:20:29 -0500 (EST) Resent-Message-Id: <199911291520.KAA22364@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256838.00520B4F.00@d54mta03.raleigh.ibm.com> Date: Mon, 29 Nov 1999 09:55:42 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3674 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I agree with everything below except the conclusion that depth:0 locks are inherited. The behavior is determined by the lock on the collection, not any of its members. So for example, say you create a new member with PUT. This will require the lock token for the collection as it is locked to control its namespace. Now anyone can PUT to the new resource without any lock token as no new member is created, and the new resource is not locked. However, the lock token for the collection must be specified in order to delete this, or any other resource from the collection as this is effecting the collection's namespace. So in this sense, the behavior of the lock is "inherited" by the new resource, but I wouldn't look at it this way. I think this is just the meaning of a lock on a collection. See details below in tags. Jim Davis on 11/25/99 06:37:56 PM To: w3c-dist-auth@w3.org cc: Subject: Re: Write Locks on Collections At 11:46 AM 11/24/99 -0500, Geoffrey M. Clemm wrote: > How so? please provide a sequence of operations that would be impossible > under this interpretation. > >I lock a collection, because I'm going to be adding members >to that collection. If a depth:0 lock applies to all the >immediate members of a collection as well, then I have prevented >anyone from updating the state of one of the existing internal members of >that collection. But that's not what I asked about, or at least not what I thought I asked about. If I lock a collection with depth infinity lock, then create a new interrnal member of that collection (e.g. with PUT) I have to provide the lock token to do the PUT, and the new internal member is added to the lock. We all agree on this, right? Agreed Now suppose the lock were depth 0 not depth infinity. 1) to add a new internal member, I still have to provide the lock token, right? Yes because this is changing the collection's members or its managed namespace. 2) Previously exising members are not affected. I can PUT or PROPPATCH to them at my whim, right? Yes, you or anyone else subject to their own individual locks and access controls of course. 3) However, I can't DELETE them without the lock token, right? True, but this doesn't mean the lock in inherited. This is just the meaning of a lock on a parent collection. You can't change the locked collection's members without the lock token. So where we seem to disagree is: If I add a new internal member, is it added to the lock, or not? Not added to the lock. You're confusing the notion of a lock on a resource with the meaning of a lock on its parent collection. I interpret 7.5 as saying Yes. You seem to think that the answer is, or should be, no. Can you please explain this? I don't see how this depth 0 lock would prevent anyone from updating the state of existing members. with all best wishes Jim From w3c-dist-auth-request@w3.org Mon Nov 29 11:06:23 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04882 for ; Mon, 29 Nov 1999 11:06:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA23648; Mon, 29 Nov 1999 10:51:32 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 10:51:32 -0500 (EST) Resent-Message-Id: <199911291551.KAA23648@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256838.0053260A.00@d54mta03.raleigh.ibm.com> Date: Mon, 29 Nov 1999 10:06:02 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Lost with links ... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3675 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list See comments below in tags... "Viktor Lioutyi" on 11/26/99 04:42:14 PM To: w3c-dist-auth@w3.org cc: "Lee Boal" Subject: Lost with links ... In our project we want to support persistency of our meta-data in a repository, based on WebDAV. We'd like to avoid fine-grain repositories because there is no a product of this type, running on different platforms. We'd like to use different WebDAV servers depending on our requirements and to protect ourselves from their differences via WebDAV protocol. We found that the following services from WebDAV are crucial for us: - naming service, properties, etc. (the whole WebDAV level-2) - versioning (Delta-V) - query service (DASL) - transactions - relationships In WebDAV level-2 there is something called links. In RFC2518 links are defined in paragraph 4.6 "Media Independent Links" "A WebDAV link is a special type of property value, formally defined in section 12.4, that allows typed connections to be established between resources of any media type." From 12.4 "Link XML Element" We suppose that these links are the closest notion in WebDAV that may be used to map relationships between models, but there are a lot of questions in respect to Delta-V and DASL. 1) Does a link include version information for "src" and "dsc" or "src" and "dst" will be resolved in a context of a workspace? The link does not include version information, and generally this would not be a good practice as it would require editing of the property and/or containing documents to change revisions of related resources. So these, and all other URL references would be resolved in the context of the workspace which would be inherited from the request. 2) Can I get part of the whole link back as result of a DASL query? For example, I'd like to know all destinations for particular source for particular kind of a link. I don't know DASL that well, but does it support regular expressions in matching strings like SQL? 3) Is there any intention to provide special operations for links? For example, I'd like to modify link. Is it required to download the whole link, change, then save or may I do incremental modifications (add/remove pairs (src, dst) from a link without downloading it)? Links are properties and may be modified with PROPPATCH. You'll have to use PROPFIND first if you need to modify an existing link. Thanks, Viktor From w3c-dist-auth-request@w3.org Mon Nov 29 11:25:46 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12917 for ; Mon, 29 Nov 1999 11:25:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA24418; Mon, 29 Nov 1999 11:11:01 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 11:11:01 -0500 (EST) Resent-Message-Id: <199911291611.LAA24418@www19.w3.org> Message-ID: <00ba01bf3a84$847f69e0$384413ac@lex.rational.com> From: "Geoffrey Clemm" To: References: <4.1.19991126002911.00b1bc50@pop.xs4all.nl> Date: Sun, 28 Nov 1999 13:37:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3676 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit From: Jim Davis > At 11:35 AM 11/24/99 -0500, Geoffrey M. Clemm wrote: > >... propose that the statement in question be modified to explicitly > >state "internal member", since depth:0 locks should only affect the > >addition and removal of internal members. > > internal members, as opposed to those added by, say, BIND? As opposed to members that are not internal members (where an internal member is as it is defined in rfc2518). For example, /a/b and /a/c are internal members of /a, while /a/b/x and /a/c/y are members of /a but are not internal members of /a. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Nov 29 11:26:37 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13083 for ; Mon, 29 Nov 1999 11:26:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA24523; Mon, 29 Nov 1999 11:11:57 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 11:11:57 -0500 (EST) Resent-Message-Id: <199911291611.LAA24523@www19.w3.org> Message-ID: <00bb01bf3a84$86115480$384413ac@lex.rational.com> From: "Geoffrey Clemm" To: References: Date: Sun, 28 Nov 1999 13:40:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: Write Locks on Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3677 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I agree with everything Greg says in this message. ----- Original Message ----- From: Greg Stein > On Fri, 26 Nov 1999, Jim Davis wrote: > >... > > If I lock a collection with depth infinity lock, then create a new > > interrnal member of that collection (e.g. with PUT) I have to provide the > > lock token to do the PUT, and the new internal member is added to the lock. > > > > We all agree on this, right? > > Yes. > > > Now suppose the lock were depth 0 not depth infinity. > > > > 1) to add a new internal member, I still have to provide the lock > > token, right? > > Right. > > > 2) Previously exising members are not affected. I can PUT or PROPPATCH to > > them at my whim, right? > > Right. > > > 3) However, I can't DELETE them without the lock token, right? > > Right. You must supply the locktoken because you are altering the > collection (on the theory that the set of names of internal members is > part of its state). > > > So where we seem to disagree is: > > > > If I add a new internal member, is it added to the lock, or not? > > It is not. > > > I interpret 7.5 as saying Yes. You seem to think that the answer is, or > > should be, no. > > > > Can you please explain this? I don't see how this depth 0 lock would > > prevent anyone from updating the state of existing members. > > The depth:0 lock does not prevent people from updating existing members. > It prevents you from altering the collections state: the set of names of > internal members. Therefore, you cannot add or remove internal members. > This means you must supply a locktoken with PUT, MKCOL, or a DELETE. Note > that you shouldn't be able to create a locknull resource either(!) without > supplying a locktoken. > From w3c-dist-auth-request@w3.org Mon Nov 29 11:28:40 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13496 for ; Mon, 29 Nov 1999 11:28:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA24500; Mon, 29 Nov 1999 11:11:18 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 11:11:18 -0500 (EST) Resent-Message-Id: <199911291611.LAA24500@www19.w3.org> Message-ID: <00bc01bf3a84$87c65780$384413ac@lex.rational.com> From: "Geoffrey Clemm" To: References: <85256835.006D514C.00@D51MTA03.pok.ibm.com> Date: Sun, 28 Nov 1999 13:48:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3678 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit From: > ... it seems somewhat odd that we use the IF header to determine > what locks are to be refreshed. I would think this should work just as UNLOCK > does. That's not to say people can't use an IF header, but that's not how > they specify which of the locks is to be refreshed. The IF header would only > be for consistancy checking if the client wanted the refresh to be contingent > on the presence of a specified lock on some specified resource. I agree with Jason (and others) that this would be the preferable way for a lock refresh to work. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Nov 29 11:29:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13847 for ; Mon, 29 Nov 1999 11:29:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA24773; Mon, 29 Nov 1999 11:15:53 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 11:15:53 -0500 (EST) Resent-Message-Id: <199911291615.LAA24773@www19.w3.org> Message-ID: <00bd01bf3a84$91054900$384413ac@lex.rational.com> From: "Geoffrey Clemm" To: References: <86256835.00774951.00@smtpmta2.i2.com> Date: Sun, 28 Nov 1999 14:04:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: Lost with links ... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3679 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit From: Viktor Lioutyi > 1) Does a link include version information for "src" and "dsc" or "src" and > "dst" will be resolved in a context of a workspace? I believe that the intent was for the src and dst of a link to be a URL. This URL could be: - a specific revision (in which case no versioning resolution is required) - a specific versioned resource (in which case either a workspace or a revision-id could be used to resolve the URL to a particular working resource or revision of the versioned resource) - a versioned resource that is identified by performing version selection on the versioned collections identified by prefixes of the URL (in which case a workspace must be used to resolve the URL to a particular working resource or revision). Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Nov 29 12:03:23 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00041 for ; Mon, 29 Nov 1999 12:03:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA26559; Mon, 29 Nov 1999 11:51:43 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 11:51:43 -0500 (EST) Resent-Message-Id: <199911291651.LAA26559@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey Clemm" cc: w3c-dist-auth@w3.org Message-ID: <85256838.005C94F1.00@D51MTA03.pok.ibm.com> Date: Mon, 29 Nov 1999 11:51:05 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3680 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Anyone that has a locking server or locking client (or knows of one) that would be significantly affected by this alteration or by any other locking changes, please send me a note or post it to this list. I'll add you to the locking mailing list. I just like to make sure I have a complete list of servers/clients (with email addresses) that are resistant to changes to locking due to 2518 compatibility issues and client base. --- note from Geoff Clemm follows ----- From: > ... it seems somewhat odd that we use the IF header to determine > what locks are to be refreshed. I would think this should work just as UNLOCK > does. That's not to say people can't use an IF header, but that's not how > they specify which of the locks is to be refreshed. The IF header would only > be for consistancy checking if the client wanted the refresh to be contingent > on the presence of a specified lock on some specified resource. I agree with Jason (and others) that this would be the preferable way for a lock refresh to work. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Nov 29 15:36:36 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02300 for ; Mon, 29 Nov 1999 15:36:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA03922; Mon, 29 Nov 1999 15:25:03 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 15:25:03 -0500 (EST) Resent-Message-Id: <199911292025.PAA03922@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256838.007019F6.00@D51MTA03.pok.ibm.com> Date: Mon, 29 Nov 1999 15:24:20 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3681 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Anyone that has a locking server or locking client (or knows of one) that would be significantly affected by this alteration or by any other locking changes, please send me a note or post it to this list. I'll add you to the locking mailing list. I just like to make sure I have a complete list of servers/clients (with email addresses) that are resistant to changes to locking due to 2518 compatibility issues and client base. Just in reply to my note above and something Kevin said subsequently about compatibility with clients. The transition path could be... Clients use both IF and token header for a while until servers have drifted to the new convention. After that, just token headers are used. Servers accept token header. If not there, they use the if header. Eventually the servers would just accept token headers. Noone would need to break. But I'd like to know if there is even a need for a transition strategy. From w3c-dist-auth-request@w3.org Mon Nov 29 20:39:59 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21921 for ; Mon, 29 Nov 1999 20:39:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA13847; Mon, 29 Nov 1999 20:18:10 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 20:18:10 -0500 (EST) Resent-Message-Id: <199911300118.UAA13847@www19.w3.org> Message-Id: <4.1.19991130012126.00b17750@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 Nov 1999 01:29:01 +0100 To: w3c-dist-auth@w3.org, www-webdav-dasl@w3.org From: Jim Davis In-Reply-To: <85256838.0053260A.00@d54mta03.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Lost with links ... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3682 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >"Viktor Lioutyi" on 11/26/99 04:42:14 PM Viktor - for questions about DASL you should write to www-webdav-dasl@w3.org I am cc'ing that list with my answers to your questions. >2) Can I get part of the whole link back as result of a DASL query? Yes. The result of a DASL query is a set of property values, it is just as if you did a PROPFIND on the resources that the query selects. But maybe that is not what you meant to ask. if you meant, "Can I write a query that selects all resources that have a link that is of certain type and whose destination is a certain URL" the answer is no not in the current DASL. DASL only allows queries that compare properties to constant string values, it does not provide a way to compare a portion of the XML value of a property. It does support a pattern match operator, similar to the LIKE operator of SQL. This is not as powerful as a regular expression though. thanks for your interest. for other email on dasl please use the dasl email list Jim From w3c-dist-auth-request@w3.org Mon Nov 29 20:40:18 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22044 for ; Mon, 29 Nov 1999 20:40:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA14000; Mon, 29 Nov 1999 20:18:42 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 20:18:42 -0500 (EST) Resent-Message-Id: <199911300118.UAA14000@www19.w3.org> Message-Id: <4.1.19991130013012.00ac3b70@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 Nov 1999 01:31:09 +0100 To: ccjason@us.ibm.com, "Geoffrey Clemm" From: Jim Davis Cc: w3c-dist-auth@w3.org In-Reply-To: <85256838.005C94F1.00@D51MTA03.pok.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: refresh LOCK for multiple locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3683 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 11:51 AM 11/29/99 -0500, ccjason@us.ibm.com wrote: > > >Anyone that has a locking server or locking client (or knows of one) that >would be significantly affected by this alteration or by any other >locking changes, please send me a note or post it to this list. I'll add >you to the locking mailing list. This change would not affect the Python WebDAV server, because it does not implement lock refreshing at all. From w3c-dist-auth-request@w3.org Mon Nov 29 20:40:19 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22060 for ; Mon, 29 Nov 1999 20:40:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA14018; Mon, 29 Nov 1999 20:18:46 -0500 (EST) Resent-Date: Mon, 29 Nov 1999 20:18:46 -0500 (EST) Resent-Message-Id: <199911300118.UAA14018@www19.w3.org> Message-Id: <4.1.19991130013916.00ac3740@pop.xs4all.nl> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 Nov 1999 02:10:26 +0100 To: w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: References: <4.1.19991125192837.00b04650@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3684 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 11:12 AM 11/26/99 -0800, Greg Stein wrote: >On Fri, 26 Nov 1999, Jim Davis wrote: >>... >> I read 7.5 as saying that even a depth zero lock is inherited, because it >> does not say "only depth infinity". You and others have asserted that this >> is bad. When I asked why, you said it causes problems for BIND. > >That's being a bit pedantic, don't you think? All right, so the RFC is >missing three words. Put them in and interpret it that way. Uh, actually no I don't think it's being pedantic. Could we please keep the discussion to logic and pragmatics? I don't object off hand to making a change (in the next draft) but I would like it to be noted as a *change* or at least a clarification in the meaning. It's possible that the authors actually had in mind that only depth infinity locks would be inherited, but that is not what the spec actually says. maybe it's a typo, or maybe it's a bad design decision, but neither you nor I are free to simply insert words that change the meaning just because we don't like the behavior as specified. The point of this conversation, and the testing experience with WebDAV is to find places where the spec is either a bad idea and should be changed, or is unclear. Just to remind you, at the start of this thread someone (G Slein, J Amsden, CC Jason or G Clemm, sorry I am not sure who though) asserted that if a depth 0 lock was inherited, something bad would happen. but upon challenge, no one has been able to say what that bad thing is. All you have said is that it's pedantic to interpret it that way. Look, I quote 7.5 If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock. It does not say "locked depth infinity" it just says "locked". If the authors had meant to restrict this to apply only to infinite-depth locked collection, they would have said so, no? Or perhaps the difficulty lies in the term "added to the lock"? I think this may be the source of the confusion. This really isn't pedantry, honest. I am not doing this just for the pleasure of arguing. I am doing this because i want a spec that's clear, so that any implementor can read it and know what to expect. I suspect that you guys interpret "added to the lock" as meaning something like "falling under the same protection as the other resources previously protected by it", which is to say protected from DELETE (because that changes the membership-state of the parent collection) but not from a (second) PUT. I interpret it as meaning "locked in the same manner as the original resource". Thus when patent collection P is exclusive write locked (at depth 0) with lock L and new resource R is added to that lock, then there are now two resources that lock L applies to, P and R. And just as one can not change P's state without passing L's token, neither can one change R. If this is not the correct interpretation, then we should add language to the spec to make this explicit. Is any one else on this list paying any attention to this? Or is it just the five of us? Hopefully we will soon straighten this out. From w3c-dist-auth-request@w3.org Tue Nov 30 01:17:03 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25543 for ; Tue, 30 Nov 1999 01:17:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA19834; Tue, 30 Nov 1999 00:59:13 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 00:59:13 -0500 (EST) Resent-Message-Id: <199911300559.AAA19834@www19.w3.org> Reply-To: <5chandlers@home.com> From: "David M. Chandler" <5chandlers@home.com> To: Date: Tue, 30 Nov 1999 00:02:42 -0800 Message-ID: <000101bf3b09$47e3f750$d6f00218@c786448-a.cdrrpd1.ia.home.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <4.1.19991130013916.00ac3740@pop.xs4all.nl> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: RE: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3685 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > Is any one else on this list paying any attention to this? > Or is it just > the five of us? Well, since you asked, yes, someone else is paying attention. For clarity, I think 7.5 should specify a depth infinity lock if that is in fact what the authors intended (I don't know whether that might be true). As far as the "bad" behavior which might result when newly-added children inherit depth-0 locks, I propose the following scenario. Please forgive me if this is obviously wrong. Suppose the following hierarchies of resources: a/ a/b a/b/d/ a/b/d/q a/b/d/r c/ c/j c/k Suppose a/b/ is write-locked depth 0. My understanding is that a/b/d and its members are not locked at this point. Now suppose we move collection /c with its members under /a/b, as in the example of 7.5. Now we have a/ a/b a/b/c/ a/b/c/j a/b/c/k a/b/d/ a/b/d/q a/b/d/r If we interpret 7.5 to mean that the write-locks are inherited even for depth 0, then /a/b/c becomes locked, but /a/b/d is not locked, which seems inconsistent to me because the lock has developed memory--pre-existing internal members are not locked, but newly-added ones are. Furthermore, what about new members of /a/b/c? Wouldn't /a/b/c/x and /a/b/c/y inherit the depth-0 write-lock from /a/b/c while /a/b/c/j and /a/b/c/k remain unlocked? It's the same case, just another level down. I think you could end up with a depth-0 lock locking some resources down to depth infinity by virtue of the fact they were added after /a/b/ was locked. Or I'm just completely lost, which is a real possibility. > Look, I quote 7.5 > > If a lock owner causes the URI of a resource to be added as an > internal member URI of a locked collection then the new resource MUST > be automatically added to the lock. This is the only > mechanism that allows a resource to be added to a write lock. Thus, for > example, if the collection /a/b/ is write locked and the resource /c > is moved to /a/b/c then resource /a/b/c will be added to the write lock. > > It does not say "locked depth infinity" it just says "locked". David Chandler From w3c-dist-auth-request@w3.org Tue Nov 30 10:43:55 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02299 for ; Tue, 30 Nov 1999 10:43:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA06617; Tue, 30 Nov 1999 10:29:25 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 10:29:25 -0500 (EST) Resent-Message-Id: <199911301529.KAA06617@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24504@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Tue, 30 Nov 1999 10:26:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3686 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The advanced collections design team has been debating whether to require the ordering semantics (DAV:orderingtype property) to be returned with every PROPFIND response for an ordered collection. The spec currently says that the server SHOULD return this property, whether or not the client explicitly requested it. It's likely that we'll either change this language to "MUST" or get rid of it altogether. On the one hand, it is a good thing for the client to be made aware that the PROPFIND response is ordered, so that the client can decide whether to override that ordering with its own. On the other hand, it seems like a bad idea to return random information that we think might (or should) be interesting to the client. Any opinions? --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Nov 30 13:06:22 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13085 for ; Tue, 30 Nov 1999 13:06:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13598; Tue, 30 Nov 1999 12:54:51 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 12:54:51 -0500 (EST) Resent-Message-Id: <199911301754.MAA13598@www19.w3.org> Message-ID: From: Mark Birbeck To: "'WebDAV'" Date: Tue, 30 Nov 1999 17:30:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id MAA13579 Subject: RE: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3687 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 8bit Slein, Judith A wrote: > On the one hand, it is a good thing for the client to be made > aware that the > PROPFIND response is ordered, so that the client can decide whether to > override that ordering with its own. > > On the other hand, it seems like a bad idea to return random > information > that we think might (or should) be interesting to the client. Just as a general approach, should we not favour the latter view? For a client that cannot or does not take notice of the order it is irrelevant information to receive anyway. And for the client that can order, they should ask for it. Otherwise, where do you stop adding info that you think should be significant? Regards, Mark Mark Birbeck Managing Director x-port.net Ltd. 220 Bon Marché Centre 241-251 Ferndale Road London SW9 8BJ w: http://www.iedigital.net/ t: +44 (171) 501 9502 e: Mark.Birbeck@iedigital.net From w3c-dist-auth-request@w3.org Tue Nov 30 13:12:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16721 for ; Tue, 30 Nov 1999 13:12:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA14215; Tue, 30 Nov 1999 13:00:55 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 13:00:55 -0500 (EST) Resent-Message-Id: <199911301800.NAA14215@www19.w3.org> Message-ID: <97FD7417E8C9D111AB4100805FADB6A203DDE2C5@pariah.cncx.com> From: Michael Hamilton To: "'Jim Davis'" , w3c-dist-auth@w3.org Date: Tue, 30 Nov 1999 09:57:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Subject: RE: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3688 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list How do I unsubscribe? -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Monday, November 29, 1999 5:10 PM To: w3c-dist-auth@w3.org Subject: Re: are depth 0 locks inherited by newly created children? At 11:12 AM 11/26/99 -0800, Greg Stein wrote: >On Fri, 26 Nov 1999, Jim Davis wrote: >>... >> I read 7.5 as saying that even a depth zero lock is inherited, because it >> does not say "only depth infinity". You and others have asserted that this >> is bad. When I asked why, you said it causes problems for BIND. > >That's being a bit pedantic, don't you think? All right, so the RFC is >missing three words. Put them in and interpret it that way. Uh, actually no I don't think it's being pedantic. Could we please keep the discussion to logic and pragmatics? I don't object off hand to making a change (in the next draft) but I would like it to be noted as a *change* or at least a clarification in the meaning. It's possible that the authors actually had in mind that only depth infinity locks would be inherited, but that is not what the spec actually says. maybe it's a typo, or maybe it's a bad design decision, but neither you nor I are free to simply insert words that change the meaning just because we don't like the behavior as specified. The point of this conversation, and the testing experience with WebDAV is to find places where the spec is either a bad idea and should be changed, or is unclear. Just to remind you, at the start of this thread someone (G Slein, J Amsden, CC Jason or G Clemm, sorry I am not sure who though) asserted that if a depth 0 lock was inherited, something bad would happen. but upon challenge, no one has been able to say what that bad thing is. All you have said is that it's pedantic to interpret it that way. Look, I quote 7.5 If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock. It does not say "locked depth infinity" it just says "locked". If the authors had meant to restrict this to apply only to infinite-depth locked collection, they would have said so, no? Or perhaps the difficulty lies in the term "added to the lock"? I think this may be the source of the confusion. This really isn't pedantry, honest. I am not doing this just for the pleasure of arguing. I am doing this because i want a spec that's clear, so that any implementor can read it and know what to expect. I suspect that you guys interpret "added to the lock" as meaning something like "falling under the same protection as the other resources previously protected by it", which is to say protected from DELETE (because that changes the membership-state of the parent collection) but not from a (second) PUT. I interpret it as meaning "locked in the same manner as the original resource". Thus when patent collection P is exclusive write locked (at depth 0) with lock L and new resource R is added to that lock, then there are now two resources that lock L applies to, P and R. And just as one can not change P's state without passing L's token, neither can one change R. If this is not the correct interpretation, then we should add language to the spec to make this explicit. Is any one else on this list paying any attention to this? Or is it just the five of us? Hopefully we will soon straighten this out. From w3c-dist-auth-request@w3.org Tue Nov 30 13:31:22 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25912 for ; Tue, 30 Nov 1999 13:31:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA16156; Tue, 30 Nov 1999 13:20:04 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 13:20:04 -0500 (EST) Resent-Message-Id: <199911301820.NAA16156@www19.w3.org> Date: Tue, 30 Nov 1999 10:15:18 -0800 From: Kevin Wiggen In-reply-to: <8E3CFBC709A8D21191A400805F15E0DBD24504@crte147.wc.eso.mc.xerox.com> To: "Slein, Judith A" , w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Priority: 3 (Normal) Subject: RE: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3689 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I have two thoughts on this proposal. They are below. THOUGHT 1: 1) ordered collections exist 2) If a client does not place or in its propfind or DASL query, then the server does not return the collection ordered. 3) If a client does request the or in propfind or DASL then the server returns the collection ordered. This is due to the fact that some clients will ignore any ordering that the server gives them. Therefore the server did more work than it had to do. My belief is that if the client wants the collections ordered, let them ask for them that way. If the client does not care, then the server can return normally. The SHOULD in the spec, mentioned below, will not help interoperability if it is left as a SHOULD. The client will never know whether the server is returning the collection ordered because some servers will say they are ordered, while others will not tell the client. I am not a fan of MUST, because the server will then ALWAYS do more work, even if the client will be ignoring the results. As I have mentioned, I think the best case is the client will ASK for the collection to be ordered if that is what it wants. ===================================== THOUGHT 2: When in DASL ordered collections will be a little weird no matter what. If the client asks for a specific order via the clause, does the server always append on the order of the collection as the last ordering. In other words, if I ask for and the query has an ordered collection (if we stick with how the spec reads), or has asked for if we go with my THOUGHT 1 proposal. Is the real order by clause This because we must do an implicit order by the collection? I believe an even better answer to this situation is to add clause to the propfind. In this way we generalized the problem, and turn it into a better solution. By the way, PROPFIND is a dumbed down DASL query so this works great. We then need to add a or something like it to the DASL and 2518 spec. Thus if a client wants the PROPFIND ordered in ANY way, including the ordered collections, they simply ask for it. There is no weird situations with ordered collections in DASL, everything works the same way, and server developers are developing to a spec that makes since through both 2518 and DASL. ====== I really like thought 2. I guess the biggest problem is that we need to get the clause into 2518 quickly so that we won't have backward compatibility problems. I think if we make this change now, we will kill the problem before it starts. On a somewhat separate note, I will probably one day push for the removal of PROPFIND, since DASL can do everything it can plus more :) Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Slein, Judith A Sent: Tuesday, November 30, 1999 7:26 AM To: 'WebDAV' Subject: Ordered Collections and PROPFIND Responses The advanced collections design team has been debating whether to require the ordering semantics (DAV:orderingtype property) to be returned with every PROPFIND response for an ordered collection. The spec currently says that the server SHOULD return this property, whether or not the client explicitly requested it. It's likely that we'll either change this language to "MUST" or get rid of it altogether. On the one hand, it is a good thing for the client to be made aware that the PROPFIND response is ordered, so that the client can decide whether to override that ordering with its own. On the other hand, it seems like a bad idea to return random information that we think might (or should) be interesting to the client. Any opinions? --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Nov 30 13:39:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00304 for ; Tue, 30 Nov 1999 13:39:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA16755; Tue, 30 Nov 1999 13:25:50 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 13:25:50 -0500 (EST) Resent-Message-Id: <199911301825.NAA16755@www19.w3.org> Message-ID: <011301bf3b60$793b93b0$9ef6a8c0@lex.rational.com> From: "Geoffrey Clemm" To: References: <4.1.19991125192837.00b04650@pop.xs4all.nl> <4.1.19991130013916.00ac3740@pop.xs4all.nl> Date: Tue, 30 Nov 1999 13:26:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3690 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit From: Jim Davis > Just to remind you, at the start of this thread someone (G Slein, J Amsden, > CC Jason or G Clemm, sorry I am not sure who though) asserted that if a > depth 0 lock was inherited, something bad would happen. but upon > challenge, no one has been able to say what that bad thing is. See In particular, this message says: I lock a collection, because I'm going to be adding members to that collection. If a depth:0 lock applies to all the immediate members of a collection as well, then I have prevented anyone from updating the state of one of the existing internal members of that collection. If I'd wanted that behavior, I would have issued a depth:1 lock. And quoting from the definition of what depth means: The Depth header is used with methods executed on resources which could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its immediate children, ("Depth: 1"), or the resource and all its progeny ("Depth: infinity"). Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Nov 30 15:42:52 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04008 for ; Tue, 30 Nov 1999 15:42:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA22939; Tue, 30 Nov 1999 15:00:17 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 15:00:17 -0500 (EST) Resent-Message-Id: <199911302000.PAA22939@www19.w3.org> Message-Id: <4.1.19991130115632.00aa8db0@shell7.ba.best.com> X-Sender: glyph-max@pplus.shell14.ba.best.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 Nov 1999 11:57:54 -0800 To: "'WebDAV'" From: Max Rible In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD24504@crte147.wc.eso.mc.x erox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3691 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 10:26 11/30/99 -0500, Slein, Judith A wrote: >The advanced collections design team has been debating whether to require >the ordering semantics (DAV:orderingtype property) to be returned with every >PROPFIND response for an ordered collection. The spec currently says that >the server SHOULD return this property, whether or not the client explicitly >requested it. > >It's likely that we'll either change this language to "MUST" or get rid of >it altogether. > >On the one hand, it is a good thing for the client to be made aware that the >PROPFIND response is ordered, so that the client can decide whether to >override that ordering with its own. > >On the other hand, it seems like a bad idea to return random information >that we think might (or should) be interesting to the client. I don't think ordering is random information. It's only a few handfuls of bytes to provide information that should be useful to an overwhelming number of clients (since I think WebDAV is going to see primary use as a network filesystem for quite some time to come). I agree with "MUST". -- %% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %% %% "Before enlightenment: sharpen claws, catch mice. %% %% After enlightenment: sharpen claws, catch mice." - me %% From w3c-dist-auth-request@w3.org Tue Nov 30 15:54:48 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09978 for ; Tue, 30 Nov 1999 15:54:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA24824; Tue, 30 Nov 1999 15:42:01 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 15:42:01 -0500 (EST) Resent-Message-Id: <199911302042.PAA24824@www19.w3.org> Message-ID: From: Mark Birbeck To: "'WebDAV'" Date: Tue, 30 Nov 1999 20:25:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: RE: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3692 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Max Rible wrote: > I don't think ordering is random information. It's only a > few handfuls > of bytes to provide information that should be useful to an > overwhelming > number of clients (since I think WebDAV is going to see primary use as > a network filesystem for quite some time to come). I agree with > "MUST". I'm using WebDAV for inter-server database updates. The server 'clients' are therefore *very* dumb - they don't care about collection ordering. Mark From w3c-dist-auth-request@w3.org Tue Nov 30 17:56:21 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10433 for ; Tue, 30 Nov 1999 17:56:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA00075; Tue, 30 Nov 1999 17:44:46 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 17:44:46 -0500 (EST) Resent-Message-Id: <199911302244.RAA00075@www19.w3.org> From: InfoNuovo@cs.com Message-ID: <0.879a5834.2575ad34@cs.com> Date: Tue, 30 Nov 1999 17:44:04 EST To: Geoffrey Clemm , w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Unknown (No Version) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id RAA00056 Subject: RE: are depth 0 locks inherited by newly created children? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3693 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 8bit Yes, I've been following this analysis too, and I concur that depth 0 locks stay on the resource, period. There should be no weird crossovers from depth:0 to depth:1 just because the resource is a collection. [I am afraid to ask what the implications are for creating a locked-null resource as an immediate child, but if it is a problem, I think the defect is in lock-null.] -- Dennis ------------------ Dennis E. Hamilton InfoNuovo mailto:infonuovo@email.com tel. +1-206-779-9430 (gsm) fax. +1-425-793-0283 http://www.infonuovo.com -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey Clemm Sent: Tuesday, November 30, 1999 10:27 To: w3c-dist-auth@w3.org Subject: Re: are depth 0 locks inherited by newly created children? [ ... ] I lock a collection, because I'm going to be adding members to that collection. If a depth:0 lock applies to all the immediate members of a collection as well, then I have prevented anyone from updating the state of one of the existing internal members of that collection. If I'd wanted that behavior, I would have issued a depth:1 lock. And quoting from the definition of what depth means: The Depth header is used with methods executed on resources which could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its immediate children, ("Depth: 1"), or the resource and all its progeny ("Depth: infinity"). Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Nov 30 19:58:50 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11863 for ; Tue, 30 Nov 1999 19:58:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA03068; Tue, 30 Nov 1999 19:47:57 -0500 (EST) Resent-Date: Tue, 30 Nov 1999 19:47:57 -0500 (EST) Resent-Message-Id: <199912010047.TAA03068@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "'WebDAV'" Message-ID: <8525683A.0004549D.00@D51MTA03.pok.ibm.com> Date: Tue, 30 Nov 1999 19:46:54 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Ordered Collections and PROPFIND Responses Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3694 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Until someone points out why this isn't good, I'm in the camp that says the server should only return the properties that the client requested.