BIND and write locks

From w3c-dist-auth-request@w3.org Mon Sep 1 06:56:44 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04013 for ; Mon, 1 Sep 2003 06:56:44 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 404D5A0660; Mon, 1 Sep 2003 06:55:28 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B9A12A0B75 for ; Mon, 1 Sep 2003 06:55:24 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 7795813C10; Mon, 1 Sep 2003 06:55:24 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by dr-nick.w3.org (Postfix) with ESMTP id CEA5113916 for ; Mon, 1 Sep 2003 06:55:23 -0400 (EDT) Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id h81AtK331785; Mon, 1 Sep 2003 12:55:21 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Sep 2003 12:55:20 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3c.org'" Date: Mon, 1 Sep 2003 12:55:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37077.8656A3F0" Subject: BIND and write locks X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C48060@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7840 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030901105528.404D5A0660@frink.w3.org> Resent-Date: Mon, 1 Sep 2003 06:55:28 -0400 (EDT) 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_01C37077.8656A3F0 Content-Type: text/plain; charset="iso-8859-1" I am trying to figure out, how write locks should behave WRT binding. Take the following scenario: - a collection C11 - a collection C1 containing a binding "foo" to C11 and mapped to URI "u1" - a resource R2 - a collection C2 containing a binding "b" to R2 and mapped to URI "u2" u1| C1 foo| |u2 C11 C2 |b R2 Now the following requests are issued (' marks locked resources): - LOCK /u1 (write, exclusive, depth=infinity) --> C11 is automatically added to the write-lock - PUT /u1/foo/a (passing locktoken) --> creates R1 which is added to the write-lock (RFC2518, Section 7.5) - BIND /u1/foo (b->/u2/b, passing locktoken) --> R2 is added to the write-lock (RFC2518, Section 7.5) u1| C1' foo| |u2 C11' C2 a| b\ |b R1' R2' - REBIND /u2 (a->/u1/foo/a, passing locktoken) --> R1 is removed from the write-lock (RFC2518, Section 7.7) u1| C1' foo| |u2 C11' C2 b\ |b \a R2' R1 The described behavior for BIND and REBIND is what I suppose it should be. Is it correct? BTW, what happens if, afterwards, the following UNLOCK on R2 is issued: - UNLOCK /u1/foo/b (passing locktoken) --> a) request is rejected, UNLOCK must be issued of C1 (/u1) or --> b) all associated resources (C1, C11, R2) are unlocked (RFC2518, Section 8.10.4) I suppose, that it is not possible to remove single resources from the write-lock by means of UNLOCK, isn't it? Thanks, Peter P.S.: At http://www.webdav.org/specs/ I found a link to http://ftp.ics.uci.edu/pub/ietf/webdav/collection/bind-issues.html, which contains the following entry: "ID: 41 Source: Reuter/Hunt Description: Specify how BIND interacts with a write lock. Status: Closed Resolution: Declined Locking semantics is in too confused a state currently to be able to make any reliable statements. Don't want to hold up binding spec till lock settles down." Is that still prevailing? ------_=_NextPart_001_01C37077.8656A3F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BIND and write locks

I am trying to figure out, how write locks should = behave WRT binding.

Take the following scenario:
- a collection C11
- a collection C1 containing a binding = "foo" to C11 and mapped to URI "u1"
- a resource R2
- a collection C2 containing a binding "b" = to R2 and mapped to URI "u2"

   u1|
     C1
foo|    |u2
    C11   C2
          = |b
          = R2

Now the following requests are issued (' marks locked = resources):
- LOCK /u1 (write, exclusive, = depth=3Dinfinity)
--> C11 is automatically added to the = write-lock
- PUT /u1/foo/a (passing locktoken)
--> creates R1 which is added to the = write-lock (RFC2518, Section 7.5)
- BIND /u1/foo (b->/u2/b, passing = locktoken)
--> R2 is added to the write-lock = (RFC2518, Section 7.5)

   u1|
     C1'
foo|    |u2
    C11' C2
    a| b\ |b
     R1' R2'

- REBIND /u2 (a->/u1/foo/a, passing = locktoken)
--> R1 is removed from the write-lock = (RFC2518, Section 7.7)

   u1|
     C1'
foo|    |u2
    C11' C2
       b\ |b \a
          R2' = R1

The described behavior for BIND and REBIND is what I = suppose it should be. Is it correct?

BTW, what happens if, afterwards, the following = UNLOCK on R2 is issued:
- UNLOCK /u1/foo/b (passing locktoken)
--> a) request is rejected, UNLOCK must be = issued of C1 (/u1)
or
--> b) all associated resources (C1, C11, = R2) are unlocked (RFC2518, Section 8.10.4)

I suppose, that it is not possible to remove single = resources from the write-lock by means of UNLOCK, isn't it?

Thanks,
Peter

P.S.:
At http://www.webdav.org/specs/ I found a link to http://ftp.ics.uci.edu/pub/ietf/webdav/collection/bind= -issues.html, which contains the following entry:

   "ID: 41
   Source: Reuter/Hunt
   Description: Specify how BIND interacts = with a write lock.
   Status: Closed
   Resolution: Declined
   Locking semantics is in too confused a = state currently to
   be able to make any reliable = statements. Don't want to hold
   up binding spec till lock settles = down."

Is that still prevailing?

------_=_NextPart_001_01C37077.8656A3F0-- From w3c-dist-auth-request@w3.org Mon Sep 1 22:28:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24685 for ; Mon, 1 Sep 2003 22:28:36 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 5BB12A0DB9; Mon, 1 Sep 2003 22:28:31 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 2B215A0DB9 for ; Mon, 1 Sep 2003 22:28:30 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C5DEC13EB7; Mon, 1 Sep 2003 22:28:22 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (Postfix) with ESMTP id ACA9113EB3 for ; Mon, 1 Sep 2003 22:28:22 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h822SMbe132140 for ; Mon, 1 Sep 2003 22:28:22 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h822SLUJ139154 for ; Mon, 1 Sep 2003 22:28:21 -0400 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 1 Sep 2003 22:28:15 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/01/2003 22:28:22, Serialize complete at 09/01/2003 22:28:22 Content-Type: multipart/alternative; boundary="=_alternative 000D84D485256D95_=" Subject: Re: BIND and write locks X-Archived-At: http://www.w3.org/mid/OF191B5874.82524F21-ON85256D95.000CEAFA-85256D95.000D9281@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7841 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030902022831.5BB12A0DB9@frink.w3.org> Resent-Date: Mon, 1 Sep 2003 22:28:31 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 000D84D485256D95_= Content-Type: text/plain; charset="US-ASCII" Peter wrote on 09/01/2003 06:55:15 AM: > I am trying to figure out, how write locks should behave WRT binding. > Take the following scenario: > - a collection C11 > - a collection C1 containing a binding "foo" to C11 and mapped to URI "u1" > - a resource R2 > - a collection C2 containing a binding "b" to R2 and mapped to URI "u2" > u1| > C1 > foo| |u2 > C11 C2 > |b > R2 > Now the following requests are issued (' marks locked resources): > - LOCK /u1 (write, exclusive, depth=infinity) > --> C11 is automatically added to the write-lock > - PUT /u1/foo/a (passing locktoken) > --> creates R1 which is added to the write-lock (RFC2518, Section 7.5) > - BIND /u1/foo (b->/u2/b, passing locktoken) > --> R2 is added to the write-lock (RFC2518, Section 7.5) > u1| > C1' > foo| |u2 > C11' C2 > a| b\ |b > R1' R2' > - REBIND /u2 (a->/u1/foo/a, passing locktoken) > --> R1 is removed from the write-lock (RFC2518, Section 7.7) > u1| > C1' > foo| |u2 > C11' C2 > b\ |b \a > R2' R1 > The described behavior for BIND and REBIND is what I suppose it > should be. Is it correct? Yes. > BTW, what happens if, afterwards, the following UNLOCK on R2 is issued: > - UNLOCK /u1/foo/b (passing locktoken) > --> a) request is rejected, UNLOCK must be issued of C1 (/u1) > or > --> b) all associated resources (C1, C11, R2) are unlocked > (RFC2518, Section 8.10.4) Several of us have strongly advocated (a), to avoid a client mistakenly unlocking a whole tree of resources when they intended to unlock a single resource. I don't believe this has been resolved though. > I suppose, that it is not possible to remove single resources from > the write-lock by means of UNLOCK, isn't it? That is correct, it is not possible. > P.S.: > At http://www.webdav.org/specs/ I found a link to http://ftp.ics. > uci.edu/pub/ietf/webdav/collection/bind-issues.html, which contains > the following entry: > "ID: 41 > Source: Reuter/Hunt > Description: Specify how BIND interacts with a write lock. > Status: Closed > Resolution: Declined > Locking semantics is in too confused a state currently to > be able to make any reliable statements. Don't want to hold > up binding spec till lock settles down." > Is that still prevailing? No, that is an obsolete document, and it (and any links to it) should be removed. The current bind issues document is: http://www.webdav.org/bind/bind-issues-list.htm Cheers, Geoff --=_alternative 000D84D485256D95_= Content-Type: text/html; charset="US-ASCII"
Peter wrote on 09/01/2003 06:55:15 AM: > I am trying to figure out, how write locks should behave WRT binding.
> Take the following scenario: > - a collection C11 > - a collection C1 containing a binding "foo" to C11 and mapped to URI "u1" > - a resource R2 > - a collection C2 containing a binding "b" to R2 and mapped to URI "u2"
> u1| > C1 > foo| |u2 > C11 C2 > |b > R2
> Now the following requests are issued (' marks locked resources): > - LOCK /u1 (write, exclusive, depth=infinity) > --> C11 is automatically added to the write-lock > - PUT /u1/foo/a (passing locktoken) > --> creates R1 which is added to the write-lock (RFC2518, Section 7.5) > - BIND /u1/foo (b->/u2/b, passing locktoken) > --> R2 is added to the write-lock (RFC2518, Section 7.5)
> u1| > C1' > foo| |u2 > C11' C2 > a| b\ |b > R1' R2'
> - REBIND /u2 (a->/u1/foo/a, passing locktoken) > --> R1 is removed from the write-lock (RFC2518, Section 7.7)
> u1| > C1' > foo| |u2 > C11' C2 > b\ |b \a > R2' R1
> The described behavior for BIND and REBIND is what I suppose it > should be. Is it correct?

Yes.

> BTW, what happens if, afterwards, the following UNLOCK on R2 is issued: > - UNLOCK /u1/foo/b (passing locktoken) > --> a) request is rejected, UNLOCK must be issued of C1 (/u1) > or > --> b) all associated resources (C1, C11, R2) are unlocked > (RFC2518, Section 8.10.4)

Several of us have strongly advocated (a), to avoid a client mistakenly
unlocking a whole tree of resources when they intended to unlock a
single resource. I don't believe this has been resolved though.

> I suppose, that it is not possible to remove single resources from > the write-lock by means of UNLOCK, isn't it?

That is correct, it is not possible.

> P.S.: > At http://www.webdav.org/specs/ I found a link to http://ftp.ics. > uci.edu/pub/ietf/webdav/collection/bind-issues.html, which contains > the following entry:
> "ID: 41 > Source: Reuter/Hunt > Description: Specify how BIND interacts with a write lock. > Status: Closed > Resolution: Declined > Locking semantics is in too confused a state currently to > be able to make any reliable statements. Don't want to hold > up binding spec till lock settles down."
> Is that still prevailing?

No, that is an obsolete document, and it (and any links to it) should
be removed. The current bind issues document is:

http://www.webdav.org/bind/bind-issues-list.htm

Cheers,
Geoff
--=_alternative 000D84D485256D95_=-- From w3c-dist-auth-request@w3.org Tue Sep 2 15:42:43 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01131 for ; Tue, 2 Sep 2003 15:42:42 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id A6B43A0E8C; Tue, 2 Sep 2003 15:42:44 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 20CFEA0E8C for ; Tue, 2 Sep 2003 15:42:43 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 9248413343; Tue, 2 Sep 2003 15:40:55 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (Postfix) with ESMTP id 360D6133A9 for ; Tue, 2 Sep 2003 15:40:55 -0400 (EDT) Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h82JdIf10134 for ; Tue, 2 Sep 2003 12:39:18 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 2 Sep 2003 12:41:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0ABB_01C3714F.76F7EB20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: [Moderator Action] Re: WebDAV and WindowsXP X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMICEKFJAAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7842 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030902194244.A6B43A0E8C@frink.w3.org> Resent-Date: Tue, 2 Sep 2003 15:42:44 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_0ABB_01C3714F.76F7EB20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Chattey, Corey (LNG-BIN) [mailto:Corey.Chattey@lexisnexis.com] Sent: Friday, August 22, 2003 11:41 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] Re: WebDAV and WindowsXP Hi...I'm having the same problem. It's working fine under Web folders but my Adobe applications which embrace WebDAV so well no longer function in Windows XP. Have you found a solution yet? Any help would be much appreciated. Corey Chattey Electronic Production Associate corey.chattey@lexisnexis.com Toll Free: 800-323-9608, ext. 2628 Direct: 607-772-2628 http://www.lexisnexis.com Matthew Bender A Member of the LexisNexis Group NALM ------=_NextPart_000_0ABB_01C3714F.76F7EB20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Accidentally caught by the spam filter.

-=20 Jim

-----Original Message-----
From: Chattey, Corey = (LNG-BIN)=20 [mailto:Corey.Chattey@lexisnexis.com]
Sent: Friday, August 22, = 2003=20 11:41 PM
To: 'w3c-dist-auth@w3.org'
Subject: = [Moderator=20 Action] Re: WebDAV and WindowsXP

Hi...I'm having the same=20 problem. It's working = fine under=20 Web folders but my Adobe applications which embrace WebDAV so well no = longer=20 function in Windows XP. Have you=20 found a solution yet?

Any help would be much=20 appreciated.

Corey=20 Chattey
Electronic Production=20 Associate
corey.chattey@lexisnexis.com
Toll = Free:=20 800-323-9608, ext. 2628
Direct:=20 607-772-2628
http://www.lexisnexis.com

Matthew=20 Bender
A=20 Member of the LexisNexis Group

NALM

------=_NextPart_000_0ABB_01C3714F.76F7EB20-- From w3c-dist-auth-request@w3.org Thu Sep 4 12:57:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07261 for ; Thu, 4 Sep 2003 12:57:06 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id ECCCAA0AC7; Thu, 4 Sep 2003 12:56:26 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6B690A0B80 for ; Thu, 4 Sep 2003 12:56:13 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 2899413720; Thu, 4 Sep 2003 12:56:13 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from nebula.lyra.org (us-1.i3.intermud.org [198.144.203.194]) by dr-nick.w3.org (Postfix) with ESMTP id CB03313751 for ; Thu, 4 Sep 2003 12:56:12 -0400 (EDT) Received: from localhost.localdomain (nebula.lyra.org [127.0.0.1]) by nebula.lyra.org (8.12.8/8.12.8) with ESMTP id h84H6NTq007452 for ; Thu, 4 Sep 2003 10:06:23 -0700 Date: Thu, 4 Sep 2003 10:06:23 -0700 Message-Id: <200309041706.h84H6NTq007452@nebula.lyra.org> From: gstein@lyra.org To: w3c-dist-auth@w3.org Subject: received your email X-Archived-At: http://www.w3.org/mid/200309041706.h84H6NTq007452@nebula.lyra.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7843 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030904165626.ECCCAA0AC7@frink.w3.org> Resent-Date: Thu, 4 Sep 2003 12:56:26 -0400 (EDT) Hi, [ Re: Thank you! ] I have received your email, but it may take a while to respond. I'm really sorry to have to hook up this auto-responder, as it is so impersonal. However, I get a lot of email every day and find it very difficult to keep up with it. Please be patient while I try to get to your message. Please feel free to resend your message if you think I've missed it. I'll always respond to personal email first. If your email is regarding some of the software that I work on (if you have questions, comments, suggestions, etc), then please resend it to the appropriate mailing list: mod_dav WebDAV ViewCVS Subversion edna Thank you! Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Sep 4 18:42:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28865 for ; Thu, 4 Sep 2003 18:42:29 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 333C0A0808; Thu, 4 Sep 2003 18:42:34 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 4E392A0C97 for ; Thu, 4 Sep 2003 18:42:17 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 1FE16138D8; Thu, 4 Sep 2003 18:42:17 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id DBB97138C8 for ; Thu, 4 Sep 2003 18:42:16 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19v2nw-0007uq-00 for w3c-dist-auth@w3c.org; Thu, 04 Sep 2003 22:42:16 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19v2nv-0007ud-00 for w3c-dist-auth@w3c.org; Thu, 04 Sep 2003 22:42:16 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Thu, 4 Sep 2003 15:43:10 -0700 Message-ID: <007701c37335$ef582ca0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: Notes from Vienna meeting X-Archived-At: http://www.w3.org/mid/007701c37335$ef582ca0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7844 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030904224234.333C0A0808@frink.w3.org> Resent-Date: Thu, 4 Sep 2003 18:42:34 -0400 (EDT) Content-Transfer-Encoding: quoted-printable It seems I entirely forgot to post the meeting notes from the WG = meeting. The meeting mostly consisted of me reporting on progress made = on the mailing lists. I put together the notes myself as well as giving = the status so I'd appreciate review for errors. =20 Lisa --- WebDAV Working Group Vienna IETF=20 July 2003 AGENDA =E2=80=93 Interop plans =E2=80=93 5 min =E2=80=93 Various draft status =E2=80=93 ACL progress =E2=80=93 RFC2518bis issues =E2=80=93 Possible SIP needs VARIOUS DRAFT STATUS Ordering =E2=80=93 Minor nits but approved by IESG =E2=80=93 Last check on specific changes Binding =E2=80=93 Still requires significant explanation if not changes Search =E2=80=93 Minor progress ACL PROGRESS Addressed IESG review issues Issue: too many possible semantics - Resolution: chose one=20 Issue: hard for clients to tell what ACL server will allow =E2=80=93 Resolution: added acl-semantics info property Issue: no clear privilege for DELETE method =E2=80=93 Resolution: added =E2=80=98unbind=E2=80=99 privilege Issue: allows insecure =E2=80=98Basic=E2=80=99 auth =E2=80=93 Resolution: =E2=80=9CImplementation of the ACL spec requires=20 that Basic authentication, if used, MUST only be=20 supported over secure transport such as TLS.=E2=80=9D Attempt to make mapping between methods and permissions more clear The =E2=80=9Cwho am I=E2=80=9D request header, response header contains = answer RFC2518 BIS ISSUES DTD usage =E2=80=93 Do we include DTDs at all =E2=80=93 Do we use content ANY or content a specific list of child = elements =E2=80=93 How do we show/enforce extensibility? =E2=80=93 How do we show namespace usage (e.g. on attributes)? =E2=80=93 ELEMENT foo | ns (bar, baz?, ANY) 207 response to DELETE failures =E2=80=93 Again=E2=80=A6 =E2=80=93 Keep or toss=09 Stronger requirement for ETag support =E2=80=93 Still not MUST From w3c-dist-auth-request@w3.org Thu Sep 4 19:55:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03158 for ; Thu, 4 Sep 2003 19:55:55 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id CC000A05C6; Thu, 4 Sep 2003 19:55:59 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9D86CA05C6 for ; Thu, 4 Sep 2003 19:55:38 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 5BC5A13871; Thu, 4 Sep 2003 19:55:38 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (Postfix) with ESMTP id 5879C13973 for ; Thu, 4 Sep 2003 19:55:05 -0400 (EDT) Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h84Nr1f26184; Thu, 4 Sep 2003 16:53:01 -0700 (PDT) From: "Jim Whitehead" To: , "WebDAV" Date: Thu, 4 Sep 2003 16:54:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-UCSC-CATS-MailScanner: Found to be clean Subject: Reminder: WebDAV Interop. Event, Sept. 15-16 X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMICEKPJBAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7845 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030904235559.CC000A05C6@frink.w3.org> Resent-Date: Thu, 4 Sep 2003 19:55:59 -0400 (EDT) Content-Transfer-Encoding: 7bit Just a quick reminder that we're holding a face-to-face interoperability testing event September 15-16, 2003, in the Baskin Engineering Building at UC Santa Cruz, in Santa Cruz, California. Right now we have confirmed attendees from Oracle, Xythos, Microsoft, Software AG, Sun, Sambar, Apple, NASA Ames, and UCSC. There's still room for additional participants, and we encourage testing of both development and shipping code. More details can be found here: http://www.webdav.org/other/interop03/ If you're planning on attending, and haven't yet registered, please send me an email, so we get an accurate count so we have enough food and network taps. - Jim Whitehead ejw@cs.ucsc.edu From w3c-dist-auth-request@w3.org Thu Sep 4 19:59:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03372 for ; Thu, 4 Sep 2003 19:59:40 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7C625A0C1E; Thu, 4 Sep 2003 19:59:43 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5AAB0A0BD2 for ; Thu, 4 Sep 2003 19:59:24 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 0DF28136F5; Thu, 4 Sep 2003 19:59:24 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (Postfix) with ESMTP id DCFF5137EE for ; Thu, 4 Sep 2003 19:59:18 -0400 (EDT) Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h84Nv6f27882 for ; Thu, 4 Sep 2003 16:57:07 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 4 Sep 2003 16:58:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0352_01C37305.CFFCFC80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: Partial Property Data Retrieval??? X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMEKPJBAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7846 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030904235943.7C625A0C1E@frink.w3.org> Resent-Date: Thu, 4 Sep 2003 19:59:43 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_0352_01C37305.CFFCFC80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Frank's email to the accept2 list. - Jim -----Original Message----- From: Frank Judge [mailto:Frank.Judge@corp.palm.com] Sent: Thursday, September 04, 2003 4:37 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Partial Property Data Retrieval??? Hi, I've read over the specifications and want to know if I'm missing something or if you considered a capability. For properties in a schema that have large amounts of data, does WebDAV specify a means to retrieve only portions of that data? For example, if you have a document object that has only a text property containing all the document data, you may only want the first 100K of a 10 megabyte document. For email the POP and IMAP protocols allow subsets of the message data to be retrieved ( POP TOP command for instance ). Have you thought of allowing retrieval of only a subset of property data, and if you have could you point me to the reference that shows how? Thanks, Frank Judge Palm Inc. frank.judge@corp.palm.com ------=_NextPart_000_0352_01C37305.CFFCFC80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Accidentally caught by the spam filter. I've = added=20 Frank's email to the accept2 list.

-=20 Jim

-----Original Message-----
From: Frank Judge=20 [mailto:Frank.Judge@corp.palm.com]
Sent: Thursday, September = 04, 2003=20 4:37 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action]=20 Partial Property Data Retrieval???

Hi,

I've = read over the=20 specifications and want to know if I'm missing something or if you = considered a=20 capability. For properties in a schema that have large amounts of = data,=20 does WebDAV specify a means to retrieve only portions of that = data? For=20 example, if you have a document object that has only = a text=20 property containing all the document data, you may only want the = first 100K=20 of a 10 megabyte document. For email the POP and IMAP = protocols allow=20 subsets of the message data to be retrieved ( POP TOP command for = instance=20 ). Have you thought of allowing retrieval of only a subset of = property=20 data, and if you have could you point me to the reference that shows=20 how?

Thanks,

Frank=20 Judge

Palm=20 Inc.

frank.judge@corp.palm.com

<= /BODY> ------=_NextPart_000_0352_01C37305.CFFCFC80-- From w3c-dist-auth-request@w3.org Fri Sep 5 06:55:35 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13826 for ; Fri, 5 Sep 2003 06:55:25 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C2B24A0D54; Fri, 5 Sep 2003 06:55:20 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B5B56A0D54 for ; Fri, 5 Sep 2003 06:55:01 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 72D251383B; Fri, 5 Sep 2003 06:55:01 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 085B813596 for ; Fri, 5 Sep 2003 06:55:01 -0400 (EDT) Received: (qmail 4836 invoked by uid 65534); 5 Sep 2003 10:55:00 -0000 Received: from p3EE24718.dip.t-dialin.net (HELO lisa) (62.226.71.24) by mail.gmx.net (mp005) with SMTP; 05 Sep 2003 12:55:00 +0200 From: "Julian Reschke" To: "Horst Liermann" , "'Julian Reschke'" , "'Webdav WG'" Date: Fri, 5 Sep 2003 12:54:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-reply-to: <077097E85A6BD3119E910800062786A905121EBA@muc-mail5.ixos.de> Subject: RE: new issue: DAV:displayname X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEPBIFAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7847 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905105520.C2B24A0D54@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 06:55:20 -0400 (EDT) Content-Transfer-Encoding: 7bit Here's some more info on DAV:displayname vs Microsoft clients: There are at least two different types of webfolder clients: those shipping with W2K and O2K (DLL version 8.*) completely ignore DAV:displayname. Those shipping with Windows XP, Office XP and Sharepoint do "support" DAV:displayname, but have multiple bugs in doing so: : "The URI displayed in the "internet adress" column is constructed from the base URI of the collection and the resource's DAV:displayname property (when present). This is wrong - the column should display the DAV:href returned in the PROPFIND response body." "The Webfolder client displays the DAV:displayname only if it doesn't contain some characters that happen to be reserved in filenames (such as "/"). However, the displayname is just a textual description, so it should be displayable no matter what kind of text it contains (basically this is caused by the Webfolder mistaking the displayname to be some kind of replacement resource name)." "If the client decides to use the DAV:displayname instead of the last path segment for display, it seems to internally confuse both. A rename operation on a resource where the displayname and the last path segment differ fails because the client submits the MOVE request to a broken request URI (collection href and displayname concatenated)." If you are aware of more issues, please report them (so I'll can put them into the issues list). Also it would be nice to get some feedback about which issue appears in which client (obviously I can't test them all :-) Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Horst Liermann > Sent: Monday, August 18, 2003 3:53 PM > To: 'Julian Reschke'; 'Webdav WG' > Subject: RE: new issue: DAV:displayname > > > > Hi, > > I have installed "MS Sharepoint" and I tested the behavior of Sharepoint. > Sharepoint is a basic WebDAV implementation. They have something like > versioning, but it's not DeltaV. > > As far as I understand MS-Sharepoint, the behavior is: > > There is a URL "segment name" for the name of the resource. > There is a DAV:displayname for the "title" of the resource. > > DAV:displayname normaly is not the same as the "segment name". So > DAV:displayname is a "dead" property > It's also possible NOT setting the property DAV:displayname. > > Behavior is like 2). > > > Horst > > > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Sunday, August 17, 2003 1:03 PM > To: 'Webdav WG' > Subject: new issue: DAV:displayname > > > > Hi, > > looking at our recent discussion, I feel that we clearly have a > problem with > the usage of DAV:displayname. > > The current situation seems to be: > > 1) Some servers implement DAV:displayname as protected live property that > just reflects the last name segment of the request URI (Microsoft IIS) > > 2) Other servers implement DAV:displayname as dead property that > by default > is not set until it get's explicitly set by a client (Apache moddav) > > > We are currently discussing whether 1) is ok. My position is that it's > clearly not, as > > - the value of the last path segment is not "a description of the resource > that is suitable for presentation to a user", > > - replicating something that's already available from the > element of > the PROPFIND response into a property just has no benefit at all, > > - clients demonstratibly can cope with absent DAV:displayname values (as > they all interoperate with Apache moddav today) and finally > > - the concept of a property that varies with the request URI is deeply > incompatible with the concept of multiple bindings to resources. > > > So my preference would be just to state that DAV:displayname SHOULD NOT be > used to replicate the information from the last path segment. > > Another alternative would be to *deprecate* DAV:displayname and > to define a > new property with more precisely defined semantics, such as > DAV:description. > > > Note that this in fact *is* a interoperability issues, as we are getting > lots of complaints from users not being able to set display names on some > remote WebDAV servers mounted into the SAP Enterprise Portal. > > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Fri Sep 5 07:17:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14806 for ; Fri, 5 Sep 2003 07:17:57 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id AEEFDA0D3A; Fri, 5 Sep 2003 07:18:00 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 09256A0B7B for ; Fri, 5 Sep 2003 07:17:42 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 95D5B13A4C; Fri, 5 Sep 2003 07:17:41 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 2C08813A3B for ; Fri, 5 Sep 2003 07:17:41 -0400 (EDT) Received: (qmail 29709 invoked by uid 65534); 5 Sep 2003 11:17:40 -0000 Received: from p3EE24718.dip.t-dialin.net (HELO lisa) (62.226.71.24) by mail.gmx.net (mp012) with SMTP; 05 Sep 2003 13:17:40 +0200 From: "Julian Reschke" To: "'Webdav WG'" Date: Fri, 5 Sep 2003 13:17:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-reply-to: <077097E85A6BD3119E910800062786A905121EBA@muc-mail5.ixos.de> Subject: call for participation: roundtripping of WebDAV properties in filesystems X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEPCIFAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7848 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905111800.AEEFDA0D3A@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 07:18:00 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, I got interested in this issue by some comments in Jim's article "The WebDAV property design" [1] and discussion on the Subversion mailing list about NTFS features. The problem(s): (a) resources copied to a local file system generally loose their WebDAV property information, thus they won't round-trip when the resource is PUT back to a WebDAV server (b) WebDAV clients mapping servers to filesystems generally can't map the properties to something a filesystem-based client can take advantage of. The issues: (1) Where to store the property information. The only portable solution involves exposing a second file somewhere else in the namespace (such as by appending a particular extension). In general, this is ugly due to possible name collisions, and the fact that the properties will not automatically move with the base file. Filesystems that offer multiple data streams or data forks may do better (see below for some information about NTFS data streams). (2) Which format to use. I think there's some hope in getting interoperability if we can get the client developers (such as MS, Xythos, Apply, davfs Linux developers) to get together (such as during the Interop event). Possible solutions: (1) This problem is hard in general but almost trivial for WIN32 scenarios. NTFS supports multiple data streams that can be accessed with generic file syntax (see [2]). All we'd need to do is to agree on a well-known name for the stream (such as ":dav-properties"). (2) Let's just use the XML serialization of the DAV:prop element from a PROPFIND/allprop response body. Proof-of-concept: Below is a script for Windows Scripting Host that GETs/PROPFINDs a resource and stores the properties in the named data stream ":dav-properties". You can see the properties by just opening the data stream like a regular file, such as cat filename:dav-properties Usage: cscript davget.js URL destination-file user password -- // davget.js // GET a file from an HTTP server, storing it's properties in a NTFS data stream // params: URL localfile user password var fso = new ActiveXObject("Scripting.FileSystemObject"); var http = new ActiveXObject("MSXML2.ServerXMLHTTP.3.0"); var stream = new ActiveXObject("ADODB.Stream"); var url = WScript.Arguments(0); // PROPFIND http.open("PROPFIND", url, false, WScript.Arguments(2), WScript.Arguments(3)); http.setRequestHeader("Depth", "0"); http.send(""); if (http.status != 207) { WScript.Echo("unexpected status from PROPFIND: " + http.status); WScript.Quit(1); } var props = new ActiveXObject("MSXML2.DOMDocument"); http.responseXML.setProperty("SelectionLanguage", "XPath"); http.responseXML.setProperty("SelectionNamespaces", "xmlns:D='DAV:'"); props.appendChild( http.responseXML.selectSingleNode("/D:multistatus/D:response/D:propstat[cont ains(D:status,'200')]/D:prop")); http.open("GET", url, false, WScript.Arguments(2), WScript.Arguments(3)); http.send(); if (http.status != 200) { WScript.Echo("unexpected status from GET: " + http.status); WScript.Quit(1); } stream.open(); stream.Type = 1; try { if (http.responseText.length > 0) { stream.Write(http.responseBody); } } catch (e) { WScript.Echo("empty content? " + e); } stream.SaveToFile(WScript.Arguments(1), 2); stream.close(); stream.open(); stream.Type = 1; props.save(stream); stream.SaveToFile(WScript.Arguments(1) + ":dav-props", 2); stream.close(); -- Feedback appreciated, Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 5 10:19:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25822 for ; Fri, 5 Sep 2003 10:19:26 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 28BE1A0E28; Fri, 5 Sep 2003 10:19:31 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DBF64A0E28 for ; Fri, 5 Sep 2003 10:19:11 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 70A5113B23; Fri, 5 Sep 2003 10:19:11 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by dr-nick.w3.org (Postfix) with ESMTP id 54C1213B09 for ; Fri, 5 Sep 2003 10:19:11 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h85EJBGh402716 for ; Fri, 5 Sep 2003 10:19:11 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h85EJ9LA064454 for ; Fri, 5 Sep 2003 10:19:10 -0400 In-Reply-To: <007701c37335$ef582ca0$f8cb90c6@lisalap> To: "Webdav WG" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 5 Sep 2003 10:18:59 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 10:19:10, Serialize complete at 09/05/2003 10:19:10 Content-Type: multipart/alternative; boundary="=_alternative 004EA47A85256D98_=" Subject: Re: Notes from Vienna meeting X-Archived-At: http://www.w3.org/mid/OFC24B4E96.DE4EED36-ON85256D98.004E05F3-85256D98.004EA47F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7849 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905141931.28BE1A0E28@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 10:19:31 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 004EA47A85256D98_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgb25seSBvbmUgb3BlbiBpc3N1ZSBpbiB0aGUgYmluZGluZyBkcmFmdDoNCjxodHRw Oi8vd3d3LndlYmRhdi5vcmcvYmluZC9iaW5kLWlzc3Vlcy1saXN0Lmh0bT4gNS4xX0xPT1BfU1RB VFVTLg0KDQpJZiBzb21lYm9keSBiZWxpZXZlcyB0aGF0IHNvbWV0aGluZyBpbiB0aGUgZHJhZnQg c3RpbGwgcmVxdWlyZXMNCnNpZ25pZmljYW50IGV4cGxhbmF0aW9uIChvciBjaGFuZ2VzKSwgdGhl eSBuZWVkIHRvIGlkZW50aWZ5IGl0DQpzbyB3ZSBjYW4gYWRkIGl0IHRvIHRoZSBiaW5kLWlzc3Vl cy1saXN0LiAgSWYgbm90LCB0aGUgc3RhdHVzIA0KZm9yIHRoZSBiaW5kaW5nIHByb3RvY29sIHNo b3VsZCBiZSB1cGRhdGVkIHRvIHN0YXRlICJvbmx5IG9uZQ0KaXNzdWUgcmVtYWluaW5nIHRvIGJl IHJlc29sdmVkIGZvciBsYXN0IGNhbGwiLg0KDQpDaGVlcnMsDQpHZW9mZg0KDQoNCkxpc2Egd3Jv dGUgb24gMDkvMDQvMjAwMyAwNjo0MzoxMCBQTToNCg0KPiBXZWJEQVYgV29ya2luZyBHcm91cA0K PiBWaWVubmEgSUVURiANCj4gSnVseSAyMDAzDQo+IA0KPiBWQVJJT1VTIERSQUZUIFNUQVRVUw0K Li4uDQo+IEJpbmRpbmcNCj4g4oCTICAgU3RpbGwgcmVxdWlyZXMgc2lnbmlmaWNhbnQgZXhwbGFu YXRpb24gaWYgbm90IGNoYW5nZXMNCg0K --=_alternative 004EA47A85256D98_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5UaGVyZSBpcyBvbmx5IG9uZSBvcGVuIGlzc3VlIGluIHRo ZSBiaW5kaW5nIGRyYWZ0OjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmx0O2h0 dHA6Ly93d3cud2ViZGF2Lm9yZy9iaW5kL2JpbmQtaXNzdWVzLWxpc3QuaHRtJmd0Ow0KNS4xX0xP T1BfU1RBVFVTLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SWYgc29t ZWJvZHkgYmVsaWV2ZXMgdGhhdCBzb21ldGhpbmcgaW4gdGhlIGRyYWZ0IHN0aWxsDQpyZXF1aXJl czwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+c2lnbmlmaWNhbnQgZXhwbGFuYXRp b24gKG9yIGNoYW5nZXMpLCB0aGV5IG5lZWQgdG8NCmlkZW50aWZ5IGl0PC90dD48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yPjx0dD5zbyB3ZSBjYW4gYWRkIGl0IHRvIHRoZSBiaW5kLWlzc3Vlcy1s aXN0LiAmbmJzcDtJZg0Kbm90LCB0aGUgc3RhdHVzIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNp emU9Mj48dHQ+Zm9yIHRoZSBiaW5kaW5nIHByb3RvY29sIHNob3VsZCBiZSB1cGRhdGVkIHRvIHN0 YXRlDQomcXVvdDtvbmx5IG9uZTwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+aXNz dWUgcmVtYWluaW5nIHRvIGJlIHJlc29sdmVkIGZvciBsYXN0IGNhbGwmcXVvdDsuPC90dD48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5DaGVlcnMsPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD5HZW9mZjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+TGlzYSB3cm90ZSBvbiAwOS8wNC8yMDAzIDA2OjQzOjEwIFBNOjxicj4NCjxi cj4NCiZndDsgV2ViREFWIFdvcmtpbmcgR3JvdXA8YnI+DQomZ3Q7IFZpZW5uYSBJRVRGIDxicj4N CiZndDsgSnVseSAyMDAzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFZBUklPVVMgRFJBRlQgU1RBVFVT PGJyPg0KLi4uPGJyPg0KJmd0OyBCaW5kaW5nPGJyPg0KJmd0OyDigJMgJm5ic3A7IFN0aWxsIHJl cXVpcmVzIHNpZ25pZmljYW50IGV4cGxhbmF0aW9uIGlmIG5vdCBjaGFuZ2VzPGJyPg0KPC90dD48 L2ZvbnQ+DQo= --=_alternative 004EA47A85256D98_=-- From w3c-dist-auth-request@w3.org Fri Sep 5 12:21:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03781 for ; Fri, 5 Sep 2003 12:21:47 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 9D999A0F67; Fri, 5 Sep 2003 12:19:37 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E493EA0F54 for ; Fri, 5 Sep 2003 12:19:13 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 6F51B13B5E; Fri, 5 Sep 2003 12:19:13 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by dr-nick.w3.org (Postfix) with ESMTP id 956A8134ED for ; Fri, 5 Sep 2003 12:19:12 -0400 (EDT) Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id h85GJA323176; Fri, 5 Sep 2003 18:19:10 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 18:19:10 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3c.org'" Date: Fri, 5 Sep 2003 18:19:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C373C9.6F83DF80" Subject: DAV:getlastmodified of collections X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C4807D@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7850 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905161937.9D999A0F67@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 12:19:37 -0400 (EDT) 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_01C373C9.6F83DF80 Content-Type: text/plain; charset="iso-8859-1" AFAIK, according to RFC2518, Section 13.7, the DAV:getlastmodified property is not required to be defined for collections, but a server MAY define it. Is that correct? Then, probably the bindings of the collection are to be considered part of the collection's state and it would make sense to set DAV:getlastmodified whenever the bindings change: - BIND, UNBIND (the coll identified by the req-URI) - REBIND (the coll identified by the req-URI AND the 2nd involved coll) - PUT returning 201 (the containing collection) - MKCOL (the containing collection) - DELETE (the containing collection) - LOCK creating a lock-null resource (the containing collection) - VERSION-CONTROL on existing version (the containing workspace) Sorry for such a basic question, but I didn't find it in the specs. Regards, Peter ------_=_NextPart_001_01C373C9.6F83DF80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DAV:getlastmodified of collections

AFAIK, according to RFC2518, Section 13.7, the = DAV:getlastmodified property is not required to be defined for = collections, but a server MAY define it. Is that correct?

Then, probably the bindings of the collection are to = be considered part of the collection's state and it would make sense to = set DAV:getlastmodified whenever the bindings change:

- BIND, UNBIND (the coll identified by the = req-URI)
- REBIND (the coll identified by the req-URI AND the = 2nd involved coll)
- PUT returning 201 (the containing = collection)
- MKCOL (the containing collection)
- DELETE (the containing collection)
- LOCK creating a lock-null resource (the containing = collection)
- VERSION-CONTROL on existing version (the = containing workspace)

Sorry for such a basic question, but I didn't find it = in the specs.

Regards,
Peter

------_=_NextPart_001_01C373C9.6F83DF80-- From w3c-dist-auth-request@w3.org Fri Sep 5 14:01:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09474 for ; Fri, 5 Sep 2003 14:01:49 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C11B3A0E90; Fri, 5 Sep 2003 14:01:52 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9F2ACA0E90 for ; Fri, 5 Sep 2003 14:01:48 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 079EF13925; Fri, 5 Sep 2003 14:01:48 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from gate.arc.nasa.gov (gate.arc.nasa.gov [128.102.102.51]) by dr-nick.w3.org (Postfix) with ESMTP id A2F4113590 for ; Fri, 5 Sep 2003 14:01:47 -0400 (EDT) Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h85I1kW16694; Fri, 5 Sep 2003 11:01:46 -0700 (PDT) Message-ID: <3F58CFA9.70201@nasa.gov> Date: Fri, 05 Sep 2003 11:02:17 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: frank.judge@corp.palm.com Cc: WebDAV References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FW: Partial Property Data Retrieval??? X-Archived-At: http://www.w3.org/mid/3F58CFA9.70201@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7851 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905180152.C11B3A0E90@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 14:01:52 -0400 (EDT) Content-Transfer-Encoding: 7bit Frank Judge wrote: >I've read over the specifications and want to know if I'm missing >something or if you considered a capability. For properties in a schema >that have large amounts of data, does WebDAV specify a means to retrieve >only portions of that data? For example, if you have a document object >that has only a text property containing all the document data, you may >only want the first 100K of a 10 megabyte document. For email the POP >and IMAP protocols allow subsets of the message data to be retrieved ( >POP TOP command for instance ). Have you thought of allowing retrieval >of only a subset of property data, and if you have could you point me to >the reference that shows how? > > Alas, WebDAV does not allow for retrieval of part of a property. It would be very interesting and useful for large structured properties, as you've said. Probably would have to support XPath...http://www.w3c.org/TR/xpath From w3c-dist-auth-request@w3.org Fri Sep 5 14:11:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09997 for ; Fri, 5 Sep 2003 14:11:57 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id E58BEA0F49; Fri, 5 Sep 2003 14:11:44 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 41257A0F49 for ; Fri, 5 Sep 2003 14:11:37 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D515813B8F; Fri, 5 Sep 2003 14:11:36 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by dr-nick.w3.org (Postfix) with ESMTP id B3AB513B86 for ; Fri, 5 Sep 2003 14:11:36 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h85IBaGh425958 for ; Fri, 5 Sep 2003 14:11:36 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h85IBYcU046346 for ; Fri, 5 Sep 2003 14:11:35 -0400 In-Reply-To: To: "'w3c-dist-auth@w3c.org'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 5 Sep 2003 14:11:35 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 14:11:35, Serialize complete at 09/05/2003 14:11:35 Content-Type: text/plain; charset="US-ASCII" Subject: Re: DAV:getlastmodified of collections X-Archived-At: http://www.w3.org/mid/OF592A9E1C.46FE6A2C-ON85256D98.00635A43-85256D98.0063F0A8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7852 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905181144.E58BEA0F49@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 14:11:44 -0400 (EDT) Also, MOVE (on the collections containing the source and destination). Also, COPY (on the collections containing any new resources created by the COPY). One correction: VERSION-CONTROL affects the state of the collection containing the resource being created, not on the containing workspace (unless the workspace is the collection containing the resource). I agree that this would be worth adding to 2518bis, i.e. saying that "If a server supports DAV:getlastmodified for a collection, it must be updated any time an internal member (2518's name for a binding) is added or removed from a collection." Lisa (or whoever is maintaining the 2518bis issues list): Can this be added to the 2518bis issues list? Cheers, Geoff Peter wrote on 09/05/2003 12:19:09 PM: > AFAIK, according to RFC2518, Section 13.7, the DAV:getlastmodified > property is not required to be defined for collections, but a server > MAY define it. Is that correct? > Then, probably the bindings of the collection are to be considered > part of the collection's state and it would make sense to set DAV: > getlastmodified whenever the bindings change: > - BIND, UNBIND (the coll identified by the req-URI) > - REBIND (the coll identified by the req-URI AND the 2nd involved coll) > - PUT returning 201 (the containing collection) > - MKCOL (the containing collection) > - DELETE (the containing collection) > - LOCK creating a lock-null resource (the containing collection) > - VERSION-CONTROL on existing version (the containing workspace) > Sorry for such a basic question, but I didn't find it in the specs. > Regards, > Peter From w3c-dist-auth-request@w3.org Fri Sep 5 14:22:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10721 for ; Fri, 5 Sep 2003 14:22:25 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 29ECFA05D7; Fri, 5 Sep 2003 14:22:30 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 68DB5A0976 for ; Fri, 5 Sep 2003 14:22:05 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id EB8A913A48; Fri, 5 Sep 2003 14:22:04 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id D03DA13925 for ; Fri, 5 Sep 2003 14:22:04 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19vLDg-0005je-00; Fri, 05 Sep 2003 18:22:04 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19vLDf-0005jT-00; Fri, 05 Sep 2003 18:22:04 +0000 From: "Lisa Dusseault" To: "'Geoffrey M Clemm'" , Date: Fri, 5 Sep 2003 11:23:04 -0700 Message-ID: <007b01c373da$c0d73560$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, w3c-dist-auth@w3c.org Subject: RE: DAV:getlastmodified of collections X-Archived-At: http://www.w3.org/mid/007b01c373da$c0d73560$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7853 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905182230.29ECFA05D7@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 14:22:30 -0400 (EDT) Content-Transfer-Encoding: 7bit > > Lisa (or whoever is maintaining the 2518bis issues list): > Can this be added to the 2518bis issues list? Yes. However, the bindings specification should also be clear how BIND and UNBIND work with this. > > Cheers, > Geoff > > Peter wrote on 09/05/2003 12:19:09 PM: > > > AFAIK, according to RFC2518, Section 13.7, the DAV:getlastmodified > > property is not required to be defined for collections, but a server > > MAY define it. Is that correct? > > Then, probably the bindings of the collection are to be considered > > part of the collection's state and it would make sense to set DAV: > > getlastmodified whenever the bindings change: > > - BIND, UNBIND (the coll identified by the req-URI) > > - REBIND (the coll identified by the req-URI AND the 2nd > involved coll) > > - PUT returning 201 (the containing collection) > > - MKCOL (the containing collection) > > - DELETE (the containing collection) > > - LOCK creating a lock-null resource (the containing collection) > > - VERSION-CONTROL on existing version (the containing workspace) > > Sorry for such a basic question, but I didn't find it in the specs. > > Regards, > > Peter > > From w3c-dist-auth-request@w3.org Fri Sep 5 14:28:58 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11099 for ; Fri, 5 Sep 2003 14:28:57 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 6D45CA06DC; Fri, 5 Sep 2003 14:28:52 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id AC896A0880 for ; Fri, 5 Sep 2003 14:28:28 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 332A213925; Fri, 5 Sep 2003 14:28:28 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from gate.arc.nasa.gov (gate.arc.nasa.gov [128.102.102.51]) by dr-nick.w3.org (Postfix) with ESMTP id C49A413BA1 for ; Fri, 5 Sep 2003 14:28:27 -0400 (EDT) Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h85ISRW16783; Fri, 5 Sep 2003 11:28:27 -0700 (PDT) Message-ID: <3F58D5EA.4070806@nasa.gov> Date: Fri, 05 Sep 2003 11:28:58 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: frank.judge@corp.palm.com Cc: WebDAV References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FW: Partial Property Data Retrieval??? X-Archived-At: http://www.w3.org/mid/3F58D5EA.4070806@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7854 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905182852.6D45CA06DC@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 14:28:52 -0400 (EDT) Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >For example, if you have a document object >that has only a text property containing all the document data, you may >only want the first 100K of a 10 megabyte document. > In retrospect, this is a different question...HTTP/1.1 currently supports the "Range" header for GET requests that would satisfy your requirement to download parts of document data. See *ftp://ftp.isi.edu/in-notes/rfc2616.txt* From w3c-dist-auth-request@w3.org Fri Sep 5 14:58:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12335 for ; Fri, 5 Sep 2003 14:58:15 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 45E65A07A1; Fri, 5 Sep 2003 14:58:20 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 22814A0BD9 for ; Fri, 5 Sep 2003 14:57:59 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D16D713B60; Fri, 5 Sep 2003 14:57:58 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from smtp-relay4.palmone.com (palm-64-28-152-193.corp.palm.com [64.28.152.193]) by dr-nick.w3.org (Postfix) with SMTP id 59A0D13AF9 for ; Fri, 5 Sep 2003 14:57:58 -0400 (EDT) Received: from unknown(148.92.223.30) by smtp-relay4.palmone.com via csmap id 1542; Fri, 05 Sep 2003 11:57:14 -0700 (PDT) Received: from usmilm004.palm1.palmone.com (usmilm004.palm1.palmone.com [148.92.223.48]) by saspcp17.palmone.com (8.11.6+Sun/8.11.4) with ESMTP id h85IroF11047; Fri, 5 Sep 2003 11:53:50 -0700 (PDT) Received: from usmilm005.palm1.palmone.com ([148.92.223.47]) by usmilm004.palm1.palmone.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Sep 2003 11:53:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Sep 2003 11:53:50 -0700 Message-ID: <950DDBC2A9A7244AA2065E733711E76C0CBDB1@usmilm005.palm1.palmone.com> Thread-Topic: FW: Partial Property Data Retrieval??? Thread-Index: AcNz24BYqlVj5d36TnSGCodj9CWhPwAAJm1A From: "Frank Judge" To: "Chris Knight" , "Frank Judge (Corp)" Cc: "WebDAV" X-OriginalArrivalTime: 05 Sep 2003 18:53:50.0565 (UTC) FILETIME=[0B93E950:01C373DF] Subject: RE: FW: Partial Property Data Retrieval??? X-Archived-At: http://www.w3.org/mid/950DDBC2A9A7244AA2065E733711E76C0CBDB1@usmilm005.palm1.palmone.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7855 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905185820.45E65A07A1@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 14:58:20 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Chris, Thanks for the heads up. The only problems I see with this are: - its optional to support byte ranges in HTTP 1.1 - if I'm understanding this right, because this is at the HTTP level, = the entity body will basically be truncated. This would mean only a = partial XML document would be downloaded, and other properties coming = after the lengthy data may be missing, as well as the terminating XML = tags. Would this be your understanding also, or would you expect the = WebDAV server implementation to respect the RANGE header, and only = return the number of bytes for the large PROPERTY instead of the entire = HTTP entity body? - I can't find a server that supports the "Range: bytes=3D" header. At = least Microsoft's IIS server for Exchange 2003 does not. Any idea if this has come up for discussion in the WebDAV specs prior, = or if it could be proposed? Basically something like specifying a byte = RANGE when asking for a specific property would do the trick. I'll look = at the XPATH reference you previously forwarded. Thanks for you help, Frank -----Original Message----- From: Chris Knight [mailto:Christopher.D.Knight@nasa.gov] Sent: Friday, September 05, 2003 2:29 PM To: Frank Judge (Corp) Cc: WebDAV Subject: Re: FW: Partial Property Data Retrieval??? Jim Whitehead wrote: >For example, if you have a document object >that has only a text property containing all the document data, you may >only want the first 100K of a 10 megabyte document. > In retrospect, this is a different question...HTTP/1.1 currently=20 supports the "Range" header for GET requests that would satisfy your=20 requirement to download parts of document data. See *ftp://ftp.isi.edu/in-notes/rfc2616.txt* From w3c-dist-auth-request@w3.org Fri Sep 5 15:59:56 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15902 for ; Fri, 5 Sep 2003 15:59:56 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 27FD4A0E7C; Fri, 5 Sep 2003 15:59:51 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BC8FBA0E8E for ; Fri, 5 Sep 2003 15:59:38 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C77A113D09; Fri, 5 Sep 2003 15:33:23 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id A95FD13BCE for ; Fri, 5 Sep 2003 15:33:23 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h85JXMSO177226; Fri, 5 Sep 2003 15:33:22 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h85JXLcU059894; Fri, 5 Sep 2003 15:33:21 -0400 In-Reply-To: <007b01c373da$c0d73560$f8cb90c6@lisalap> To: "Lisa Dusseault" Cc: w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 5 Sep 2003 15:33:22 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 15:33:21, Serialize complete at 09/05/2003 15:33:21 Content-Type: text/plain; charset="US-ASCII" Subject: RE: DAV:getlastmodified of collections X-Archived-At: http://www.w3.org/mid/OF473FB777.701A454A-ON85256D98.006B3886-85256D98.006B6D24@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7856 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905195951.27FD4A0E7C@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 15:59:51 -0400 (EDT) That's fine, but the binding spec needs to follow whatever decision is made by the spec defining DAV:getlastmodified (which is RFC2518). So the binding spec can't be clear on it until RFC2518 is clear on it. Cheers, Geoff "Lisa Dusseault" wrote on 09/05/2003 02:23:04 PM: > > > > Lisa (or whoever is maintaining the 2518bis issues list): > > Can this be added to the 2518bis issues list? > > Yes. However, the bindings specification should also be clear how BIND and > UNBIND work with this. > > > > > Cheers, > > Geoff > > > > Peter wrote on 09/05/2003 12:19:09 PM: > > > > > AFAIK, according to RFC2518, Section 13.7, the DAV:getlastmodified > > > property is not required to be defined for collections, but a server > > > MAY define it. Is that correct? > > > Then, probably the bindings of the collection are to be considered > > > part of the collection's state and it would make sense to set DAV: > > > getlastmodified whenever the bindings change: > > > - BIND, UNBIND (the coll identified by the req-URI) > > > - REBIND (the coll identified by the req-URI AND the 2nd > > involved coll) > > > - PUT returning 201 (the containing collection) > > > - MKCOL (the containing collection) > > > - DELETE (the containing collection) > > > - LOCK creating a lock-null resource (the containing collection) > > > - VERSION-CONTROL on existing version (the containing workspace) > > > Sorry for such a basic question, but I didn't find it in the specs. > > > Regards, > > > Peter > > > > > > From w3c-dist-auth-request@w3.org Fri Sep 5 17:53:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21203 for ; Fri, 5 Sep 2003 17:53:49 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id E4950A06DC; Fri, 5 Sep 2003 17:53:17 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BF197A0EC3 for ; Fri, 5 Sep 2003 17:53:15 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 806D913B69; Fri, 5 Sep 2003 17:53:15 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 1A6F913674 for ; Fri, 5 Sep 2003 17:53:15 -0400 (EDT) Received: (qmail 23622 invoked by uid 65534); 5 Sep 2003 21:53:04 -0000 Received: from pD950C3A6.dip.t-dialin.net (HELO lisa) (217.80.195.166) by mail.gmx.net (mp027) with SMTP; 05 Sep 2003 23:53:04 +0200 From: "Julian Reschke" To: "Nevermann, Dr., Peter" , Date: Fri, 5 Sep 2003 23:52:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: getlastmodified of collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEANIGAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7857 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905215317.E4950A06DC@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 17:53:17 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Nevermann, Dr., Peter > Sent: Friday, September 05, 2003 6:19 PM > To: 'w3c-dist-auth@w3c.org' > Subject: DAV:getlastmodified of collections > > > AFAIK, according to RFC2518, Section 13.7, the > DAV:getlastmodified property > is not required to be defined for collections, but a server MAY define it. > Is that correct? Actually, it's not really required at all. A server should provide a DAV:getlastmodified property for any resource for which it actually would also provide the last-modified header upon GET. So a collection may have GETtable content (in which case DAV:getlastmodified should be present), and then also a server may not even have the last-modified date for a plain resource (for instance if it's clockless). > Then, probably the bindings of the collection are to be considered part of > the collection's state and it would make sense to set DAV:getlastmodified > whenever the bindings change: I agree although I have to point out that properties *also* are part of the state of a collection, and the current consensus seems to be that the last-modified date should not change when the content doesn't. So this is non-obvious. > - BIND, UNBIND (the coll identified by the req-URI) > - REBIND (the coll identified by the req-URI AND the 2nd involved coll) > - PUT returning 201 (the containing collection) > - MKCOL (the containing collection) > - DELETE (the containing collection) > - LOCK creating a lock-null resource (the containing collection) > - VERSION-CONTROL on existing version (the containing workspace) Yes. > Sorry for such a basic question, but I didn't find it in the specs. No, it's good to ask these kinds of questions. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 5 17:55:00 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21294 for ; Fri, 5 Sep 2003 17:54:59 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 55145A0D95; Fri, 5 Sep 2003 17:55:05 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5B30AA0D95 for ; Fri, 5 Sep 2003 17:55:03 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id F214F13360; Fri, 5 Sep 2003 17:55:02 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 684AD13B13 for ; Fri, 5 Sep 2003 17:55:01 -0400 (EDT) Received: (qmail 2934 invoked by uid 65534); 5 Sep 2003 21:54:52 -0000 Received: from pD950C3A6.dip.t-dialin.net (HELO lisa) (217.80.195.166) by mail.gmx.net (mp025) with SMTP; 05 Sep 2003 23:54:52 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Fri, 5 Sep 2003 23:54:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: DAV:getlastmodified of collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEANIGAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7858 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905215505.55145A0D95@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 17:55:05 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M Clemm > Sent: Friday, September 05, 2003 8:12 PM > To: 'w3c-dist-auth@w3c.org' > Subject: Re: DAV:getlastmodified of collections > > > > Also, MOVE (on the collections containing the source and destination). > Also, COPY (on the collections containing any new resources > created by the > COPY). > One correction: VERSION-CONTROL affects the state of the collection > containing the resource being created, not on the containing workspace > (unless the workspace is the collection containing the resource). Hm. Does it affect the state of a parent collection if it (the collection) isn't version-controlled? In this case the state of the collection IMHO doesn't (or doesn't need to) change. > ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 5 18:03:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21788 for ; Fri, 5 Sep 2003 18:03:05 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 1CDF9A08A0; Fri, 5 Sep 2003 18:03:11 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B6FC0A0E92 for ; Fri, 5 Sep 2003 18:03:09 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 6813D13AF9; Fri, 5 Sep 2003 18:03:09 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (Postfix) with ESMTP id 570C613B15 for ; Fri, 5 Sep 2003 18:03:09 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150] (may be forged)) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h85M39g2177466 for ; Fri, 5 Sep 2003 18:03:09 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h85M37gr051736 for ; Fri, 5 Sep 2003 18:03:08 -0400 In-Reply-To: To: w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 5 Sep 2003 18:03:06 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 18:03:08, Serialize complete at 09/05/2003 18:03:08 Content-Type: text/plain; charset="US-ASCII" Subject: RE: DAV:getlastmodified of collections X-Archived-At: http://www.w3.org/mid/OF0B81860D.AB69925D-ON85256D98.0078F2C6-85256D98.0079228C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7859 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905220311.1CDF9A08A0@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 18:03:11 -0400 (EDT) I was referring to the VERSION-CONTROL bullet in Peter's original message, i.e. VERSION-CONTROL with a version argument (which always creates a new version-controlled resource). For VERSION-CONTROL without a version argument (which never creates a new version-controlled resource), you are correct that it does not affect the state of the parent collection. Cheers, Geoff Julian wrote on 09/05/2003 05:54:12 PM: > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M Clemm > > Sent: Friday, September 05, 2003 8:12 PM > > To: 'w3c-dist-auth@w3c.org' > > Subject: Re: DAV:getlastmodified of collections > > > > > > > > Also, MOVE (on the collections containing the source and destination). > > Also, COPY (on the collections containing any new resources > > created by the > > COPY). > > One correction: VERSION-CONTROL affects the state of the collection > > containing the resource being created, not on the containing workspace > > (unless the workspace is the collection containing the resource). > > Hm. Does it affect the state of a parent collection if it (the collection) > isn't version-controlled? In this case the state of the collection IMHO > doesn't (or doesn't need to) change. > > > ... > > Julian From w3c-dist-auth-request@w3.org Fri Sep 5 18:08:31 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22451 for ; Fri, 5 Sep 2003 18:08:31 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 30F49A0A45; Fri, 5 Sep 2003 18:08:36 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 1E92EA0A45 for ; Fri, 5 Sep 2003 18:08:34 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id BBBCC13866; Fri, 5 Sep 2003 18:08:33 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 5013913448 for ; Fri, 5 Sep 2003 18:08:33 -0400 (EDT) Received: (qmail 23223 invoked by uid 65534); 5 Sep 2003 22:08:32 -0000 Received: from pD950C3A6.dip.t-dialin.net (HELO lisa) (217.80.195.166) by mail.gmx.net (mp012) with SMTP; 06 Sep 2003 00:08:32 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Sat, 6 Sep 2003 00:08:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: Importance: Normal Subject: RE: DAV:getlastmodified of collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEAOIGAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7860 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905220836.30F49A0A45@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 18:08:36 -0400 (EDT) Content-Transfer-Encoding: 7bit I see. But then we're missing the case of VERSION-CONTROL on a versionable but not yet version-controlled resource that lives inside a versioned collection (in which case I'd say the state of the parent collection *does* change). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M Clemm > Sent: Saturday, September 06, 2003 12:03 AM > To: w3c-dist-auth@w3c.org > Subject: RE: DAV:getlastmodified of collections > > > > I was referring to the VERSION-CONTROL bullet in Peter's > original message, i.e. VERSION-CONTROL with a version argument > (which always creates a new version-controlled resource). > > For VERSION-CONTROL without a version argument (which never > creates a new version-controlled resource), you are correct > that it does not affect the state of the parent collection. > > Cheers, > Geoff > > > Julian wrote on 09/05/2003 05:54:12 PM: > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M Clemm > > > Sent: Friday, September 05, 2003 8:12 PM > > > To: 'w3c-dist-auth@w3c.org' > > > Subject: Re: DAV:getlastmodified of collections > > > > > > > > > > > > Also, MOVE (on the collections containing the source and destination). > > > Also, COPY (on the collections containing any new resources > > > created by the > > > COPY). > > > One correction: VERSION-CONTROL affects the state of the collection > > > containing the resource being created, not on the containing workspace > > > (unless the workspace is the collection containing the resource). > > > > Hm. Does it affect the state of a parent collection if it (the > collection) > > isn't version-controlled? In this case the state of the collection IMHO > > doesn't (or doesn't need to) change. > > > > > ... > > > > Julian > From w3c-dist-auth-request@w3.org Fri Sep 5 18:15:54 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23282 for ; Fri, 5 Sep 2003 18:15:53 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 2AAF5A05D8; Fri, 5 Sep 2003 18:15:59 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 75532A05D8 for ; Fri, 5 Sep 2003 18:15:56 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 0F193139B7; Fri, 5 Sep 2003 18:15:56 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id CEF8613866 for ; Fri, 5 Sep 2003 18:15:55 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19vOry-00026S-00; Fri, 05 Sep 2003 22:15:54 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19vOry-00026B-00; Fri, 05 Sep 2003 22:15:54 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Nevermann, Dr., Peter'" , Date: Fri, 5 Sep 2003 15:16:56 -0700 Message-ID: <009a01c373fb$6b59d220$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Old-X-Envelope-To: julian.reschke@gmx.de, Peter.Nevermann@softwareag.com, w3c-dist-auth@w3c.org Subject: RE: getlastmodified of collections X-Archived-At: http://www.w3.org/mid/009a01c373fb$6b59d220$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7861 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030905221559.2AAF5A05D8@frink.w3.org> Resent-Date: Fri, 5 Sep 2003 18:15:59 -0400 (EDT) Content-Transfer-Encoding: quoted-printable This is a good point. I was thinking that the GET response to a = directory was likely only a=20 listing of its member files, and then Geoff's idea of getlastmodified = would fit this model. However there are a number of other possibilities: - If the server includes information about a directory's members, that could change. E.g. File Name Size Last Modified file1.txt 123k 8/1/2003 file2.txt 124k 8/2/2003 A server that did a listing like this in response to a GET ought to change its directory's getlastmodified value whenever the content changed. Obviously that = might include a PUT operation to a child as well as the other operations listed. - If the server returns a file like "index.html" in response to a GET = for a directory, then possibly the 'getlastmodified' property value for the directory = should be that of=20 the index.html file. How many HTTP/WebDAV clients are there out there that do caching/synch = based on the=20 Last-Modified header or the 'getlastmodified' property? I am guessing = there are quite a few because from what I've seen clients can't rely on ETag support in Web/WebDAV servers. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org=20 > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Friday, September 05, 2003 2:52 PM > To: Nevermann, Dr., Peter; w3c-dist-auth@w3c.org > Subject: RE: getlastmodified of collections >=20 >=20 >=20 > > From: w3c-dist-auth-request@w3.org=20 > > [mailto:w3c-dist-auth-request@w3.org]On > > Behalf Of Nevermann, Dr., Peter > > Sent: Friday, September 05, 2003 6:19 PM > > To: 'w3c-dist-auth@w3c.org' > > Subject: DAV:getlastmodified of collections > > > > > > AFAIK, according to RFC2518, Section 13.7, the DAV:getlastmodified=20 > > property is not required to be defined for collections, but=20 > a server=20 > > MAY define it. Is that correct? >=20 > Actually, it's not really required at all. A server should=20 > provide a DAV:getlastmodified property for any resource for=20 > which it actually would also provide the last-modified header=20 > upon GET. So a collection may have GETtable content (in which=20 > case DAV:getlastmodified should be present), and then also a=20 > server may not even have the last-modified date for a plain=20 > resource (for instance if it's clockless). >=20 > > Then, probably the bindings of the collection are to be considered=20 > > part of the collection's state and it would make sense to set=20 > > DAV:getlastmodified whenever the bindings change: >=20 > I agree although I have to point out that properties *also*=20 > are part of the state of a collection, and the current=20 > consensus seems to be that the last-modified date should not=20 > change when the content doesn't. So this is non-obvious. >=20 > > - BIND, UNBIND (the coll identified by the req-URI) > > - REBIND (the coll identified by the req-URI AND the 2nd involved=20 > > coll) > > - PUT returning 201 (the containing collection) > > - MKCOL (the containing collection) > > - DELETE (the containing collection) > > - LOCK creating a lock-null resource (the containing collection) > > - VERSION-CONTROL on existing version (the containing workspace) >=20 > Yes. >=20 > > Sorry for such a basic question, but I didn't find it in the specs. >=20 > No, it's good to ask these kinds of questions. >=20 > Julian >=20 > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >=20 >=20 From w3c-dist-auth-request@w3.org Sat Sep 6 05:46:48 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02644 for ; Sat, 6 Sep 2003 05:46:47 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 4F2ABA0F57; Sat, 6 Sep 2003 05:46:49 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 1D79BA0F57 for ; Sat, 6 Sep 2003 05:46:43 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D9ED713CF7; Sat, 6 Sep 2003 05:46:42 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 7134913D00 for ; Sat, 6 Sep 2003 05:46:41 -0400 (EDT) Received: (qmail 26233 invoked by uid 65534); 6 Sep 2003 09:46:40 -0000 Received: from pD950C3A6.dip.t-dialin.net (HELO lisa) (217.80.195.166) by mail.gmx.net (mp016) with SMTP; 06 Sep 2003 11:46:40 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Nevermann, Dr., Peter'" , Date: Sat, 6 Sep 2003 11:46:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <009a01c373fb$6b59d220$f8cb90c6@lisalap> Importance: Normal Subject: RE: getlastmodified of collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEBIIGAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7862 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030906094649.4F2ABA0F57@frink.w3.org> Resent-Date: Sat, 6 Sep 2003 05:46:49 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, September 06, 2003 12:17 AM > To: 'Julian Reschke'; 'Nevermann, Dr., Peter'; w3c-dist-auth@w3c.org > Subject: RE: getlastmodified of collections > > > > This is a good point. I was thinking that the GET response to a directory was likely only a > listing of its member files, and then Geoff's idea of getlastmodified would fit this model. Yes. > However there are a number of other possibilities: > > - If the server includes information about a directory's members, that could change. E.g. > File Name Size Last Modified > file1.txt 123k 8/1/2003 > file2.txt 124k 8/2/2003 > A server that did a listing like this in response to a GET ought to change its directory's > getlastmodified value whenever the content changed. Obviously that might include a PUT > operation to a child as well as the other operations listed. Correct. > - If the server returns a file like "index.html" in response to a GET for a directory, then > possibly the 'getlastmodified' property value for the directory should be that of > the index.html file. Yes. > How many HTTP/WebDAV clients are there out there that do caching/synch based on the > Last-Modified header or the 'getlastmodified' property? I am guessing there are quite > a few because from what I've seen clients can't rely on ETag support in Web/WebDAV servers. I think most user agents will cache using the Last-Modified *header* when no ETag is present. I however doubt that there are lots of WebDAV-aware clients that actually use DAV:getlastmodified to cache (they'd still need to GET the content, in which case they SHOULD use the "Last-Modified" header returned by GET). In general, all we can say reliably is that the Last-Modified date should change when the GETtable content changes. Now the real issue here is: is the timestamp allowed to change even though the content didn't. We ruled that out for property changes (which I think is wrong), but seem to propose it for other non-content changes here. See also , part 2. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 8 08:10:44 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14790 for ; Mon, 8 Sep 2003 08:10:44 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B6E29A090A; Mon, 8 Sep 2003 08:10:49 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7894CA090A for ; Mon, 8 Sep 2003 08:10:47 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 14FB51363C; Mon, 8 Sep 2003 08:10:47 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (Postfix) with ESMTP id EAC4A1348D for ; Mon, 8 Sep 2003 08:10:46 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h88CAk0H229962 for ; Mon, 8 Sep 2003 08:10:46 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h88CAjWo066784 for ; Mon, 8 Sep 2003 08:10:45 -0400 In-Reply-To: To: w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 8 Sep 2003 08:10:41 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/08/2003 08:10:45, Serialize complete at 09/08/2003 08:10:45 Content-Type: multipart/alternative; boundary="=_alternative 000BB54185256D9B_=" Subject: RE: DAV:getlastmodified of collections X-Archived-At: http://www.w3.org/mid/OFCC3AF710.B7939216-ON85256D9B.000B1A75-85256D9B.0042E587@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7863 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030908121049.B6E29A090A@frink.w3.org> Resent-Date: Mon, 8 Sep 2003 08:10:49 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 000BB54185256D9B_= Content-Type: text/plain; charset="US-ASCII" "Julian Reschke" wrote on 09/05/2003 06:08:11 PM: > But then we're missing the case of VERSION-CONTROL on a versionable but not > yet version-controlled resource that lives inside a versioned collection (in > which case I'd say the state of the parent collection *does* change). I suggest we keep the semantics very simple, and say that DAV:getlastmodified is changed only by adding a binding, removing a binding, or changing a binding to new resource. Putting an existing resource under version control does none of these things, so it should not result in an update to DAV:getlastmodified. Note that in general the "version-controlled state" of a collection will be different from the "state" of a collection, i.e. adding and removing a binding to a non-version-controlled resource does not change the version-controlled state of a collection, but does change the state of the collection. Cheers, Geoff --=_alternative 000BB54185256D9B_= Content-Type: text/html; charset="US-ASCII"
"Julian Reschke" <julian.reschke@gmx.de> wrote on 09/05/2003 06:08:11 PM: > But then we're missing the case of VERSION-CONTROL on a versionable but not > yet version-controlled resource that lives inside a versioned collection (in > which case I'd say the state of the parent collection *does* change).
I suggest we keep the semantics very simple, and say that DAV:getlastmodified
is changed only by adding a binding, removing a binding, or changing a binding
to new resource. Putting an existing resource under version control does
none of these things, so it should not result in an update to DAV:getlastmodified.

Note that in general the "version-controlled state" of a collection will be
different from the "state" of a collection, i.e. adding and removing a binding
to a non-version-controlled resource does not change the version-controlled
state of a collection, but does change the state of the collection.

Cheers,
Geoff
--=_alternative 000BB54185256D9B_=-- From w3c-dist-auth-request@w3.org Mon Sep 8 08:11:11 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14844 for ; Mon, 8 Sep 2003 08:11:11 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id D7A80A0DE9; Mon, 8 Sep 2003 08:10:57 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C6333A0DE9 for ; Mon, 8 Sep 2003 08:10:56 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 628201410F; Mon, 8 Sep 2003 08:10:56 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id 409C5140FA for ; Mon, 8 Sep 2003 08:10:56 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h88CAuWq684930 for ; Mon, 8 Sep 2003 08:10:56 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h88CAsWo054126 for ; Mon, 8 Sep 2003 08:10:55 -0400 In-Reply-To: <009a01c373fb$6b59d220$f8cb90c6@lisalap> To: w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 8 Sep 2003 08:10:48 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/08/2003 08:10:55, Serialize complete at 09/08/2003 08:10:55 Content-Type: multipart/alternative; boundary="=_alternative 000E026B85256D9B_=" Subject: RE: getlastmodified of collections X-Archived-At: http://www.w3.org/mid/OFF1E3105C.5C14F114-ON85256D9B.000DF33A-85256D9B.0042E846@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7864 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030908121057.D7A80A0DE9@frink.w3.org> Resent-Date: Mon, 8 Sep 2003 08:10:57 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 000E026B85256D9B_= Content-Type: text/plain; charset="US-ASCII" I agree with Lisa's observations below, and my conclusion is that since the behavior of GET on a collection is not defined, the behavior of DAV:getlastmodified should not be defined, since the purpose of the Last-Modified header is to support caching of the GET request. So until 2518 defines server-independent behavior of GET on a collection 2518 should remain silent on DAV:getlastmodified on a collection. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 09/05/2003 06:16:56 PM: > > This is a good point. I was thinking that the GET response to a directory > was likely only a > listing of its member files, and then Geoff's idea of getlastmodified would > fit this model. > However there are a number of other possibilities: > > - If the server includes information about a directory's members, that > could change. E.g. > File Name Size Last Modified > file1.txt 123k 8/1/2003 > file2.txt 124k 8/2/2003 > A server that did a listing like this in response to a GET ought to > change its directory's > getlastmodified value whenever the content changed. Obviously that might > include a PUT > operation to a child as well as the other operations listed. > > - If the server returns a file like "index.html" in response to a GET for a > directory, then > possibly the 'getlastmodified' property value for the directory should be > that of > the index.html file. > > How many HTTP/WebDAV clients are there out there that do caching/synch based > on the > Last-Modified header or the 'getlastmodified' property? I am guessing there > are quite > a few because from what I've seen clients can't rely on ETag support in > Web/WebDAV servers. > > Lisa > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > > Sent: Friday, September 05, 2003 2:52 PM > > To: Nevermann, Dr., Peter; w3c-dist-auth@w3c.org > > Subject: RE: getlastmodified of collections > > > > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On > > > Behalf Of Nevermann, Dr., Peter > > > Sent: Friday, September 05, 2003 6:19 PM > > > To: 'w3c-dist-auth@w3c.org' > > > Subject: DAV:getlastmodified of collections > > > > > > > > > AFAIK, according to RFC2518, Section 13.7, the DAV:getlastmodified > > > property is not required to be defined for collections, but > > a server > > > MAY define it. Is that correct? > > > > Actually, it's not really required at all. A server should > > provide a DAV:getlastmodified property for any resource for > > which it actually would also provide the last-modified header > > upon GET. So a collection may have GETtable content (in which > > case DAV:getlastmodified should be present), and then also a > > server may not even have the last-modified date for a plain > > resource (for instance if it's clockless). > > > > > Then, probably the bindings of the collection are to be considered > > > part of the collection's state and it would make sense to set > > > DAV:getlastmodified whenever the bindings change: > > > > I agree although I have to point out that properties *also* > > are part of the state of a collection, and the current > > consensus seems to be that the last-modified date should not > > change when the content doesn't. So this is non-obvious. > > > > > - BIND, UNBIND (the coll identified by the req-URI) > > > - REBIND (the coll identified by the req-URI AND the 2nd involved > > > coll) > > > - PUT returning 201 (the containing collection) > > > - MKCOL (the containing collection) > > > - DELETE (the containing collection) > > > - LOCK creating a lock-null resource (the containing collection) > > > - VERSION-CONTROL on existing version (the containing workspace) > > > > Yes. > > > > > Sorry for such a basic question, but I didn't find it in the specs. > > > > No, it's good to ask these kinds of questions. > > > > Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > --=_alternative 000E026B85256D9B_= Content-Type: text/html; charset="US-ASCII"
I agree with Lisa's observations below, and my conclusion is that since
the behavior of GET on a collection is not defined, the behavior of
DAV:getlastmodified should not be defined, since the purpose
of the Last-Modified header is to support caching of the GET request.

So until 2518 defines server-independent behavior of GET on a collection
2518 should remain silent on DAV:getlastmodified on a collection.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 09/05/2003 06:16:56 PM: > > This is a good point. I was thinking that the GET response to a directory > was likely only a > listing of its member files, and then Geoff's idea of getlastmodified would > fit this model. > However there are a number of other possibilities: > > - If the server includes information about a directory's members, that > could change. E.g. > File Name Size Last Modified > file1.txt 123k 8/1/2003 > file2.txt 124k 8/2/2003 > A server that did a listing like this in response to a GET ought to > change its directory's > getlastmodified value whenever the content changed. Obviously that might > include a PUT > operation to a child as well as the other operations listed. > > - If the server returns a file like "index.html" in response to a GET for a > directory, then > possibly the 'getlastmodified' property value for the directory should be > that of > the index.html file. > > How many HTTP/WebDAV clients are there out there that do caching/synch based > on the > Last-Modified header or the 'getlastmodified' property? I am guessing there > are quite > a few because from what I've seen clients can't rely on ETag support in > Web/WebDAV servers. > > Lisa > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > > Sent: Friday, September 05, 2003 2:52 PM > > To: Nevermann, Dr., Peter; w3c-dist-auth@w3c.org > > Subject: RE: getlastmodified of collections > > > > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On > > > Behalf Of Nevermann, Dr., Peter > > > Sent: Friday, September 05, 2003 6:19 PM > > > To: 'w3c-dist-auth@w3c.org' > > > Subject: DAV:getlastmodified of collections > > > > > > > > > AFAIK, according to RFC2518, Section 13.7, the DAV:getlastmodified > > > property is not required to be defined for collections, but > > a server > > > MAY define it. Is that correct? > > > > Actually, it's not really required at all. A server should > > provide a DAV:getlastmodified property for any resource for > > which it actually would also provide the last-modified header > > upon GET. So a collection may have GETtable content (in which > > case DAV:getlastmodified should be present), and then also a > > server may not even have the last-modified date for a plain > > resource (for instance if it's clockless). > > > > > Then, probably the bindings of the collection are to be considered > > > part of the collection's state and it would make sense to set > > > DAV:getlastmodified whenever the bindings change: > > > > I agree although I have to point out that properties *also* > > are part of the state of a collection, and the current > > consensus seems to be that the last-modified date should not > > change when the content doesn't. So this is non-obvious. > > > > > - BIND, UNBIND (the coll identified by the req-URI) > > > - REBIND (the coll identified by the req-URI AND the 2nd involved > > > coll) > > > - PUT returning 201 (the containing collection) > > > - MKCOL (the containing collection) > > > - DELETE (the containing collection) > > > - LOCK creating a lock-null resource (the containing collection) > > > - VERSION-CONTROL on existing version (the containing workspace) > > > > Yes. > > > > > Sorry for such a basic question, but I didn't find it in the specs. > > > > No, it's good to ask these kinds of questions. > > > > Julian > > > > -- > > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > --=_alternative 000E026B85256D9B_=-- From w3c-dist-auth-request@w3.org Mon Sep 8 09:50:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19276 for ; Mon, 8 Sep 2003 09:50:36 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 9753BA0532; Mon, 8 Sep 2003 09:50:40 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 06AD7A0532 for ; Mon, 8 Sep 2003 09:50:38 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 93DB613AD4; Mon, 8 Sep 2003 09:41:48 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 2107613979 for ; Mon, 8 Sep 2003 09:41:48 -0400 (EDT) Received: (qmail 5377 invoked by uid 65534); 8 Sep 2003 13:41:47 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009) with SMTP; 08 Sep 2003 15:41:47 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Mon, 8 Sep 2003 15:41:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Subject: RE: getlastmodified of collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEFAIGAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7865 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030908135040.9753BA0532@frink.w3.org> Resent-Date: Mon, 8 Sep 2003 09:50:40 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Geoffrey M Clemm > Sent: Monday, September 08, 2003 2:11 PM > To: w3c-dist-auth@w3c.org > Subject: RE: getlastmodified of collections > > > > I agree with Lisa's observations below, and my conclusion is that since > the behavior of GET on a collection is not defined, the behavior of > DAV:getlastmodified should not be defined, since the purpose > of the Last-Modified header is to support caching of the GET request. To clarify: the behaviour of GET and the HTTP Last-Modified header *is* defined by RFC2616. A collection may or may not have gettable representations (as any other resource), but if it does, the Last-Modified header must obey RFC2616's rules (that is, if it's present it must change when the GETtable content changes). The behaviour for DAV:getlastmodified follows automatically. > So until 2518 defines server-independent behavior of GET on a collection > 2518 should remain silent on DAV:getlastmodified on a collection. Yes. In particular, if we see a use case for a last modified timestamp that is not directly tied to content changes, we need to define a new one. This may be optional (as all the other timestamps we have), so it shouldn't be a problem getting it into RFC2518bis. Maybe a topic for the interop event? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 8 09:58:33 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20342 for ; Mon, 8 Sep 2003 09:58:33 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 84A5CA07B1; Mon, 8 Sep 2003 09:58:36 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 1D6D1A07B1 for ; Mon, 8 Sep 2003 09:58:34 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 38DDE13619; Mon, 8 Sep 2003 09:45:23 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 9E2121358C for ; Mon, 8 Sep 2003 09:45:22 -0400 (EDT) Received: (qmail 11004 invoked by uid 65534); 8 Sep 2003 13:45:21 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 08 Sep 2003 15:45:21 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Mon, 8 Sep 2003 15:45:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Subject: RE: DAV:getlastmodified of collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEFCIGAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7866 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030908135836.84A5CA07B1@frink.w3.org> Resent-Date: Mon, 8 Sep 2003 09:58:36 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Geoffrey M Clemm > Sent: Monday, September 08, 2003 2:11 PM > To: w3c-dist-auth@w3c.org > Subject: RE: DAV:getlastmodified of collections > > > > "Julian Reschke" wrote on 09/05/2003 06:08:11 PM: > > But then we're missing the case of VERSION-CONTROL on a versionable but > not > > yet version-controlled resource that lives inside a versioned collection > (in > > which case I'd say the state of the parent collection *does* change). > > I suggest we keep the semantics very simple, and say that DAV:getlastmodified > is changed only by adding a binding, removing a binding, or changing a binding > to new resource. Putting an existing resource under version control does > none of these things, so it should not result in an update to > DAV:getlastmodified. > > Note that in general the "version-controlled state" of a collection will be > different from the "state" of a collection, i.e. adding and removing a binding > to a non-version-controlled resource does not change the version-controlled > state of a collection, but does change the state of the collection. This seems to imply that the version-controlled state is not a subset of the state, or more precisely, that you can modify the version-controlled state without changing the state. This IMHO seems to be a weird way to define the state of a collection. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 8 11:19:24 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29440 for ; Mon, 8 Sep 2003 11:19:23 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id D61D7A0C20; Mon, 8 Sep 2003 11:19:18 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 689A1A101E for ; Mon, 8 Sep 2003 11:19:11 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 956A313617; Mon, 8 Sep 2003 11:18:40 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id 5C39913E59 for ; Mon, 8 Sep 2003 11:18:39 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h88FIdWq693422 for ; Mon, 8 Sep 2003 11:18:39 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h88FIbWo052278 for ; Mon, 8 Sep 2003 11:18:37 -0400 In-Reply-To: To: w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 8 Sep 2003 11:18:43 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/08/2003 11:18:37, Serialize complete at 09/08/2003 11:18:37 Content-Type: text/plain; charset="US-ASCII" Subject: DAV:bindings-last-modified (was RE: DAV:getlastmodified of collections) X-Archived-At: http://www.w3.org/mid/OF3BA57745.F717643E-ON85256D9B.00530FC8-85256D9B.00541CF7@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7867 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030908151918.D61D7A0C20@frink.w3.org> Resent-Date: Mon, 8 Sep 2003 11:19:18 -0400 (EDT) I believe that we have concluded that DAV:getlastmodified depends on what the server returns on a GET on a collection, and therefore is not something we can define (since what the server returns on a GET on a collection is not defined). So what we are really talking about in this thread is a new property (which without much thought, I've named DAV:bindings-last-modified). This raises the key question: what will the client be using this new property for. I suggest it be used to keep the structure of a client tree display synchronized with the names and resources on the server, in which case the client doesn't care whether the version-controlled state changes, as long as the named tree of resources is still valid. Cheers, Geoff > > "Julian Reschke" wrote on 09/05/2003 06:08:11 PM: > > > But then we're missing the case of VERSION-CONTROL on a versionable but not > > > yet version-controlled resource that lives inside a versioned collection (in > > > which case I'd say the state of the parent collection *does* change). > > Geoffrey M Clemm > > I suggest we keep the semantics very simple, and say that DAV:getlastmodified > > is changed only by adding a binding, removing a binding, or changing a binding > > to new resource. Putting an existing resource under version control does > > none of these things, so it should not result in an update to > > DAV:getlastmodified. > > > > Note that in general the "version-controlled state" of a collection will be > > different from the "state" of a collection, i.e. adding and removing a binding > > to a non-version-controlled resource does not change the version-controlled > > state of a collection, but does change the state of the collection. "Julian Reschke" wrote on 09/08/2003 09:45:20 AM: > This seems to imply that the version-controlled state is not a subset of the > state, or more precisely, that you can modify the version-controlled state > without changing the state. This IMHO seems to be a weird way to define the > state of a collection. From w3c-dist-auth-request@w3.org Mon Sep 8 11:44:58 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00976 for ; Mon, 8 Sep 2003 11:44:58 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 2CE7DA0753; Mon, 8 Sep 2003 11:44:20 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 41DB9A0753 for ; Mon, 8 Sep 2003 11:44:17 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id F11E91360F; Mon, 8 Sep 2003 11:44:16 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by dr-nick.w3.org (Postfix) with ESMTP id 21538135F8 for ; Mon, 8 Sep 2003 11:44:16 -0400 (EDT) Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id h88Fi3312407; Mon, 8 Sep 2003 17:44:14 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Sep 2003 17:44:02 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3c.org'" Date: Mon, 8 Sep 2003 17:44:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37620.073CEC10" Subject: RE: DAV:modificationdate (was bindings-last-modified (was RE: DAV :getlastmodified of collections)) X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C48087@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7868 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030908154420.2CE7DA0753@frink.w3.org> Resent-Date: Mon, 8 Sep 2003 11:44:20 -0400 (EDT) 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_01C37620.073CEC10 Content-Type: text/plain; charset="iso-8859-1" I would prefer a more general new property, e.g. DAV:modificationdate as proposed by Julian some days ago in another thread (I added a few words about *bindings* of a collection to Julian's wording): "A proper way to address this may be to define a new optional property (if we make it optional, we may be able to get it into RFC52518bis), for instance: Name: modificationdate Namespace: DAV: Purpose: Records the time and date the resource was modified. Value: date-time Description: The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was last modified (i.e., the moment when content and/or properties last changed, or, when the bindings of a collection last changed). This property is live and protected. The Internet date-time format is defined in [RFC3339], see the ABNF in section 5.6. COPY/MOVE behavior: This property value SHOULD be kept during a MOVE operation, but is re-initialized when a resource is created with a COPY. It should not be set in a remote COPY. " Probably, w.r.t. properties, we need to clarify whether: 1) changes to *all* properties ought to be taken into account for setting the modification date, or only 2) changes to the *dead* properties plus some selected live properties (e.g. non-protected properties). I would go for 2). Regards, Peter > -----Original Message----- > From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] > Sent: Monday, September 08, 2003 17:19 > To: w3c-dist-auth@w3c.org > Subject: DAV:bindings-last-modified (was RE: DAV:getlastmodified of > collections) > > > > I believe that we have concluded that DAV:getlastmodified depends on > what the server returns on a GET on a collection, and therefore is not > something we can define (since what the server returns on a GET on a > collection is not defined). So what we are really talking about in > this thread is a new property (which without much thought, I've named > DAV:bindings-last-modified). > > This raises the key question: what will the client be using this new > property for. I suggest it be used to keep the structure of a client > tree display synchronized with the names and resources on the server, > in which case the client doesn't care whether the version-controlled > state changes, as long as the named tree of resources is still valid. > > Cheers, > Geoff > > > > "Julian Reschke" wrote on > 09/05/2003 06:08:11 > PM: > > > > But then we're missing the case of VERSION-CONTROL on a > versionable > but not > > > > yet version-controlled resource that lives inside a versioned > collection (in > > > > which case I'd say the state of the parent collection *does* > change). > > > > Geoffrey M Clemm > > > I suggest we keep the semantics very simple, and say that > DAV:getlastmodified > > > is changed only by adding a binding, removing a binding, > or changing a > binding > > > to new resource. Putting an existing resource under > version control > does > > > none of these things, so it should not result in an update to > > > DAV:getlastmodified. > > > > > > Note that in general the "version-controlled state" of a > collection > will be > > > different from the "state" of a collection, i.e. adding > and removing a > binding > > > to a non-version-controlled resource does not change the > version-controlled > > > state of a collection, but does change the state of the > collection. > > "Julian Reschke" wrote on 09/08/2003 > 09:45:20 AM: > > This seems to imply that the version-controlled state is > not a subset of > the > > state, or more precisely, that you can modify the > version-controlled > state > > without changing the state. This IMHO seems to be a weird > way to define > the > > state of a collection. > > ------_=_NextPart_001_01C37620.073CEC10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DAV:modificationdate (was bindings-last-modified (was RE: = DAV:getlastmodified of collections))

I would prefer a more general new property, e.g. = DAV:modificationdate as proposed by Julian some days ago in another = thread (I added a few words about *bindings* of a collection to = Julian's wording):

    "A proper way to address this = may be to define a new optional property
    (if we make it optional, we may = be able to get it into RFC52518bis),
    for instance:

    = Name:        modificationdate =
    Namespace:   DAV: =
    Purpose:     = Records the time and date the resource was modified.
    = Value:       date-time   =
    Description: The creationdate = property should be defined on all DAV
          &nb= sp; compliant resources. If present, it contains a timestamp =
          &nb= sp; of the moment when the resource was last modified (i.e., the =
          &nb= sp; moment when content and/or properties last changed,
          &nb= sp; or, when the bindings of a collection last changed).
          &nb= sp; This property is live and protected. The Internet date-time
          &nb= sp; format is defined in [RFC3339], see the ABNF in section 5.6. =
    COPY/MOVE behavior: This property = value SHOULD be kept during a
          &nb= sp; MOVE operation, but is re-initialized when a resource is
          &nb= sp; created with a COPY. It should not be set in a remote COPY.

    <!ELEMENT modificationdate = (#PCDATA) >"

Probably, w.r.t. properties, we need to clarify = whether:
1) changes to *all* properties ought to be taken = into account for setting the modification date,
or only
2) changes to the *dead* properties plus some = selected live properties (e.g. non-protected properties).

I would go for 2).

Regards,
Peter

> -----Original Message-----
> From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.c= om]
> Sent: Monday, September 08, 2003 17:19
> To: w3c-dist-auth@w3c.org
> Subject: DAV:bindings-last-modified (was RE: = DAV:getlastmodified of
> collections)
>
>
>
> I believe that we have concluded that = DAV:getlastmodified depends on
> what the server returns on a GET on a = collection, and therefore is not
> something we can define (since what the server = returns on a GET on a
> collection is not defined). So what we = are really talking about in
> this thread is a new property (which without = much thought, I've named
> DAV:bindings-last-modified).
>
> This raises the key question: what will the = client be using this new
> property for. I suggest it be used to = keep the structure of a client
> tree display synchronized with the names and = resources on the server,
> in which case the client doesn't care whether = the version-controlled
> state changes, as long as the named tree of = resources is still valid.
>
> Cheers,
> Geoff
>
> > > "Julian Reschke" = <julian.reschke@gmx.de> wrote on
> 09/05/2003 06:08:11
> PM:
> > > > But then we're missing the case = of VERSION-CONTROL on a
> versionable
> but not
> > > > yet version-controlled resource = that lives inside a versioned
> collection (in
> > > > which case I'd say the state of = the parent collection *does*
> change).
>
> > > Geoffrey M Clemm
> > > I suggest we keep the semantics very = simple, and say that
> DAV:getlastmodified
> > > is changed only by adding a binding, = removing a binding,
> or changing a
> binding
> > > to new resource. Putting an = existing resource under
> version control
> does
> > > none of these things, so it should = not result in an update to
> > > DAV:getlastmodified.
> > >
> > > Note that in general the = "version-controlled state" of a
> collection
> will be
> > > different from the "state" = of a collection, i.e. adding
> and removing a
> binding
> > > to a non-version-controlled resource = does not change the
> version-controlled
> > > state of a collection, but does = change the state of the
> collection.
>
> "Julian Reschke" = <julian.reschke@gmx.de> wrote on 09/08/2003
> 09:45:20 AM:
> > This seems to imply that the = version-controlled state is
> not a subset of
> the
> > state, or more precisely, that you can = modify the
> version-controlled
> state
> > without changing the state. This IMHO = seems to be a weird
> way to define
> the
> > state of a collection.
>
>

------_=_NextPart_001_01C37620.073CEC10-- From w3c-dist-auth-request@w3.org Tue Sep 9 18:36:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10004 for ; Tue, 9 Sep 2003 18:36:20 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id D9F06A09CC; Tue, 9 Sep 2003 18:36:26 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A54DEA0A6C for ; Tue, 9 Sep 2003 18:36:24 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 842C013700; Tue, 9 Sep 2003 18:36:24 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from gate.arc.nasa.gov (gate.arc.nasa.gov [128.102.102.51]) by dr-nick.w3.org (Postfix) with ESMTP id 2C55613512 for ; Tue, 9 Sep 2003 18:36:24 -0400 (EDT) Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h89Ma4W25933; Tue, 9 Sep 2003 15:36:04 -0700 (PDT) Message-ID: <3F5E55F1.4030403@nasa.gov> Date: Tue, 09 Sep 2003 15:36:33 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm Cc: w3c-dist-auth@w3c.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: DAV:bindings-last-modified (was RE: DAV:getlastmodified of collections) X-Archived-At: http://www.w3.org/mid/3F5E55F1.4030403@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7869 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030909223626.D9F06A09CC@frink.w3.org> Resent-Date: Tue, 9 Sep 2003 18:36:26 -0400 (EDT) Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: >I believe that we have concluded that DAV:getlastmodified depends on >what the server returns on a GET on a collection, and therefore is not >something we can define (since what the server returns on a GET on a >collection is not defined). > Actually, since many servers do implement GET on a collection, how about saying "DAV:getlastmodified should be defined for collections if the server supports GET on collections and the value of the property would be the last time some operation changed what would be the result of a GET operation (and would be the value that would be compared against if a Last-Modified header was sent on said GET request)"? Sorry, my brain is not thinking in protocol-spec-speak right now, but I think you get the idea. Your other property for bindings would be useful as well, and I would guess that many implementations would make them equivalent (as a GET on a collection would return an HTML rendering of the bindings from that collection.) From w3c-dist-auth-request@w3.org Tue Sep 9 19:48:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12955 for ; Tue, 9 Sep 2003 19:48:41 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 3B700A0A0B; Tue, 9 Sep 2003 19:48:42 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id D6080A0A0B for ; Tue, 9 Sep 2003 19:48:35 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 31F5213BB2; Tue, 9 Sep 2003 19:39:21 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id F40C713B7C for ; Tue, 9 Sep 2003 19:39:20 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19ws4t-0002cS-00; Tue, 09 Sep 2003 23:39:19 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19ws4t-0002cD-00; Tue, 09 Sep 2003 23:39:19 +0000 From: "Lisa Dusseault" To: "'Chris Knight'" , "'Geoffrey M Clemm'" Cc: Date: Tue, 9 Sep 2003 16:39:19 -0700 Message-ID: <006a01c3772b$96db9d60$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-reply-to: <3F5E55F1.4030403@nasa.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: Christopher.D.Knight@nasa.gov, geoffrey.clemm@us.ibm.com, w3c-dist-auth@w3c.org Subject: RE: DAV:bindings-last-modified (was RE: DAV:getlastmodified of collections) X-Archived-At: http://www.w3.org/mid/006a01c3772b$96db9d60$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7870 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030909234842.3B700A0A0B@frink.w3.org> Resent-Date: Tue, 9 Sep 2003 19:48:42 -0400 (EDT) Content-Transfer-Encoding: 7bit This sounds like the right general idea. I'm starting to think that RFC2518 needs a new section, a non-normative note or warning on the dangers of relying on the value of 'getlastmodified'. As far as I can tell: - some servers allow this to be modified by clients - on a MOVE, some servers set the destination getlastmodified to the source's previous value, others set it to the timestamp of the operation itself - on a COPY, same thing, but probably not on all the same servers that do the MOVE that way - some servers allow underlying file system operations to replace files with new files with *older* getlastmodified values - some servers modify getlastmodifed when props change - the behavior on directories is probably completely random Thus, clients can't rely on the value of getlastmodified (or the Last-Modified header) at all and should use ETags instead. If the server doesn't support ETags the client is screwed. In that case, possibly the only reasonable thing is to throw away your cached version anytime the last modified value changes an iota, even if it changes to be *earlier* than your cached version. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Chris Knight > Sent: Tuesday, September 09, 2003 3:37 PM > To: Geoffrey M Clemm > Cc: w3c-dist-auth@w3c.org > Subject: Re: DAV:bindings-last-modified (was RE: > DAV:getlastmodified of collections) > > > > Geoffrey M Clemm wrote: > > >I believe that we have concluded that DAV:getlastmodified depends on > >what the server returns on a GET on a collection, and > therefore is not > >something we can define (since what the server returns on a GET on a > >collection is not defined). > > > Actually, since many servers do implement GET on a > collection, how about > saying "DAV:getlastmodified should be defined for collections if the > server supports GET on collections and the value of the > property would > be the last time some operation changed what would be the result of a > GET operation (and would be the value that would be compared > against if > a Last-Modified header was sent on said GET request)"? > > Sorry, my brain is not thinking in protocol-spec-speak right > now, but I > think you get the idea. > > Your other property for bindings would be useful as well, and I would > guess that many implementations would make them equivalent > (as a GET on > a collection would return an HTML rendering of the bindings from that > collection.) > > From w3c-dist-auth-request@w3.org Tue Sep 9 22:02:14 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16672 for ; Tue, 9 Sep 2003 22:02:13 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 9A531A0553; Tue, 9 Sep 2003 22:02:19 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EA4D0A0BCD for ; Tue, 9 Sep 2003 22:02:16 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 9B245137C1; Tue, 9 Sep 2003 22:02:16 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (Postfix) with ESMTP id 7FC4B1334C for ; Tue, 9 Sep 2003 22:02:16 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h8A22G0H759502 for ; Tue, 9 Sep 2003 22:02:16 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8A22FYT229590 for ; Tue, 9 Sep 2003 22:02:15 -0400 In-Reply-To: <006a01c3772b$96db9d60$f8cb90c6@lisalap> To: w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 9 Sep 2003 22:02:11 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/09/2003 22:02:15, Serialize complete at 09/09/2003 22:02:15 Content-Type: multipart/alternative; boundary="=_alternative 000A222B85256D9D_=" Subject: RE: DAV:bindings-last-modified (was RE: DAV:getlastmodified of collections) X-Archived-At: http://www.w3.org/mid/OF20BE7008.938E407D-ON85256D9D.0009C2F3-85256D9D.000B2FF5@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7871 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20030910020219.9A531A0553@frink.w3.org> Resent-Date: Tue, 9 Sep 2003 22:02:19 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 000A222B85256D9D_= Content-Type: text/plain; charset="US-ASCII" I agree with Lisa's points below, especially the last point, i.e. that we should provide guidance to clients that they should always check for equality of the Last-Modified value to what they previously retrieved. Cheers, Geoff "Lisa Dusseault" wrote on 09/09/2003 07:39:19 PM: > This sounds like the right general idea. > > I'm starting to think that RFC2518 needs a new section, a non-normative > note or warning on the dangers of relying on the value of > 'getlastmodified'. As far as I can tell: > - some servers allow this to be modified by clients > - on a MOVE, some servers set the destination getlastmodified to > the source's previous value, others set it to the timestamp of the > operation itself > - on a COPY, same thing, but probably not on all the same servers > that do the MOVE that way > - some servers allow underlying file system operations to replace > files with new files with *older* getlastmodified values > - some servers modify getlastmodifed when props change > - the behavior on directories is probably completely random > > Thus, clients can't rely on the value of getlastmodified (or > the Last-Modified header) at all and should use ETags instead. > If the server doesn't support ETags the client is screwed. > In that case, possibly the only reasonable thing is to throw > away your cached version anytime the last modified value changes > an iota, even if it changes to be *earlier* than your cached > version. > > Lisa > --=_alternative 000A222B85256D9D_= Content-Type: text/html; charset="US-ASCII"
I agree with Lisa's points below, especially the last point, i.e.
that we should provide guidance to clients that they should always
check for equality of the Last-Modified value to what they
previously retrieved.

Cheers,
Geoff

"Lisa Dusseault" <lisa@xythos.com> wrote on 09/09/2003 07:39:19 PM: > This sounds like the right general idea. > > I'm starting to think that RFC2518 needs a new section, a non-normative > note or warning on the dangers of relying on the value of > 'getlastmodified'. As far as I can tell: > - some servers allow this to be modified by clients > - on a MOVE, some servers set the destination getlastmodified to > the source's previous value, others set it to the timestamp of the > operation itself > - on a COPY, same thing, but probably not on all the same servers > that do the MOVE that way > - some servers allow underlying file system operations to replace > files with new files with *older* getlastmodified values > - some servers modify getlastmodifed when props change > - the behavior on directories is probably completely random > > Thus, clients can't rely on the value of getlastmodified (or > the Last-Modified header) at all and should use ETags instead. > If the server doesn't support ETags the client is screwed. > In that case, possibly the only reasonable thing is to throw > away your cached version anytime the last modified value changes > an iota, even if it changes to be *earlier* than your cached > version. > > Lisa > --=_alternative 000A222B85256D9D_=-- From w3c-dist-auth-request@w3.org Tue Sep 9 22:02:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16727 for ; Tue, 9 Sep 2003 22:02:27 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 4C869A08F4; Tue, 9 Sep 2003 22:02:22 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id D3BCCA08F4 for ; Tue, 9 Sep 2003 22:02:19 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 822AB13A20; Tue, 9 Sep 2003 22:02:19 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id 6D28D13A02 for ; Tue, 9 Sep 2003 22:02:19 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h8A22JWq305590 for ; Tue, 9 Sep 2003 22:02:19 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8A22IYT229600 for ; Tue, 9 Sep 2003 22:02:18 -0400 In-Reply-To: <3F5E55F1.4030403@nasa.gov> To: w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm