From w3c-dist-auth-request@w3.org Wed May 2 12:29:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16360 for ; Wed, 2 May 2001 12:29:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA17323; Wed, 2 May 2001 10:01:04 -0400 (EDT) Resent-Date: Wed, 2 May 2001 10:01:04 -0400 (EDT) Resent-Message-Id: <200105021401.KAA17323@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA17294 for ; Wed, 2 May 2001 10:00:58 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA13390 for ; Wed, 2 May 2001 10:00:59 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA75578 for ; Wed, 2 May 2001 09:57:46 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id JAA50446 for ; Wed, 2 May 2001 09:54:08 -0400 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 2 May 2001 00:44:57 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 05/02/2001 09:59:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4876 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: Hey everyone. I didn't mean to silence everyone with my note below. I think Jim still needs opinions to figure out the disposition of this issue. Do we have any more comments? I'll propose that we put this off until we know if there is an actual problem. Perhaps someone who felt there was a problem could speak up and add an opinion. Do you still think there is a problem that we need to solve? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com Jason Crawford/Watson/IBM@IBMUS@w3.org on 04/28/2001 02:03:04 PM Sent by: w3c-dist-auth-request@w3.org To: Greg Stein cc: WebDAV WG Subject: Re: Issue: ALLPROP_AND_COMPUTED << The issue isn't tossing allprop, but providing a warning to clients about dealing with expensive computed properties. Removing allprop does not solve the computed problem. Since allprop *is* useful, then there is no reason to remove it. >> I agree with Greg. We can still have this size problem with depth one and depth zero. And FTP's MGET can have a similar problem and we don't hear people complaining about that. Are we being overly concerned? We as authors of the spec can't know if this is a problem in advance either. Sometimes it will be and other times it won't be. Let's just deal with what a client or server can do in situations where they feel it's a problem. So... Is it sufficient for a client to simply disconnect/timeout? Should we have an error code that the server can use if it deems a request too expensive? Or is there some other simple approach? Or should we defer the issue until version 2.0 if it then looks like this truly is a problem? J. From w3c-dist-auth-request@w3.org Wed May 2 13:18:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17695 for ; Wed, 2 May 2001 13:18:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA21864; Wed, 2 May 2001 10:52:48 -0400 (EDT) Resent-Date: Wed, 2 May 2001 10:52:48 -0400 (EDT) Resent-Message-Id: <200105021452.KAA21864@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA21844 for ; Wed, 2 May 2001 10:52:43 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA17634 for ; Wed, 2 May 2001 10:52:41 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f42EqFj25865; Wed, 2 May 2001 07:52:15 -0700 (PDT) From: "Lisa Dusseault" To: "Jason Crawford" , Date: Wed, 2 May 2001 07:51:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4877 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit There is still a problem to solve, and it's not directly the expensive computations, though it is a result of that. Now that specs which extend RFC 2518 explicitly state that their properties should not be returned in an 'allprop', it no longer has the meaning it used to and clients need to be made aware of that. "Cat out of bag". From the client point of view, 'allprop' could be deprecated, repurposed, or renamed. - Deprecated would amount to "don't use allprop". - Repurposed would be "use it, but it doesn't mean what you think it means (it doesn't return all properties)". - Renamed it would presumably be 'coreprop' and return the properties defined in RFC2518 (except perhaps for lockdiscovery). lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Tuesday, May 01, 2001 9:45 PM > To: w3c-dist-auth@w3.org > Subject: Re: Issue: ALLPROP_AND_COMPUTED > > > > > Hey everyone. I didn't mean to silence everyone with my note below. I > think Jim still needs opinions to figure out the disposition of > this issue. > Do we have any more comments? > > I'll propose that we put this off until we know if there is an actual > problem. Perhaps someone who felt there was a problem could speak up and > add an opinion. Do you still think there is a problem that we need to > solve? > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > Jason Crawford/Watson/IBM@IBMUS@w3.org on 04/28/2001 02:03:04 PM > > Sent by: w3c-dist-auth-request@w3.org > > > To: Greg Stein > cc: WebDAV WG > Subject: Re: Issue: ALLPROP_AND_COMPUTED > > > > > > << > The issue isn't tossing allprop, but providing a warning to clients about > dealing with expensive computed properties. > > Removing allprop does not solve the computed problem. Since allprop *is* > useful, then there is no reason to remove it. > >> > I agree with Greg. We can still have this size problem with depth one and > depth zero. And FTP's MGET can have a similar problem and we don't hear > people complaining about that. Are we being overly concerned? We as > authors of the spec can't know if this is a problem in advance either. > Sometimes it will be and other times it won't be. Let's just deal with > what a client or server can do in situations where they feel it's a > problem. > > So... > > Is it sufficient for a client to simply disconnect/timeout? > Should we have > an error code that the server can use if it deems a request too expensive? > Or is there some other simple approach? Or should we defer the > issue until > version 2.0 if it then looks like this truly is a problem? > > J. > > > > > From w3c-dist-auth-request@w3.org Wed May 2 17:38:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24280 for ; Wed, 2 May 2001 17:38:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA13649; Wed, 2 May 2001 17:26:25 -0400 (EDT) Resent-Date: Wed, 2 May 2001 17:26:25 -0400 (EDT) Resent-Message-Id: <200105022126.RAA13649@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA13601 for ; Wed, 2 May 2001 17:26:16 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA15693; Wed, 2 May 2001 17:26:14 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f42LQ4j46700; Wed, 2 May 2001 14:26:05 -0700 (PDT) From: "Lisa Dusseault" To: "DeltaV" , Date: Wed, 2 May 2001 14:24:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4878 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit WebDAV people: RFC2518 leaves it carefully open whether 'getlastmodified' changes when properties of the resource change. It seems useful either way -- users might want to get the last time the content was changed, or they might want to see the last time the file was touched at all. Is there some precedent? Really, one might best be served by a new timestamp property, so the suite of timestamp-like properties would be - creationdate - time the content was last modified (etag changes, but etag doesn't provide a timestamp) - time the file was last touched Which one of the last two is most commonly handled by getlastmodified? Implementors speak up? DeltaV people: What does it mean to get the time file content was last "modified", if the file is versioned? I don't see that the behaviour of getlastmodified is specified for a Version-Controlled Resource, can this be a recommendation in the spec to promote consistency? For one thing, should 'getlastmodified' on the VCR change when it is checked out, or when it is checked in, or both? lisa From w3c-dist-auth-request@w3.org Wed May 2 18:25:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25333 for ; Wed, 2 May 2001 18:25:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA15534; Wed, 2 May 2001 18:14:08 -0400 (EDT) Resent-Date: Wed, 2 May 2001 18:14:08 -0400 (EDT) Resent-Message-Id: <200105022214.SAA15534@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA15491 for ; Wed, 2 May 2001 18:14:02 -0400 (EDT) Received: from elsmx60.mattel.net ([63.100.125.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA19175; Wed, 2 May 2001 18:13:51 -0400 Received: from estwr60.eshq.mattel.com (mailhub3.mattel.net [156.20.106.249]) by elsmx60.mattel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2YA5YG5K; Wed, 2 May 2001 15:13:40 -0700 Received: from 156.20.200.13 by estwr60.eshq.mattel.com (InterScan E-Mail VirusWall NT); Wed, 02 May 2001 15:15:56 -0700 (Pacific Daylight Time) Received: by estwr60.eshq.mattel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 15:15:56 -0700 Message-ID: <2ABD012C3FB72A44A0429F4CDAFE767602E470CB@estwr50a.eshq.mattel.com> From: "Harris, Matt" To: DeltaV , w3c-dist-auth@w3.org Date: Wed, 2 May 2001 15:11:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: File creation date, version creation date, and getlastmodifie d Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4881 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D354.D20265E0" ------_=_NextPart_001_01C0D354.D20265E0 Content-Type: text/plain; charset="iso-8859-1" I am an implementer, not a developer, but I do have an opinion on this one. For process workflow applications, it is very important to know when the resource is last changed. I care less about property changes, although that event is key for backup software. I would like to see both tracked. As far as versioning is concerned, it will often be important to know both when Check-out occurred and when Check-in occurred, however, getlastmodified should only reflect Check-in. This is because the resource has not been modified, as far as DAV is concerned, until that Check-in has occurred. To keep this consistent with the three properties you listed, getlasttouched would reflect the Check-out event because the file lock was set, while getlastmodified would not. On Checked-in both would be updated. Matt Harris > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Wednesday, May 02, 2001 2:25 PM > To: DeltaV; w3c-dist-auth@w3.org > Subject: File creation date, version creation date, and > getlastmodified > > > > WebDAV people: RFC2518 leaves it carefully open whether > 'getlastmodified' > changes when properties of the resource change. It seems > useful either > way -- users might want to get the last time the content was > changed, or > they might want to see the last time the file was touched at > all. Is there > some precedent? Really, one might best be served by a new timestamp > property, so the suite of timestamp-like properties would be > - creationdate > - time the content was last modified (etag changes, but etag doesn't > provide a timestamp) > - time the file was last touched > > Which one of the last two is most commonly handled by getlastmodified? > Implementors speak up? > > DeltaV people: What does it mean to get the time file content was last > "modified", if the file is versioned? I don't see that the > behaviour of > getlastmodified is specified for a Version-Controlled > Resource, can this be > a recommendation in the spec to promote consistency? For one > thing, should > 'getlastmodified' on the VCR change when it is checked out, > or when it is > checked in, or both? > > lisa > ------_=_NextPart_001_01C0D354.D20265E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: File creation date, version creation date, and = getlastmodified

I am an implementer, not a developer, but I do have = an opinion on this one.

For process workflow applications, it is very = important to know when the resource is last changed.  I care less = about property changes, although that event is key for backup = software.  I would like to see both tracked.

As far as versioning is concerned, it will often be = important to know both when Check-out occurred and when Check-in = occurred, however, getlastmodified should only reflect Check-in.  = This is because the resource has not been modified, as far as DAV is = concerned, until that Check-in has occurred.  To keep this = consistent with the three properties you listed, getlasttouched would = reflect the Check-out event because the file lock was set, while = getlastmodified would not.  On Checked-in both would be = updated.

Matt Harris

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Wednesday, May 02, 2001 2:25 PM
> To: DeltaV; w3c-dist-auth@w3.org
> Subject: File creation date, version creation = date, and
> getlastmodified
>
>
>
> WebDAV people:  RFC2518 leaves it = carefully open whether
> 'getlastmodified'
> changes when properties of the resource = change.  It seems
> useful either
> way -- users might want to get the last time = the content was
> changed, or
> they might want to see the last time the file = was touched at
> all.  Is there
> some precedent?  Really, one might best be = served by a new timestamp
> property, so the suite of timestamp-like = properties would be
>  - creationdate
>  - time the content was last modified = (etag changes, but etag doesn't
> provide a timestamp)
>  - time the file was last touched
>
> Which one of the last two is most commonly = handled by getlastmodified?
> Implementors speak up?
>
> DeltaV people: What does it mean to get the = time file content was last
> "modified", if the file is = versioned?  I don't see that the
> behaviour of
> getlastmodified is specified for a = Version-Controlled
> Resource, can this be
> a recommendation in the spec to promote = consistency?  For one
> thing, should
> 'getlastmodified' on the VCR change when it is = checked out,
> or when it is
> checked in, or both?
>
> lisa
>

------_=_NextPart_001_01C0D354.D20265E0-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Wed May 2 21:02:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27681 for ; Wed, 2 May 2001 21:02:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA17133; Wed, 2 May 2001 18:53:37 -0400 (EDT) Resent-Date: Wed, 2 May 2001 18:53:37 -0400 (EDT) Resent-Message-Id: <200105022253.SAA17133@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA17108 for ; Wed, 2 May 2001 18:53:32 -0400 (EDT) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA21925 for ; Wed, 2 May 2001 18:53:29 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id PAA22603; Wed, 2 May 2001 15:56:29 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 2 May 2001 15:56:29 -0700 From: Greg Stein To: David Logan Cc: w3c-dist-auth@w3.org Message-ID: <20010502155629.A1374@lyra.org> Mail-Followup-To: David Logan , w3c-dist-auth@w3.org References: <3AF088B2.9AE6629@ind.tansu.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3AF088B2.9AE6629@ind.tansu.com.au>; from dlogan@ind.tansu.com.au on Thu, May 03, 2001 at 08:22:42AM +1000 X-URL: http://www.lyra.org/greg/ Subject: Re: IE5 & DAV Interoperability Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4884 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Thu, May 03, 2001 at 08:22:42AM +1000, David Logan wrote: >... > My understanding of IE5 Web Folders was that it was fairly compliant and > did not require extensions. Am I barking up the wrong tree? IE5 and mod_dav are very interoperable. > If this is not the right list for these comments, can somebody please > point me in the right direction? 8-) The dav-dev@lyra.org mailing list is the right place. See: http://www.webdav.org/mod_dav/install.html#problem For the information that we'll need to diagnose your problem, then post to the dav-dev list. Cheers, -g ps. w3c-dist-auth is generally "implementation agnostic" and is about the protocol itself. -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed May 2 22:23:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29452 for ; Wed, 2 May 2001 22:23:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA21373; Wed, 2 May 2001 20:41:37 -0400 (EDT) Resent-Date: Wed, 2 May 2001 20:41:37 -0400 (EDT) Resent-Message-Id: <200105030041.UAA21373@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA21353 for ; Wed, 2 May 2001 20:41:33 -0400 (EDT) Received: from smtp.ekeeper.com ([38.204.71.240]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA29955 for ; Wed, 2 May 2001 20:41:29 -0400 Received: from lisa ([24.11.181.185]) by smtp.ekeeper.com with Microsoft SMTPSVC(5.5.1877.197.19); Wed, 2 May 2001 19:41:08 -0500 From: "Douglas R. Steen" To: Date: Wed, 2 May 2001 19:41:16 -0500 Message-ID: <000601c0d369$c38935b0$78d7fea9@drsteen.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4885 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit re: WebDAV. My vote would be changing getlastmodified when the properties change. As we use properties more and more, they become a true part of the file in the user experience. Trying to distinguish between the two ("I know you changed the billing number yesterday, but you didn't change the _content_ so the date still reads last week...") can be difficult. Unfortunately, it's a very easy shorthand for server implementations to use the file last-modified date for getlastmodified, and for the operating systems I know that reflects the date/time of the last content modification. Douglas R. Steen dsteen@ekeeper.com Drag-and-Drop Web File Management http://www.eKeeper.com -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: Wednesday, May 02, 2001 4:25 PM To: DeltaV; w3c-dist-auth@w3.org Subject: File creation date, version creation date, and getlastmodified WebDAV people: RFC2518 leaves it carefully open whether 'getlastmodified' changes when properties of the resource change. It seems useful either way -- users might want to get the last time the content was changed, or they might want to see the last time the file was touched at all. Is there some precedent? Really, one might best be served by a new timestamp property, so the suite of timestamp-like properties would be - creationdate - time the content was last modified (etag changes, but etag doesn't provide a timestamp) - time the file was last touched Which one of the last two is most commonly handled by getlastmodified? Implementors speak up? DeltaV people: What does it mean to get the time file content was last "modified", if the file is versioned? I don't see that the behaviour of getlastmodified is specified for a Version-Controlled Resource, can this be a recommendation in the spec to promote consistency? For one thing, should 'getlastmodified' on the VCR change when it is checked out, or when it is checked in, or both? lisa From w3c-dist-auth-request@w3.org Wed May 2 23:15:39 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00946 for ; Wed, 2 May 2001 23:15:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA15964; Wed, 2 May 2001 18:24:44 -0400 (EDT) Resent-Date: Wed, 2 May 2001 18:24:44 -0400 (EDT) Resent-Message-Id: <200105022224.SAA15964@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA15938 for ; Wed, 2 May 2001 18:24:38 -0400 (EDT) Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA19848 for ; Wed, 2 May 2001 18:24:03 -0400 Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id IAA20112 for ; Thu, 3 May 2001 08:23:30 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0K88ub; Thu May 3 08:22:59 2001 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id IAA00883 for ; Thu, 3 May 2001 08:22:58 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "ind.tansu.com.au" via SMTP by localhost, id smtpdj.3Hy_; Thu May 3 08:22:42 2001 Received: (qmail 29324 invoked from network); 2 May 2001 22:22:42 -0000 Received: from lagoon.ind.tansu.com.au (HELO ind.tansu.com.au) (149.135.67.31) by tamar.ind.tansu.com.au with SMTP; 2 May 2001 22:22:42 -0000 Message-ID: <3AF088B2.9AE6629@ind.tansu.com.au> Date: Thu, 03 May 2001 08:22:42 +1000 From: David Logan Reply-To: dlogan@ind.tansu.com.au X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IE5 & DAV Interoperability Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4882 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Good Morning Folks, I have been attempting to get IE5 to talk to our apache 1.3.14 server using the mod_dav module. Having played around extensively I cannot, for the life of me, get IE5 talking to the server. It appears that I need to install Frontpage extensions. In reading the archives of this list, I can't see anywhere that this gets a mention as being a requirement. My understanding of IE5 Web Folders was that it was fairly compliant and did not require extensions. Am I barking up the wrong tree? If this is not the right list for these comments, can somebody please point me in the right direction? 8-) Thanks & Regards -- _______________________________________________________________ David Logan 102 Cameron Street Broadband e-Lab Launceston Tas 7250 Australia Ph : (03) 6323 2667 Fax: (03) 6323 2666 From w3c-dist-auth-request@w3.org Thu May 3 01:53:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08447 for ; Thu, 3 May 2001 01:53:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA16131; Wed, 2 May 2001 18:27:54 -0400 (EDT) Resent-Date: Wed, 2 May 2001 18:27:54 -0400 (EDT) Resent-Message-Id: <200105022227.SAA16131@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA16099 for ; Wed, 2 May 2001 18:27:50 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA20115 for ; Wed, 2 May 2001 18:27:46 -0400 Received: from gmgw01.oraclecorp.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail3.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f42MOHP25068; Wed, 2 May 2001 15:24:17 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-33.us.oracle.com [130.35.171.33]) by gmgw01.oraclecorp.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f42MR7W18740; Wed, 2 May 2001 15:27:07 -0700 (PDT) From: "Eric Sedlar" To: "Yaron Goland" , "webdav ACL Group" Cc: Date: Wed, 2 May 2001 15:31:47 -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.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: [ACL] Reviewing the ACL Spec - Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4883 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 1 Semantics as a Property > > The information contained in the semantics property describes information > about the type of a resource. This is exactly the type of information RFC > 2518 requires to be placed in the resource type. Therefore I move that the > semantics property be removed and this data be supplied in the > resource type > property. Please also refer to my e-mail on IsPrincipal. I don't have a problem with allowing dav:resourcetype to list all of the abstract interfaces that a resource supports, as I mentioned in my last mail. However, this should only be done as part of a general RFC2518 revision, IMHO. > 2 Semantics on any ACL'd Resource > > The values in the semantics property do a good job of capturing > most of the > axis's of functionality but a few were missed. I list below those I could > find. > > Principals Identified by HTTP URL - Does the resource require that all > principals it uses are referenced by at least one HTTP URL? Hopefully the > need for this extension to the semantics section will go away when the > specification is changed to mandate support for HTTP URLs. Please > also refer > to my e-mail on multiple principals. > > Allows Group Principals - Will the resource support principal references, > either in ACEs or for owner, that contain group principals? > > Recursive Principals - Will the resource support principal references, > either in ACEs or for owner, that contain group principals that allow > recursive principals? > > Inheritance Policy - Semantic information is needed on what sort of > inheritance policy the resource follows. At a minimum we should > specify the > Windows NT, Oracle and popular UNIX policies. Given that > representatives of > both Microsoft and Oracle are authors on the spec and given the number of > working group members familiar with UNIX, I assume that the > expertise exists > in the group to build these descriptions. > > Write-able Owner - The Owner property may or may not be write-able. This > information needs to be specified in the semantics. Hopefully we > will adopt > a method to modify owner. If so then no value is necessary in the > semantics > section because OPTIONS will list if the owner modification method is > supported. The original intent of the semantics property was to allow clients to be able to evaluate an ACL, or give the user some clue as to how the ACL will be evaluated by the server, so the client knows how to author them. It wasn't intended as a general capabilities discovery method. As far as your specific suggestions, my take is: * Recursive groups: this is getting into the area of user/group admin, which we are explicitly trying to stay out of. We also don't allow you to ask all of the groups you are a member of. I'm not sure there is a lot of support for going into this area in the first rev of the spec. However, if we were to do so, we could add either a property to principal collections or make that a defined element tag allowed in (as per that discussion). * Inheritance policy: the only people who cared about this were me (Oracle) & Anne Hopkins (Microsoft), and Anne recently left Microsoft. Our implementations were different enough that it would be good to see what other people wanted before doing something interoperable here so we deferred this to a later "Advanced" spec. * The list of writeable properties may or may not include owner, but this is a general RFC2518 problem. Perhaps we should have a property that lists writeable property names rather than trying to put the list of writeable live properties in the spec. > 3 Semantics specific to Group Principals > > Recursive Principals - Will this group principal allow recursive principal > membership? > See above comment. > 4 Semantics specific to Collections > > Default ACL Policy - We need to add semantic information to collections > specifying the ACLs that will appear when a child is created. The default > ACL is not necessarily defined exclusively by inheritance. I vaguely > recollect systems that allow users to specify additional default ACEs. For > example, an administrator can add default ACEs that specify that all new > resources are read-only, except by their owner. > BTW, can users safely assume that the inheritance policy > specified on the > collection will also apply to its children? If not, then we need > to specify > what inheritance policy applies to the children as part of the default ACL > policy value. We can provide this information for the root "/" of a server > by accessing the reserved "*" URL. > There are way too many ways to specify the default ACL to get good interoperability. You can specify a default ACL per user (like the Unix UMASK). You can specify a default ACL per directory (Apache allows this). You can specify a default ACL by type (Principals have this default ACL). Perhaps each user wants to specify their own ACL for a particular type (when I create a particular type of resource, it should have this ACL). That's why I think we should defer this to the "Advanced" spec. > 5 ERROR CODES > > We need to specify error codes specific to violating each of the semantics > we specify. Geoff has more notes about this issue and what format > we should > use. > If we extend to list the set of supported interfaces on the resource, we probably need a "Interface not supported" error code. From w3c-dist-auth-request@w3.org Thu May 3 01:59:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09239 for ; Thu, 3 May 2001 01:59:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA14464; Wed, 2 May 2001 17:54:32 -0400 (EDT) Resent-Date: Wed, 2 May 2001 17:54:32 -0400 (EDT) Resent-Message-Id: <200105022154.RAA14464@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA14418 for ; Wed, 2 May 2001 17:54:25 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA17709; Wed, 2 May 2001 17:54:24 -0400 Received: from gmgw01.oraclecorp.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail3.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f42LosP09394; Wed, 2 May 2001 14:50:54 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-33.us.oracle.com [130.35.171.33]) by gmgw01.oraclecorp.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f42LriW18216; Wed, 2 May 2001 14:53:44 -0700 (PDT) From: "Eric Sedlar" To: "DeltaV" , Date: Wed, 2 May 2001 14:58:25 -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.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4880 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit We update getlastmodified whenever properties or contents change. Either of these is reflected in the ETag. I'm not sure we need another property to handle changes to the properties separately. > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, May 02, 2001 2:25 PM > To: DeltaV; w3c-dist-auth@w3.org > Subject: File creation date, version creation date, and getlastmodified > > > > WebDAV people: RFC2518 leaves it carefully open whether 'getlastmodified' > changes when properties of the resource change. It seems useful either > way -- users might want to get the last time the content was changed, or > they might want to see the last time the file was touched at all. > Is there > some precedent? Really, one might best be served by a new timestamp > property, so the suite of timestamp-like properties would be > - creationdate > - time the content was last modified (etag changes, but etag doesn't > provide a timestamp) > - time the file was last touched > > Which one of the last two is most commonly handled by getlastmodified? > Implementors speak up? > > DeltaV people: What does it mean to get the time file content was last > "modified", if the file is versioned? I don't see that the behaviour of > getlastmodified is specified for a Version-Controlled Resource, > can this be > a recommendation in the spec to promote consistency? For one > thing, should > 'getlastmodified' on the VCR change when it is checked out, or when it is > checked in, or both? > > lisa > > From w3c-dist-auth-request@w3.org Thu May 3 01:59:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09249 for ; Thu, 3 May 2001 01:59:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA14358; Wed, 2 May 2001 17:52:00 -0400 (EDT) Resent-Date: Wed, 2 May 2001 17:52:00 -0400 (EDT) Resent-Message-Id: <200105022152.RAA14358@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA14338 for ; Wed, 2 May 2001 17:51:55 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA17547 for ; Wed, 2 May 2001 17:51:51 -0400 Received: from gmgw01.oraclecorp.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail3.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f42LmKP07922; Wed, 2 May 2001 14:48:20 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-33.us.oracle.com [130.35.171.33]) by gmgw01.oraclecorp.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f42LpAW13781; Wed, 2 May 2001 14:51:10 -0700 (PDT) From: "Eric Sedlar" To: "webdav ACL Group" Cc: Date: Wed, 2 May 2001 14:55:51 -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.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: [ACL] Reviewing the ACL Spec - IsPrincipal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4879 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit We had many discussions about whether or not to try to stick in dav:resourcetype. The consensus of the working group was that dav:resourcetype is too simple to extend nicely. The other issue other than the WebFolders bug you are alluding to is that there isn't really a type system in WebDAV. What you want is to define all of the abstract interfaces that a resource supports. The Java version of this might be: public class Group extends ietf.webdav.Resource implements ietf.webdav.Principal, ietf.webdav.Versioned, ietv.webdav.Collection { } Since we are reexamining RFC2518 at the same time we are releasing versioning & ACLs, maybe we should address this? I think this is a general problem. DeltaV addresses the "what interfaces do you support" question by looking for particular properties, which is also kind of hokey. Whaddaya think, Jim W? > -----Original Message----- > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of > Yaron Goland > Sent: Wednesday, May 02, 2001 1:35 PM > To: webdav ACL Group > Subject: [ACL] Reviewing the ACL Spec - IsPrincipal > > > IsPrincipal really confused me. I couldn't understand why it would be > necessary given that we have the resource type property and RFC 2518 very > clearly specifies that values such as "is a resource a principal" > should be > listed in resource type. > > I achieved a better understanding of the situation when it was pointed out > to me that a corporation, who shall remain nameless, has a bug in > its WebDAV > clients. The bug is that if the client retrieves a resource type and the > property contains any value at all then the client assumes the > resource is a > collection. > > The IETF does not set its standards based on bugs in > implementer's products. > As such IsPrincipal should be immediately removed and replaced, in > accordance with RFC 2518, with a value in the resource type property. > > > > > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl > From w3c-dist-auth-request@w3.org Thu May 3 02:15:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16443 for ; Thu, 3 May 2001 02:15:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA27911; Wed, 2 May 2001 23:51:29 -0400 (EDT) Resent-Date: Wed, 2 May 2001 23:51:29 -0400 (EDT) Resent-Message-Id: <200105030351.XAA27911@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA27891 for ; Wed, 2 May 2001 23:51:20 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id XAA13782 for ; Wed, 2 May 2001 23:51:20 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 02 May 2001 23:53:14 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 23:53:14 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102DB8BBC@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 2 May 2001 23:53:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4886 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I am adamantly opposed to DAV:allprop. In the context of computed live properties, a client should never blindly ask for all property values ... it should always first ask for DAV:propname, and then use the subset that it can use. The WebDAV versioning extensions explicitly allows a server to *not* return the versioning properties in response to a DAV:allprop request, so DAV:propname will be the only reliable way of obtaining all the properties. Finally, the fact that PROPFIND/DAV:allprop is trivially replaceable with two PROPFIND calls (the first being PROPFIND/DAV:propname) makes DAV:allprop superfluous (in addition to being inadvisable). I spoke to Yaron Goland earlier this week (about the ACL spec), and he believes DAV:allprop should be removed/deprecated as well. Protocol's are complex enough with important/required features. A feature that is prone to misuse and is redundant is a serious error, and should be removed in the next draft. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Wednesday, May 02, 2001 12:45 AM To: w3c-dist-auth@w3.org Subject: Re: Issue: ALLPROP_AND_COMPUTED Hey everyone. I didn't mean to silence everyone with my note below. I think Jim still needs opinions to figure out the disposition of this issue. Do we have any more comments? I'll propose that we put this off until we know if there is an actual problem. Perhaps someone who felt there was a problem could speak up and add an opinion. Do you still think there is a problem that we need to solve? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com Jason Crawford/Watson/IBM@IBMUS@w3.org on 04/28/2001 02:03:04 PM Sent by: w3c-dist-auth-request@w3.org To: Greg Stein cc: WebDAV WG Subject: Re: Issue: ALLPROP_AND_COMPUTED << The issue isn't tossing allprop, but providing a warning to clients about dealing with expensive computed properties. Removing allprop does not solve the computed problem. Since allprop *is* useful, then there is no reason to remove it. >> I agree with Greg. We can still have this size problem with depth one and depth zero. And FTP's MGET can have a similar problem and we don't hear people complaining about that. Are we being overly concerned? We as authors of the spec can't know if this is a problem in advance either. Sometimes it will be and other times it won't be. Let's just deal with what a client or server can do in situations where they feel it's a problem. So... Is it sufficient for a client to simply disconnect/timeout? Should we have an error code that the server can use if it deems a request too expensive? Or is there some other simple approach? Or should we defer the issue until version 2.0 if it then looks like this truly is a problem? J. From w3c-dist-auth-request@w3.org Thu May 3 07:00:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18402 for ; Thu, 3 May 2001 07:00:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA12140; Thu, 3 May 2001 06:51:48 -0400 (EDT) Resent-Date: Thu, 3 May 2001 06:51:48 -0400 (EDT) Resent-Message-Id: <200105031051.GAA12140@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA12094 for ; Thu, 3 May 2001 06:51:41 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA13850; Thu, 3 May 2001 06:51:02 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id LAA28706; Thu, 3 May 2001 11:34:00 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id LAA80246; Thu, 3 May 2001 11:49:26 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A41.003B7427 ; Thu, 3 May 2001 11:49:23 +0100 X-Lotus-FromDomain: IBMGB To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Message-ID: <80256A41.003B6FE8.00@d06mta07.portsmouth.uk.ibm.com> Date: Thu, 3 May 2001 11:49:10 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4888 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Lisa Dusseault wrote: > WebDAV people: RFC2518 leaves it carefully open whether > 'getlastmodified' changes when properties of the resource > change. It seems useful either way -- users might want to > get the last time the content was changed, or they might > want to see the last time the file was touched at all. Is > there some precedent? I seem to recall that moddav does not change the last modified timestamp when properties are updated. There has been discussion on this topic previously, with a weak consensus that the properties should not contribute to last modified changes. I think this is the right answer. Peter Raymond wrote: > One example of why we keep the "last modified" date separate > is that our build system uses this to compare with timestamps > of files on disk to decide if the file is out of date. If the > WebDAV client set the last modification time each time a > property was changed then the build system would think the file > on disk was "out of date" compared to the file held in version > control. I think that this is a common scenario, also found on caching proxies, that relies upon property updates not being considered a change to the resource. Clearly there is some ambiguity here. On the one hand, properties appear to be 'part of' a resource. They appear when a resource is created, and disappear when a resource is deleted. Operations on a property are via the URL of the resource. However, live properties exhibit behaviour that sets them apart from the resource. They can change even when a resource is versioned or locked, and (at least in a couple of implementations) changes to the resource's properties do not change the last modified timestamp of the resource. Lisa Dusseault wrote: > DeltaV people: What does it mean to get the time file content > was last "modified", if the file is versioned? I don't see > that the behaviour of getlastmodified is specified for a > Version-Controlled Resource, can this be a recommendation in > the spec to promote consistency? For one thing, should > 'getlastmodified' on the VCR change when it is checked out, > or when it is checked in, or both? When a version-controlled resource is checked-out its contents and dead properties are updated to be the same as the version identified in the DAV:checked-in property. Therefore the DAV:getlastmodified timestamp clearly should be updated to reflect the changes. Note that the timestamp value is the server's notion of the time the version-controlled resource was modified and not the same as the checked-in version's DAV:getlastmodified. When a version-controlled resource is checked-in, its content and dead properties become those of a new version in the version history. Some live properties of the version-controlled resource are updated to reflect its checked-in status. In this case I argue that the DAV:getlastmodified timestamp does not change. Furthermore, if you use UPDATE to update the content and dead properties of a version-controlled resource to reflect the state of a version in version history, the DAV:getlastmodified timestamp will be the time that the UPDATE method was applied and not that of the version. It it were otherwise updating the version-controlled resource to an earlier version would make the last modified time go 'backwards' which would potentially screw up caching proxies and clients that rely on If-Unmodified-Since: headers etc. > - time the file was last touched What is your definition of touched? Dead property updates? Given the number of live / computed properties I assume you agree that their values do not contribute to the touched timestamp? Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 From w3c-dist-auth-request@w3.org Thu May 3 07:19:43 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18690 for ; Thu, 3 May 2001 07:19:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA08993; Thu, 3 May 2001 05:30:30 -0400 (EDT) Resent-Date: Thu, 3 May 2001 05:30:30 -0400 (EDT) Resent-Message-Id: <200105030930.FAA08993@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA08903 for ; Thu, 3 May 2001 05:30:19 -0400 (EDT) Received: from egateout.merant.com (rock-gate.merant.com [63.79.165.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA07040; Thu, 3 May 2001 05:30:18 -0400 Received: from stalmail.eu.merant.com ([10.130.13.220]) by egateout.merant.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id FAA26646; Thu, 03 May 2001 05:25:17 -0400 Received: by stalmail.eu.merant.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 10:31:05 +0100 Message-ID: <20CF1CE11441D411919C0008C7C5A13B01D03BA4@stalmail.eu.merant.com> From: Peter Raymond To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Date: Thu, 3 May 2001 10:31:01 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: File creation date, version creation date, and getlastmodifie d Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4887 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi, I am not sure that properties are necessarily "becoming a true part of the file", our system is a complete workflow based SCM system with build capabilities etc. WebDAV clients will be using the same repository/server as the rest of our application. Some of our properties like "workflow state" for example, are not directly related to the file content. We track the last modification time (in UTC) of the file content at check-in time. Separately we track the last time the file had any property changed etc, this includes promoting through the workflow, changing properties, locking/unlocking, adding/removing from a collection etc. One example of why we keep the "last modified" date separate is that our build system uses this to compare with timestamps of files on disk to decide if the file is out of date. If the WebDAV client set the last modification time each time a property was changed then the build system would think the file on disk was "out of date" compared to the file held in version control. I am in favor of Lisa's suggestion of having three timestamps. Regards, -- Peter Raymond - MERANT Technical Architect (ADM) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com -----Original Message----- From: Douglas R. Steen [mailto:dsteen@ekeeper.com] Sent: Thursday, May 03, 2001 1:41 AM To: w3c-dist-auth@w3.org Subject: RE: File creation date, version creation date, and getlastmodified re: WebDAV. My vote would be changing getlastmodified when the properties change. As we use properties more and more, they become a true part of the file in the user experience. Trying to distinguish between the two ("I know you changed the billing number yesterday, but you didn't change the _content_ so the date still reads last week...") can be difficult. Unfortunately, it's a very easy shorthand for server implementations to use the file last-modified date for getlastmodified, and for the operating systems I know that reflects the date/time of the last content modification. Douglas R. Steen dsteen@ekeeper.com Drag-and-Drop Web File Management http://www.eKeeper.com -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: Wednesday, May 02, 2001 4:25 PM To: DeltaV; w3c-dist-auth@w3.org Subject: File creation date, version creation date, and getlastmodified WebDAV people: RFC2518 leaves it carefully open whether 'getlastmodified' changes when properties of the resource change. It seems useful either way -- users might want to get the last time the content was changed, or they might want to see the last time the file was touched at all. Is there some precedent? Really, one might best be served by a new timestamp property, so the suite of timestamp-like properties would be - creationdate - time the content was last modified (etag changes, but etag doesn't provide a timestamp) - time the file was last touched Which one of the last two is most commonly handled by getlastmodified? Implementors speak up? DeltaV people: What does it mean to get the time file content was last "modified", if the file is versioned? I don't see that the behaviour of getlastmodified is specified for a Version-Controlled Resource, can this be a recommendation in the spec to promote consistency? For one thing, should 'getlastmodified' on the VCR change when it is checked out, or when it is checked in, or both? lisa From w3c-dist-auth-request@w3.org Thu May 3 10:32:42 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25680 for ; Thu, 3 May 2001 10:32:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA16314; Thu, 3 May 2001 08:31:16 -0400 (EDT) Resent-Date: Thu, 3 May 2001 08:31:16 -0400 (EDT) Resent-Message-Id: <200105031231.IAA16314@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA16272 for ; Thu, 3 May 2001 08:31:11 -0400 (EDT) Received: from hatfield.mail.uk.easynet.net (hatfield.mail.uk.easynet.net [195.40.1.39]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA21315; Thu, 3 May 2001 08:31:00 -0400 Received: from piranha (unknown [194.242.154.34]) by hatfield.mail.uk.easynet.net (Postfix) with ESMTP id 08BEE22E18F; Thu, 3 May 2001 13:30:46 +0100 (BST) Received: from 192.168.3.2 by piranha; THU, 3 May 2001 13:20:59 -0700 Received: by PIRANHA with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 13:20:59 +0100 Message-ID: From: "jack vamvas-angryfish.uk.com" To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Date: Thu, 3 May 2001 13:20:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: File creation date, version creation date, and getlastmodifie d Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4889 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: unsubscribe -----Original Message----- From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] Sent: Thursday, May 03, 2001 11:49 AM To: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org Subject: RE: File creation date, version creation date, and getlastmodified Lisa Dusseault wrote: > WebDAV people: RFC2518 leaves it carefully open whether > 'getlastmodified' changes when properties of the resource > change. It seems useful either way -- users might want to > get the last time the content was changed, or they might > want to see the last time the file was touched at all. Is > there some precedent? I seem to recall that moddav does not change the last modified timestamp when properties are updated. There has been discussion on this topic previously, with a weak consensus that the properties should not contribute to last modified changes. I think this is the right answer. Peter Raymond wrote: > One example of why we keep the "last modified" date separate > is that our build system uses this to compare with timestamps > of files on disk to decide if the file is out of date. If the > WebDAV client set the last modification time each time a > property was changed then the build system would think the file > on disk was "out of date" compared to the file held in version > control. I think that this is a common scenario, also found on caching proxies, that relies upon property updates not being considered a change to the resource. Clearly there is some ambiguity here. On the one hand, properties appear to be 'part of' a resource. They appear when a resource is created, and disappear when a resource is deleted. Operations on a property are via the URL of the resource. However, live properties exhibit behaviour that sets them apart from the resource. They can change even when a resource is versioned or locked, and (at least in a couple of implementations) changes to the resource's properties do not change the last modified timestamp of the resource. Lisa Dusseault wrote: > DeltaV people: What does it mean to get the time file content > was last "modified", if the file is versioned? I don't see > that the behaviour of getlastmodified is specified for a > Version-Controlled Resource, can this be a recommendation in > the spec to promote consistency? For one thing, should > 'getlastmodified' on the VCR change when it is checked out, > or when it is checked in, or both? When a version-controlled resource is checked-out its contents and dead properties are updated to be the same as the version identified in the DAV:checked-in property. Therefore the DAV:getlastmodified timestamp clearly should be updated to reflect the changes. Note that the timestamp value is the server's notion of the time the version-controlled resource was modified and not the same as the checked-in version's DAV:getlastmodified. When a version-controlled resource is checked-in, its content and dead properties become those of a new version in the version history. Some live properties of the version-controlled resource are updated to reflect its checked-in status. In this case I argue that the DAV:getlastmodified timestamp does not change. Furthermore, if you use UPDATE to update the content and dead properties of a version-controlled resource to reflect the state of a version in version history, the DAV:getlastmodified timestamp will be the time that the UPDATE method was applied and not that of the version. It it were otherwise updating the version-controlled resource to an earlier version would make the last modified time go 'backwards' which would potentially screw up caching proxies and clients that rely on If-Unmodified-Since: headers etc. > - time the file was last touched What is your definition of touched? Dead property updates? Given the number of live / computed properties I assume you agree that their values do not contribute to the touched timestamp? Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 From w3c-dist-auth-request@w3.org Thu May 3 12:14:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28779 for ; Thu, 3 May 2001 12:14:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA00482; Thu, 3 May 2001 12:00:51 -0400 (EDT) Resent-Date: Thu, 3 May 2001 12:00:51 -0400 (EDT) Resent-Message-Id: <200105031600.MAA00482@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA00437 for ; Thu, 3 May 2001 12:00:45 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA06339; Thu, 3 May 2001 12:00:29 -0400 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id JAA27497; Thu, 3 May 2001 09:03:19 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id IAA17828; Thu, 3 May 2001 08:59:37 -0700 (PDT) Received: from [192.168.1.6] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GCROFM00.QG2; Thu, 3 May 2001 08:59:46 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 2 May 2001 19:09:00 -0700 To: "Lisa Dusseault" From: "Dan Brotsky" Cc: "DeltaV" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4891 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 2:24 PM -0700 5/2/01, Lisa Dusseault wrote: >WebDAV people: RFC2518 leaves it carefully open whether 'getlastmodified' >changes when properties of the resource change. It seems useful either >way -- users might want to get the last time the content was changed, or >they might want to see the last time the file was touched at all. Is there >some precedent? ... > >Which one of the last two is most commonly handled by getlastmodified? >Implementors speak up? At Adobe our various servers take different positions on this. We have found that clients which have transitioned from doing FTP to doing DAV and HTTP 1.0 clients tend to use getlastmodified where they really should be using etags, so servers that cater to those clients ("general purpose servers" :^) are careful not to tamper with getlastmodified unless the content changes. But our high-end workflow servers expect savvy clients and users who really care about property (read workflow) changes, so they update whether or not content changes. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Thu May 3 13:14:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00621 for ; Thu, 3 May 2001 13:14:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA04444; Thu, 3 May 2001 13:03:16 -0400 (EDT) Resent-Date: Thu, 3 May 2001 13:03:16 -0400 (EDT) Resent-Message-Id: <200105031703.NAA04444@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA04400 for ; Thu, 3 May 2001 13:03:10 -0400 (EDT) Received: from conductor.synapse.net (conductor.synapse.net [199.84.54.18]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA11642 for ; Thu, 3 May 2001 13:03:10 -0400 Received: (qmail 14447 invoked from network); 3 May 2001 17:02:53 -0000 Received: from ppp-44-155.ott.aei.net (HELO sri01) (216.221.44.155) by conductor.synapse.net with SMTP; 3 May 2001 17:02:53 -0000 From: "Sridhar Erukulla" To: , , Date: Thu, 3 May 2001 13:03:30 -0400 Message-ID: <000401c0d3f2$faf042d0$37c9c8c8@ByteQuest.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <80256A41.003B6FE8.00@d06mta07.portsmouth.uk.ibm.com> Disposition-Notification-To: "Sridhar Erukulla" Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4892 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit In our document management system we have two concepts, 'Object' and 'Document'. An 'Object' comprises of a 'Document' and all its properties. The function GetLastModified for a document retrieves when the actual document was modified where as for an object when the object was modified which includes the properties and document. We found that this distinction was critical in distinguishing the physical actions like library maintenance, caching etc. vs. the business operations like using workflow. -S From w3c-dist-auth-request@w3.org Thu May 3 13:32:46 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01154 for ; Thu, 3 May 2001 13:32:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06099; Thu, 3 May 2001 13:21:12 -0400 (EDT) Resent-Date: Thu, 3 May 2001 13:21:12 -0400 (EDT) Resent-Message-Id: <200105031721.NAA06099@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA06079 for ; Thu, 3 May 2001 13:21:07 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA13253 for ; Thu, 3 May 2001 13:21:05 -0400 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id KAA10762 for ; Thu, 3 May 2001 10:23:56 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id KAA18680; Thu, 3 May 2001 10:19:33 -0700 (PDT) Received: from [192.168.1.6] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GCRS6200.SNP for ; Thu, 3 May 2001 10:20:26 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: <3906C56A7BD1F54593344C05BD1374B102DB8BBC@SUS-MA1IT01> References: <3906C56A7BD1F54593344C05BD1374B102DB8BBC@SUS-MA1IT01> Date: Thu, 3 May 2001 10:16:53 -0700 To: w3c-dist-auth@w3.org From: "Dan Brotsky" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4893 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I think we might be able to close on this issue if we consider it pragmatically: 1. We are having a great deal of difficulty deciding on a single semantics for ALLPROP that fits well with the various related specs (e.g., delta-V). 2. We already seem to have general agreement on a change in the default semantics for ALLPROP (i.e., no depth infinity and the default if not specified changes to 0) that's incompatible with the current draft (and thus current versions of clients). From these two I conclude that there's no way that ALLPROP in the next draft is going to have the same semantics as ALLPROP in the last draft. Thus existing clients who use ALLPROP are going to have to be rewritten to be compatible with servers going forward. So we're faced with two alternatives---preserve ALLPROP and change clients, or give up on ALLPROP and change clients---which IMHO differ very little for client implementors but which are quite different for server implementors (the first being harder than the second). As a server implementor, I vote for option 2: abandon allprop. As a client implementor (which I also am), I can live equally with either (as long as it means that servers are CONSISTENT, which is easier with option 2). Are there any client implementors out there who strongly believe that changing to a new semantics for ALLPROP is harder for them than just doing PROPNAME then PROPFIND? dan P.S. Yes I realize that server implementors who implement cross-server COPY and MOVE are also client implementors, and should feel free to respond from that perspective! -d. -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Thu May 3 13:54:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01813 for ; Thu, 3 May 2001 13:54:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07511; Thu, 3 May 2001 13:39:41 -0400 (EDT) Resent-Date: Thu, 3 May 2001 13:39:41 -0400 (EDT) Resent-Message-Id: <200105031739.NAA07511@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA07450 for ; Thu, 3 May 2001 13:39:31 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA14804; Thu, 3 May 2001 13:39:29 -0400 Received: from [216.36.75.57] (HELO beaver) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 21289598; Thu, 03 May 2001 10:38:20 -0700 From: "Lisa Dusseault" To: "Sridhar Erukulla" , , Date: Thu, 3 May 2001 10:38:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000401c0d3f2$faf042d0$37c9c8c8@ByteQuest.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4894 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit If this system has been exposed via WebDAV, I'd be quite interested to hear how you did it. What does the resource URL point to? Did you find WebDAV lacking? How did you work around it or extend it? lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Sridhar Erukulla > Sent: Thursday, May 03, 2001 10:04 AM > To: Tim_Ellison@uk.ibm.com; ietf-dav-versioning@w3.org; > w3c-dist-auth@w3.org > Subject: RE: File creation date, version creation date, and > getlastmodified > > > In our document management system we have two concepts, 'Object' > and 'Document'. An 'Object' comprises of a 'Document' and all its > properties. The function GetLastModified for a document retrieves > when the actual document was modified where as for an object when > the object was modified which includes the properties and > document. > > We found that this distinction was critical in distinguishing the > physical actions like library maintenance, caching etc. vs. the > business operations like using workflow. > > -S From w3c-dist-auth-request@w3.org Thu May 3 14:33:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02817 for ; Thu, 3 May 2001 14:33:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA09157; Thu, 3 May 2001 14:20:08 -0400 (EDT) Resent-Date: Thu, 3 May 2001 14:20:08 -0400 (EDT) Resent-Message-Id: <200105031820.OAA09157@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA09103 for ; Thu, 3 May 2001 14:20:02 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA17803; Thu, 3 May 2001 14:20:02 -0400 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id LAA19334; Thu, 3 May 2001 11:22:50 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id LAA04474; Thu, 3 May 2001 11:19:09 -0700 (PDT) Received: from [192.168.1.6] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GCRUW700.FTB; Thu, 3 May 2001 11:19:19 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: <000401c0d3f2$faf042d0$37c9c8c8@ByteQuest.ca> References: <000401c0d3f2$faf042d0$37c9c8c8@ByteQuest.ca> Date: Thu, 3 May 2001 11:16:38 -0700 To: "Sridhar Erukulla" From: "Dan Brotsky" Cc: , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4896 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 1:03 PM -0400 5/3/01, Sridhar Erukulla wrote: >In our document management system we have two concepts, 'Object' >and 'Document'. An 'Object' comprises of a 'Document' and all its >properties. The function GetLastModified for a document retrieves >when the actual document was modified where as for an object when >the object was modified which includes the properties and >document. > >We found that this distinction was critical in distinguishing the >physical actions like library maintenance, caching etc. vs. the >business operations like using workflow. Adobe's InScope server does a similar thing distinguishing "Assets" from "Versions" (which are the content and dead property snapshots of the asset); assets as a resource have content and properties (the latest version) but also properties that the version doesn't have. Many of these "non-content" properties are about the workflow. Our approach (prior to delta-V) has been to establish a conventional relationship between the asset URLs and the version URLs; in fact assets are (non-DAV-compliant) collections of their versions. With delta-V stabilizing we are hoping, going forward, to use delta-V mechanisms to connect assets and their versions. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Thu May 3 14:52:43 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03219 for ; Thu, 3 May 2001 14:52:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA09979; Thu, 3 May 2001 14:33:21 -0400 (EDT) Resent-Date: Thu, 3 May 2001 14:33:21 -0400 (EDT) Resent-Message-Id: <200105031833.OAA09979@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA09959 for ; Thu, 3 May 2001 14:33:16 -0400 (EDT) Received: from conductor.synapse.net (conductor.synapse.net [199.84.54.18]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA18945 for ; Thu, 3 May 2001 14:33:13 -0400 Received: (qmail 20159 invoked from network); 3 May 2001 18:33:10 -0000 Received: from ppp-44-155.ott.aei.net (HELO sri01) (216.221.44.155) by conductor.synapse.net with SMTP; 3 May 2001 18:33:10 -0000 From: "Sridhar Erukulla" To: "'Lisa Dusseault'" , "'Sridhar Erukulla'" , , Date: Thu, 3 May 2001 14:33:28 -0400 Keywords: Official Message-ID: <000201c0d3ff$8c4ea760$37c9c8c8@ByteQuest.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Disposition-Notification-To: "Sridhar Erukulla" Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4897 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit No, Not yet! But in future we want to expose the Document objects first, eventually the Holder objects. Sridhar -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: May 3, 2001 1:38 PM To: Sridhar Erukulla; ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org Subject: RE: File creation date, version creation date, and getlastmodified If this system has been exposed via WebDAV, I'd be quite interested to hear how you did it. What does the resource URL point to? Did you find WebDAV lacking? How did you work around it or extend it? lisa From w3c-dist-auth-request@w3.org Thu May 3 15:57:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06641 for ; Thu, 3 May 2001 15:57:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13206; Thu, 3 May 2001 15:45:56 -0400 (EDT) Resent-Date: Thu, 3 May 2001 15:45:56 -0400 (EDT) Resent-Message-Id: <200105031945.PAA13206@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA13178 for ; Thu, 3 May 2001 15:45:42 -0400 (EDT) Received: from ELSMX61.mattel.net ([63.100.125.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA24440 for ; Thu, 3 May 2001 15:45:41 -0400 Received: from estwr61.eshq.mattel.com (mailhub3.mattel.net [156.20.106.250]) by ELSMX61.mattel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQYJJD8Y; Thu, 3 May 2001 12:45:22 -0700 Received: from 156.20.200.14 by estwr61.eshq.mattel.com (InterScan E-Mail VirusWall NT); Thu, 03 May 2001 12:46:08 -0700 (Pacific Daylight Time) Received: by estwr61.eshq.mattel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 12:46:08 -0700 Message-ID: <2ABD012C3FB72A44A0429F4CDAFE7676035ED603@estwr50a.eshq.mattel.com> From: "Harris, Matt" To: w3c-dist-auth@w3.org Date: Thu, 3 May 2001 12:43:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: File creation date, version creation date, and getlastmodifie d Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4899 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D409.444DFDD0" ------_=_NextPart_001_01C0D409.444DFDD0 Content-Type: text/plain; charset="iso-8859-1" Now that is the best suggestion I have seen yet for this issue. Matt > -----Original Message----- > From: Adam Freeman [mailto:afreeman@lightsurf.com] > Sent: Thursday, May 03, 2001 12:04 PM > To: Douglas R. Steen; w3c-dist-auth@w3.org > > Hello, > why not have two different last modified dates, one for the > content and one > for the metadata? > - Adam ------_=_NextPart_001_01C0D409.444DFDD0 Content-Type: text/html; charset="iso-8859-1" RE: File creation date, version creation date, and getlastmodified

Now that is the best suggestion I have seen yet for this issue.

Matt

> -----Original Message-----
> From: Adam Freeman [mailto:afreeman@lightsurf.com]
> Sent: Thursday, May 03, 2001 12:04 PM
> To: Douglas R. Steen; w3c-dist-auth@w3.org
>
> Hello,
> why not have two different last modified dates, one for the
> content and one
> for the metadata?
> - Adam

------_=_NextPart_001_01C0D409.444DFDD0-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Thu May 3 18:22:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11870 for ; Thu, 3 May 2001 18:22:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07604; Thu, 3 May 2001 13:41:12 -0400 (EDT) Resent-Date: Thu, 3 May 2001 13:41:12 -0400 (EDT) Resent-Message-Id: <200105031741.NAA07604@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA07562 for ; Thu, 3 May 2001 13:41:08 -0400 (EDT) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA14897; Thu, 3 May 2001 13:40:55 -0400 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id KAA25110; Thu, 3 May 2001 10:45:14 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id KAA21848; Thu, 3 May 2001 10:39:22 -0700 (PDT) Received: from [192.168.1.6] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GCRT3200.EPW; Thu, 3 May 2001 10:40:14 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: <20CF1CE11441D411919C0008C7C5A13B01D03BA4@stalmail.eu.merant.com> References: <20CF1CE11441D411919C0008C7C5A13B01D03BA4@stalmail.eu.merant.com> Date: Thu, 3 May 2001 10:30:51 -0700 To: Peter Raymond From: "Dan Brotsky" Cc: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: File creation date, version creation date, and getlastmodifie d Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4895 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: >I am in favor of Lisa's suggestion of having three timestamps. I'm not sure Lisa was actually making that suggestion :^), but in any event I don't like the idea of requiring this kind of timestamping at all. It adds detail to the abstract "DAV resource" that unnecessarily biases it towards file-system implementations (where content and properties are likely to be stored separately and modified independently). I believe that the modification date property is in DAV because it's there in HTTP 1.1. And its semantics are left vague exactly to allow many different implementations. The move to etags in 1.1 was specifically intended to more generally answer the question "has the content of this resource changed." We shouldn't now go back and try to resurrect modification dates as the way to find out about content changes. Similarly, I don't think we should tie modification dates one way or the other to property changes. if clients need a way of asking "has this resource changed in any way - content or properties" then we should add a "property etag" in addition to the "content etag" that now exists. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Thu May 3 18:22:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11894 for ; Thu, 3 May 2001 18:22:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA11699; Thu, 3 May 2001 15:04:16 -0400 (EDT) Resent-Date: Thu, 3 May 2001 15:04:16 -0400 (EDT) Resent-Message-Id: <200105031904.PAA11699@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA11675 for ; Thu, 3 May 2001 15:04:05 -0400 (EDT) Received: from lsmail.office.lightsurf.com (lsmail.office.lightsurf.com [204.30.31.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA21220 for ; Thu, 3 May 2001 15:04:05 -0400 Received: from urchin (urchin.office.lightsurf.com [10.10.10.133]) by lsmail.office.lightsurf.com (Mirapoint) with SMTP id AAK30332; Thu, 3 May 2001 12:03:41 -0700 (PDT) Reply-To: From: "Adam Freeman" To: "Douglas R. Steen" , Date: Thu, 3 May 2001 12:03:42 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <000601c0d369$c38935b0$78d7fea9@drsteen.com> Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4898 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, why not have two different last modified dates, one for the content and one for the metadata? - Adam -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Douglas R. Steen Sent: Wednesday, May 02, 2001 5:41 PM To: w3c-dist-auth@w3.org Subject: RE: File creation date, version creation date, and getlastmodified re: WebDAV. My vote would be changing getlastmodified when the properties change. As we use properties more and more, they become a true part of the file in the user experience. Trying to distinguish between the two ("I know you changed the billing number yesterday, but you didn't change the _content_ so the date still reads last week...") can be difficult. Unfortunately, it's a very easy shorthand for server implementations to use the file last-modified date for getlastmodified, and for the operating systems I know that reflects the date/time of the last content modification. Douglas R. Steen dsteen@ekeeper.com Drag-and-Drop Web File Management http://www.eKeeper.com -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: Wednesday, May 02, 2001 4:25 PM To: DeltaV; w3c-dist-auth@w3.org Subject: File creation date, version creation date, and getlastmodified WebDAV people: RFC2518 leaves it carefully open whether 'getlastmodified' changes when properties of the resource change. It seems useful either way -- users might want to get the last time the content was changed, or they might want to see the last time the file was touched at all. Is there some precedent? Really, one might best be served by a new timestamp property, so the suite of timestamp-like properties would be - creationdate - time the content was last modified (etag changes, but etag doesn't provide a timestamp) - time the file was last touched Which one of the last two is most commonly handled by getlastmodified? Implementors speak up? DeltaV people: What does it mean to get the time file content was last "modified", if the file is versioned? I don't see that the behaviour of getlastmodified is specified for a Version-Controlled Resource, can this be a recommendation in the spec to promote consistency? For one thing, should 'getlastmodified' on the VCR change when it is checked out, or when it is checked in, or both? lisa From w3c-dist-auth-request@w3.org Thu May 3 20:25:02 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16028 for ; Thu, 3 May 2001 20:25:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA19316; Thu, 3 May 2001 09:30:23 -0400 (EDT) Resent-Date: Thu, 3 May 2001 09:30:23 -0400 (EDT) Resent-Message-Id: <200105031330.JAA19316@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA19296 for ; Thu, 3 May 2001 09:30:19 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA25529 for ; Thu, 3 May 2001 09:29:29 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id OAA30616; Thu, 3 May 2001 14:11:16 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id OAA270502; Thu, 3 May 2001 14:28:02 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A41.0049F881 ; Thu, 3 May 2001 14:27:57 +0100 X-Lotus-FromDomain: IBMGB To: "jack vamvas-angryfish.uk.com" cc: w3c-dist-auth@w3.org Message-ID: <80256A41.0049F3DD.00@d06mta07.portsmouth.uk.ibm.com> Date: Thu, 3 May 2001 14:27:42 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: File creation date, version creation date, and getlastmodifie d Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4890 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: 'cmon, it wasn't that bad try sending your request to ietf-dav-versioning-request@w3.org and/or w3c-dist-auth-request@w3.org Tim "jack vamvas-angryfish.uk.com" wrote: unsubscribe -----Original Message----- From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] Sent: Thursday, May 03, 2001 11:49 AM To: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org Subject: RE: File creation date, version creation date, and getlastmodified <> From w3c-dist-auth-request@w3.org Thu May 3 22:42:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19411 for ; Thu, 3 May 2001 22:42:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA20989; Thu, 3 May 2001 20:49:02 -0400 (EDT) Resent-Date: Thu, 3 May 2001 20:49:02 -0400 (EDT) Resent-Message-Id: <200105040049.UAA20989@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA20969 for ; Thu, 3 May 2001 20:48:58 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA13322 for ; Thu, 3 May 2001 20:48:54 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA231340 for ; Thu, 3 May 2001 20:42:30 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f440mOA130874 for ; Thu, 3 May 2001 20:48:24 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Thu, 3 May 2001 20:43:46 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/03/2001 08:48:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: IE5 & DAV Interoperability Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4900 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I don't have any problems with web folders, Office 2000, IE5, or DreamWeaver, but FrontPage, Visual InterDev, and VS.NET don't do WebDAV. David Logan says: Good Morning Folks, I have been attempting to get IE5 to talk to our apache 1.3.14 server using the mod_dav module. Having played around extensively I cannot, for the life of me, get IE5 talking to the server. It appears that I need to install Frontpage extensions. In reading the archives of this list, I can't see anywhere that this gets a mention as being a requirement. My understanding of IE5 Web Folders was that it was fairly compliant and did not require extensions. Am I barking up the wrong tree? If this is not the right list for these comments, can somebody please point me in the right direction? 8-) Thanks & Regards -- _______________________________________________________________ David Logan 102 Cameron Street Broadband e-Lab Launceston Tas 7250 Australia Ph : (03) 6323 2667 Fax: (03) 6323 2666 From w3c-dist-auth-request@w3.org Fri May 4 02:07:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05606 for ; Fri, 4 May 2001 02:07:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA05064; Fri, 4 May 2001 01:56:25 -0400 (EDT) Resent-Date: Fri, 4 May 2001 01:56:25 -0400 (EDT) Resent-Message-Id: <200105040556.BAA05064@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA05041 for ; Fri, 4 May 2001 01:56:12 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA04440 for ; Fri, 4 May 2001 01:56:07 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id WAA24985 for w3c-dist-auth@w3.org; Thu, 3 May 2001 22:59:19 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 3 May 2001 22:59:19 -0700 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20010503225919.Q1374@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B102DB8BBC@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B102DB8BBC@SUS-MA1IT01>; from gclemm@rational.com on Wed, May 02, 2001 at 11:53:27PM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4902 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wed, May 02, 2001 at 11:53:27PM -0400, Clemm, Geoff wrote: > I am adamantly opposed to DAV:allprop. In the context of > computed live properties, a client should never blindly ask > for all property values ... it should always first ask for > DAV:propname, and then use the subset that it can use. Euh, how does the propname help the computed live prop case? If I fetch all the names, then fetch the values, then I've still slammed the server with a bunch of computed props. Removing allprop does not help this scenario at all. > The WebDAV versioning extensions explicitly allows a server to > *not* return the versioning properties in response to a > DAV:allprop request, so DAV:propname will be the only reliable > way of obtaining all the properties. When did that go in? That seems to be a direct violation of RFC 2518. > Finally, the fact that > PROPFIND/DAV:allprop is trivially replaceable with two PROPFIND > calls (the first being PROPFIND/DAV:propname) makes DAV:allprop > superfluous (in addition to being inadvisable). It is *NOT* trivial. If you want to do a Depth:1, then the client is going to have to create a union of all the resources' prop names, then do the fetch for those props. Next, it will need to deal with the 404 that it will get for the props that weren't available on all resources. Trivial? Bah. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri May 4 02:33:52 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05814 for ; Fri, 4 May 2001 02:33:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA06269; Fri, 4 May 2001 02:22:42 -0400 (EDT) Resent-Date: Fri, 4 May 2001 02:22:42 -0400 (EDT) Resent-Message-Id: <200105040622.CAA06269@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA06249 for ; Fri, 4 May 2001 02:22:37 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA06362 for ; Fri, 4 May 2001 02:22:38 -0400 Received: (qmail 3093 invoked by uid 0); 4 May 2001 06:21:56 -0000 Received: from p3ee24798.dip.t-dialin.net (HELO lisa) (62.226.71.152) by mail.gmx.net (mp020-rz3) with SMTP; 4 May 2001 06:21:56 -0000 From: "Julian Reschke" To: "Greg Stein" , Date: Fri, 4 May 2001 08:21:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010503225919.Q1374@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: AW: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4903 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit How about a) looking again into the proposed PROPFIND extensions to get properties by namespace (and to suppress specific namespaces), and b) put for example the deltaV properties into a different namespace? Julian > -----Ursprungliche Nachricht----- > Von: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Greg Stein > Gesendet: Freitag, 4. Mai 2001 07:59 > An: w3c-dist-auth@w3.org > Betreff: Re: Issue: ALLPROP_AND_COMPUTED > > > On Wed, May 02, 2001 at 11:53:27PM -0400, Clemm, Geoff wrote: > > I am adamantly opposed to DAV:allprop. In the context of > > computed live properties, a client should never blindly ask > > for all property values ... it should always first ask for > > DAV:propname, and then use the subset that it can use. > > Euh, how does the propname help the computed live prop case? If I > fetch all > the names, then fetch the values, then I've still slammed the > server with a > bunch of computed props. > > Removing allprop does not help this scenario at all. > > > The WebDAV versioning extensions explicitly allows a server to > > *not* return the versioning properties in response to a > > DAV:allprop request, so DAV:propname will be the only reliable > > way of obtaining all the properties. > > When did that go in? That seems to be a direct violation of RFC 2518. > > > Finally, the fact that > > PROPFIND/DAV:allprop is trivially replaceable with two PROPFIND > > calls (the first being PROPFIND/DAV:propname) makes DAV:allprop > > superfluous (in addition to being inadvisable). > > It is *NOT* trivial. If you want to do a Depth:1, then the client is going > to have to create a union of all the resources' prop names, then do the > fetch for those props. Next, it will need to deal with the 404 > that it will > get for the props that weren't available on all resources. > > Trivial? Bah. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Fri May 4 03:04:48 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06053 for ; Fri, 4 May 2001 03:04:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA22129; Thu, 3 May 2001 21:17:45 -0400 (EDT) Resent-Date: Thu, 3 May 2001 21:17:45 -0400 (EDT) Resent-Message-Id: <200105040117.VAA22129@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA22087 for ; Thu, 3 May 2001 21:17:39 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id VAA15414; Thu, 3 May 2001 21:17:39 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 03 May 2001 21:19:46 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 21:19:46 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102DB8EA0@SUS-MA1IT01> From: "Clemm, Geoff" To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Date: Thu, 3 May 2001 21:19:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: File creation date, version creation date, and getlastmodifie d Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4901 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Tim's position. The DAV:getlastmodified property is explicitly defined to coincide with the value of the Last-Modified header, which is used to control caching of resource content (i.e. what GET returns). Requiring that this date change whenever a property changes would severely harm existing HTTP clients which depend on Last-Modified for content caching. This would be especially disastrous for a server that maintains a "last-accessed" property on resources, since if we stated that a property change causes a Last-Modified change, the DAV:getlastmodified would change every time a resource is accessed. On the other hand, many implementations depend on the underlying "modification date" being maintained by the underlying repository (to allow multi-protocol access to that repository), and for those implementations that store some properties in the repository item that affects the modification date, the modification date on those servers will be affected by a change to those properties. So I believe the current RFC-2518 language is correct and appropriate. Cheers, Geoff -----Original Message----- From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] Sent: Thursday, May 03, 2001 6:49 AM To: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org Subject: RE: File creation date, version creation date, and getlastmodified Lisa Dusseault wrote: > WebDAV people: RFC2518 leaves it carefully open whether > 'getlastmodified' changes when properties of the resource > change. It seems useful either way -- users might want to > get the last time the content was changed, or they might > want to see the last time the file was touched at all. Is > there some precedent? I seem to recall that moddav does not change the last modified timestamp when properties are updated. There has been discussion on this topic previously, with a weak consensus that the properties should not contribute to last modified changes. I think this is the right answer. Peter Raymond wrote: > One example of why we keep the "last modified" date separate > is that our build system uses this to compare with timestamps > of files on disk to decide if the file is out of date. If the > WebDAV client set the last modification time each time a > property was changed then the build system would think the file > on disk was "out of date" compared to the file held in version > control. I think that this is a common scenario, also found on caching proxies, that relies upon property updates not being considered a change to the resource. Clearly there is some ambiguity here. On the one hand, properties appear to be 'part of' a resource. They appear when a resource is created, and disappear when a resource is deleted. Operations on a property are via the URL of the resource. However, live properties exhibit behaviour that sets them apart from the resource. They can change even when a resource is versioned or locked, and (at least in a couple of implementations) changes to the resource's properties do not change the last modified timestamp of the resource. Lisa Dusseault wrote: > DeltaV people: What does it mean to get the time file content > was last "modified", if the file is versioned? I don't see > that the behaviour of getlastmodified is specified for a > Version-Controlled Resource, can this be a recommendation in > the spec to promote consistency? For one thing, should > 'getlastmodified' on the VCR change when it is checked out, > or when it is checked in, or both? When a version-controlled resource is checked-out its contents and dead properties are updated to be the same as the version identified in the DAV:checked-in property. Therefore the DAV:getlastmodified timestamp clearly should be updated to reflect the changes. Note that the timestamp value is the server's notion of the time the version-controlled resource was modified and not the same as the checked-in version's DAV:getlastmodified. When a version-controlled resource is checked-in, its content and dead properties become those of a new version in the version history. Some live properties of the version-controlled resource are updated to reflect its checked-in status. In this case I argue that the DAV:getlastmodified timestamp does not change. Furthermore, if you use UPDATE to update the content and dead properties of a version-controlled resource to reflect the state of a version in version history, the DAV:getlastmodified timestamp will be the time that the UPDATE method was applied and not that of the version. It it were otherwise updating the version-controlled resource to an earlier version would make the last modified time go 'backwards' which would potentially screw up caching proxies and clients that rely on If-Unmodified-Since: headers etc. > - time the file was last touched What is your definition of touched? Dead property updates? Given the number of live / computed properties I assume you agree that their values do not contribute to the touched timestamp? Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 From w3c-dist-auth-request@w3.org Fri May 4 04:30:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06980 for ; Fri, 4 May 2001 04:30:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA10988; Fri, 4 May 2001 04:17:51 -0400 (EDT) Resent-Date: Fri, 4 May 2001 04:17:51 -0400 (EDT) Resent-Message-Id: <200105040817.EAA10988@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA10965 for ; Fri, 4 May 2001 04:17:41 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA15802 for ; Fri, 4 May 2001 04:17:39 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id IAA206270 for ; Fri, 4 May 2001 08:59:52 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id JAA205246 for ; Fri, 4 May 2001 09:17:00 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A42.002D7FBC ; Fri, 4 May 2001 09:16:58 +0100 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <80256A42.002D7F5E.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 4 May 2001 09:16:54 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4905 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: Greg Stein wrote: > On Wed, May 02, 2001 at 11:53:27PM -0400, Clemm, Geoff wrote: > > I am adamantly opposed to DAV:allprop. In the context of > > computed live properties, a client should never blindly ask > > for all property values ... it should always first ask for > > DAV:propname, and then use the subset that it can use. > > Euh, how does the propname help the computed live prop case? > If I fetch all the names, then fetch the values, then I've > still slammed the server with a bunch of computed props. I think the key part of Geoff's post is "the subset that it can use". The problem with allprop is that it will return all the live properties irrespective of whether the client is aware of the properties' semantics. Sometimes this is what the client wants, say if it is naively displaying a property sheet; but most likely it is not since there is no way for the client to interpret the values or know if/how they can be changed. > Removing allprop does not help this scenario at all. It's the old NRA argument -- allprop doesn't kill servers, clients kill servers ;-) > > The WebDAV versioning extensions explicitly allows a server to > > *not* return the versioning properties in response to a > > DAV:allprop request, so DAV:propname will be the only reliable > > way of obtaining all the properties. > > When did that go in? That seems to be a direct violation of RFC 2518. I have to agree that it is a stealth action to undermine (the effects of) allprop. > > Finally, the fact that > > PROPFIND/DAV:allprop is trivially replaceable with two PROPFIND > > calls (the first being PROPFIND/DAV:propname) makes DAV:allprop > > superfluous (in addition to being inadvisable). > > It is *NOT* trivial. If you want to do a Depth:1, then the client > is going to have to create a union of all the resources' prop names, > then do the fetch for those props. Next, it will need to deal with > the 404 that it will get for the props that weren't available on all > resources. > > Trivial? Bah. I'd say that was pretty trivial. Tim From w3c-dist-auth-request@w3.org Fri May 4 05:46:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07523 for ; Fri, 4 May 2001 05:46:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA13585; Fri, 4 May 2001 05:35:50 -0400 (EDT) Resent-Date: Fri, 4 May 2001 05:35:50 -0400 (EDT) Resent-Message-Id: <200105040935.FAA13585@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA13561 for ; Fri, 4 May 2001 05:35:42 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA22281 for ; Fri, 4 May 2001 05:35:41 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id KAA38450; Fri, 4 May 2001 10:17:22 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id KAA195756; Fri, 4 May 2001 10:34:17 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A42.00349070 ; Fri, 4 May 2001 10:34:08 +0100 X-Lotus-FromDomain: IBMGB To: "Julian Reschke" , w3c-dist-auth@w3.org Message-ID: <80256A42.00348F20.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 4 May 2001 10:33:56 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: AW: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4907 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Julian Reschke" wrote: > > Von: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von > > Tim_Ellison@uk.ibm.com > > Gesendet: Freitag, 4. Mai 2001 10:17 > > An: w3c-dist-auth@w3.org > > Betreff: Re: Issue: ALLPROP_AND_COMPUTED > > > > I think the key part of Geoff's post is "the subset that it can use". The > > problem with allprop is that it will return all the live properties > > irrespective of whether the client is aware of the properties' semantics. > > Sometimes this is what the client wants, say if it is naively displaying a > > property sheet; but most likely it is not since there is no way for the > > client to interpret the values or know if/how they can be changed. > > If agree with "to know if they can be changed". But, if they CAN be changed, > the way to do that is pretty obvious, isn't it???? Causing the update of a live property is usually not obvious. For example, changing the DAV:getlastmodified value is achieved by PUT-ing new content, changing the DAV:successor-set of a version is achieved by creating a version whose DAV:predecessor-set identifies that version, and so on. My point is that if, say, a versioning unaware client uses PROPFIND with DAV:allprop and retrieves the name and value of the DAV:successor-set property, the best the client can likely do is to render the XML value some way that is not going to be very meaningful; and the client certainly isn't going to know how to change that value. Tim From w3c-dist-auth-request@w3.org Fri May 4 06:21:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07873 for ; Fri, 4 May 2001 06:21:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA11469; Fri, 4 May 2001 04:34:52 -0400 (EDT) Resent-Date: Fri, 4 May 2001 04:34:52 -0400 (EDT) Resent-Message-Id: <200105040834.EAA11469@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA11448 for ; Fri, 4 May 2001 04:34:47 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA17322 for ; Fri, 4 May 2001 04:34:46 -0400 Received: (qmail 4552 invoked by uid 0); 4 May 2001 08:34:09 -0000 Received: from p3ee24798.dip.t-dialin.net (HELO lisa) (62.226.71.152) by mail.gmx.net (mail01) with SMTP; 4 May 2001 08:34:09 -0000 From: "Julian Reschke" To: , Date: Fri, 4 May 2001 10:34:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <80256A42.002D7F5E.00@d06mta07.portsmouth.uk.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: AW: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4906 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Von: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von > Tim_Ellison@uk.ibm.com > Gesendet: Freitag, 4. Mai 2001 10:17 > An: w3c-dist-auth@w3.org > Betreff: Re: Issue: ALLPROP_AND_COMPUTED > > I think the key part of Geoff's post is "the subset that it can use". The > problem with allprop is that it will return all the live properties > irrespective of whether the client is aware of the properties' semantics. > Sometimes this is what the client wants, say if it is naively displaying a > property sheet; but most likely it is not since there is no way for the > client to interpret the values or know if/how they can be changed. If agree with "to know if they can be changed". But, if they CAN be changed, the way to do that is pretty obvious, isn't it???? From w3c-dist-auth-request@w3.org Fri May 4 06:32:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08021 for ; Fri, 4 May 2001 06:32:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA10636; Fri, 4 May 2001 04:05:39 -0400 (EDT) Resent-Date: Fri, 4 May 2001 04:05:39 -0400 (EDT) Resent-Message-Id: <200105040805.EAA10636@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA10591 for ; Fri, 4 May 2001 04:05:32 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA14562; Fri, 4 May 2001 04:05:29 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id IAA32988; Fri, 4 May 2001 08:47:42 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id JAA106770; Fri, 4 May 2001 09:04:51 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A42.002C61E3 ; Fri, 4 May 2001 09:04:46 +0100 X-Lotus-FromDomain: IBMGB To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Message-ID: <80256A42.002C6081.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 4 May 2001 09:04:41 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: What was I thinkin' ? (was: RE: File creation date, version creation date, and getlastmodified) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4904 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On May 3, 2001 I wrote: > When a version-controlled resource is checked-out its > contents and dead properties are updated to be the same > as the version identified in the DAV:checked-in property. When a version-controlled resource is checked-out it's contents and dead properties will _already_ be the same as those of the version identified by the DAV:checked-in property, so no update is required. > Therefore the DAV:getlastmodified timestamp clearly should > be updated to reflect the changes. Note that the timestamp > value is the server's notion of the time the version-controlled > resource was modified and not the same as the checked-in > version's DAV:getlastmodified. ...so saying the "timestamp clearly should be updated" was totally bogus. The act of checking-out a version-controlled resource only updates the live properties of the resource, and 'clearly' this should *not* update the DAV:getlastmodified timestamp Sorry for causing confusion. Tim From w3c-dist-auth-request@w3.org Fri May 4 10:02:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12660 for ; Fri, 4 May 2001 10:02:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA21405; Fri, 4 May 2001 09:16:01 -0400 (EDT) Resent-Date: Fri, 4 May 2001 09:16:01 -0400 (EDT) Resent-Message-Id: <200105041316.JAA21405@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA21382 for ; Fri, 4 May 2001 09:15:54 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA05565 for ; Fri, 4 May 2001 09:15:54 -0400 Received: (qmail 30324 invoked by uid 0); 4 May 2001 13:15:22 -0000 Received: from pd950c2a0.dip.t-dialin.net (HELO lisa) (217.80.194.160) by mail.gmx.net (mp005-rz3) with SMTP; 4 May 2001 13:15:22 -0000 From: "Julian Reschke" To: , Date: Fri, 4 May 2001 15:15:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <80256A42.00348F20.00@d06mta07.portsmouth.uk.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: AW: AW: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4908 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Von: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von > Tim_Ellison@uk.ibm.com > Gesendet: Freitag, 4. Mai 2001 11:34 > An: Julian Reschke; w3c-dist-auth@w3.org > Betreff: Re: AW: Issue: ALLPROP_AND_COMPUTED > > My point is that if, say, a versioning unaware client uses PROPFIND with > DAV:allprop and retrieves the name and value of the DAV:successor-set > property, the best the client can likely do is to render the XML > value some > way that is not going to be very meaningful; and the client > certainly isn't > going to know how to change that value. Agreed. When I wrote my mail, I was thinking of dead properties. From w3c-dist-auth-request@w3.org Fri May 4 15:04:26 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19298 for ; Fri, 4 May 2001 15:04:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA06668; Fri, 4 May 2001 14:48:54 -0400 (EDT) Resent-Date: Fri, 4 May 2001 14:48:54 -0400 (EDT) Resent-Message-Id: <200105041848.OAA06668@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA06648 for ; Fri, 4 May 2001 14:48:49 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA32357 for ; Fri, 4 May 2001 14:48:49 -0400 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id LAA22013 for ; Fri, 4 May 2001 11:50:56 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id LAA26358; Fri, 4 May 2001 11:46:29 -0700 (PDT) Received: from [192.168.1.6] ([130.248.188.66]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GCTQUX00.B60 for ; Fri, 4 May 2001 11:47:21 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Fri, 4 May 2001 11:33:59 -0700 To: w3c-dist-auth@w3.org From: "Dan Brotsky" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4910 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 12:45 PM -0400 5/4/01, Jason Crawford wrote: >As it stands now, I have a mild preference for leaving allprop in. I'm >*very* willing to support another position if it will bring us to agreement >and not do any serious damage. That was the point I was trying to make (apparently not very well :^) in my earlier message. The problem with leaving ALLPROP in is that we're clearly going to be changing its semantics (e.g., forbidding depth infinity) so existing clients are likely to stop working and will need updates. Plus leaving it in but changing its semantics may mean that existing clients will seem to work but in fact give erroneous results. Plus it means we actually have to *agree* about its semantics, which is apparently not going to be easy. Deprecating it is a much cleaner way to change its semantics: servers who wish to can still honor it (keeping old clients working) and servers that don't can just refuse it (breaking old clients cleanly). Clients who update can go to using PROPNAME/PROPFIND pairs and so work against all servers. I think the only problem with this plan is that folks are worried about the extra work clients will have to do to do PROPNAME/PROPFIND pairs (with unioning) rather than a simple ALLPROP. So I ask again (as a client implementor who doesn't mind doing this): are there any client-side folks out there who believe the extra work is too onerous? And, if so, do you have clear requirements for what an updated ALLPROP needs to do in order to work for you? dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Fri May 4 16:57:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20498 for ; Fri, 4 May 2001 16:57:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA11990; Fri, 4 May 2001 16:45:14 -0400 (EDT) Resent-Date: Fri, 4 May 2001 16:45:14 -0400 (EDT) Resent-Message-Id: <200105042045.QAA11990@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA11872 for ; Fri, 4 May 2001 16:45:07 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA08362 for ; Fri, 4 May 2001 16:45:01 -0400 Received: from [216.36.75.57] (HELO beaver) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 21444705 for w3c-dist-auth@w3c.org; Fri, 04 May 2001 13:43:55 -0700 From: "Lisa Dusseault" To: Date: Fri, 4 May 2001 13:43:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: IE5 & DAV Interoperability Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4911 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I can tell you mod_dav definitely works with Web Folders. (So does my product, Xythos WebFile Server, on apache or off). The trick may be that you've got to set up a web folder: IE 5.5 doesn't know that it's talking to a WebDAV server unless you tell it. Depending on the OS, this is done by creating a new network place in "my network places" or a new web folder in "Web Folders". We've got instructions on www.sharemation.com to help people do this. Frontpage extensions are irrelevant. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Amsden > Sent: Thursday, May 03, 2001 5:44 PM > To: w3c-dist-auth@w3c.org > Subject: Re: IE5 & DAV Interoperability > > > I don't have any problems with web folders, Office 2000, IE5, or > DreamWeaver, but FrontPage, Visual InterDev, and VS.NET don't do WebDAV. > > > > David Logan says: > > Good Morning Folks, > > I have been attempting to get IE5 to talk to our apache 1.3.14 server > using the mod_dav module. Having played around extensively I cannot, for > the life of me, get IE5 talking to the server. It appears that I need to > install Frontpage extensions. In reading the archives of this list, I > can't see anywhere that this gets a mention as being a requirement. > > My understanding of IE5 Web Folders was that it was fairly compliant and > did not require extensions. Am I barking up the wrong tree? > > If this is not the right list for these comments, can somebody please > point me in the right direction? 8-) > > Thanks & Regards > -- > _______________________________________________________________ > > David Logan 102 Cameron Street > Broadband e-Lab Launceston Tas 7250 > Australia > Ph : (03) 6323 2667 > Fax: (03) 6323 2666 > > > From w3c-dist-auth-request@w3.org Fri May 4 17:44:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21341 for ; Fri, 4 May 2001 17:44:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA14350; Fri, 4 May 2001 17:31:28 -0400 (EDT) Resent-Date: Fri, 4 May 2001 17:31:28 -0400 (EDT) Resent-Message-Id: <200105042131.RAA14350@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA14326 for ; Fri, 4 May 2001 17:31:22 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA11599 for ; Fri, 4 May 2001 17:31:20 -0400 Received: from [216.36.75.57] (HELO beaver) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 21450319; Fri, 04 May 2001 14:30:21 -0700 From: "Lisa Dusseault" To: "Dan Brotsky" , Date: Fri, 4 May 2001 14:30:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4912 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I think the only problem with this plan is that folks are worried > about the extra work clients will have to do to do PROPNAME/PROPFIND > pairs (with unioning) rather than a simple ALLPROP. So I ask again > (as a client implementor who doesn't mind doing this): are there any > client-side folks out there who believe the extra work is too > onerous? And, if so, do you have clear requirements for what an > updated ALLPROP needs to do in order to work for you? To go a little further than Dan did, I would like to know why a client would do a propname depth 1, a _union_ of all the properties, and a propfind depth 1. How would they _ever_ display all these disparate properties? What, exactly, is the scenario, and is it known that the scenario would work. 1. The only working scenario I know of that requires discovery of unknown properties is the "explore information about this resource" functionality. E.g. one could imagine using Windows Explorer to right-click on a resource on a WebDAV server, choose "Properties", then choose the "custom" tag, and it might want to display even unknown property names there at the user request. But I can't see that happening for multiple resources at once. For a single resource, obviously it doesn't require doing a union. Also note that this scenario may not require getting the values of all the properties -- the display would be simplest if it displayed only the names of properties, since some properties have long complex XML values, and then let the user select interesting properties to display the value. 2. I'll explore the replication scenario as well but it's basically an unworkable scenario based solely on RFC2518. That's because property replication is impossible to do with only standard elements of WebDAV, even if we did keep allprop. - If the client doesn't know what properties exist, it can't know which of them are dead properties. It can't replicate live properties. Replication would require some way of listing or marking up those properties which can be replicated safely. - If the client DOES know what dead properties it can safely replicate, it can ask for them explicitly. - With the current discussion of getlastmodified in mind, clients can't know when properties change (unless they rely on a particular WebDAV implementation). Thus it's impossible to know when to replicate property values. - The client can do 'propname' and individual specific PROPFIND requests for each resource if absolutely necessary. These can be pipelined for efficiency. In fact, it may be easier to separate them out and pipeline them, than it would be to do depth requests and then to have to deal with the size of a serious depth allprop request. - Operating against regular webDAV servers, it's quite possible clients will discover that serious depth allprop requests won't work. I wouldn't be surprised if various resource limitation safeguards programmed into various WebDAV servers would cut off the response part way through or fail it completely. With all these considerations, I do not think replication of properties is decently possible in RFC2518 without writing serious server and client protocol extensions. If these server and client protocol extensions are being done in order to do replication properly, then surely they will design something better than allprop anyway. Lisa From w3c-dist-auth-request@w3.org Fri May 4 19:01:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22030 for ; Fri, 4 May 2001 19:01:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA16132; Fri, 4 May 2001 18:54:50 -0400 (EDT) Resent-Date: Fri, 4 May 2001 18:54:50 -0400 (EDT) Resent-Message-Id: <200105042254.SAA16132@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA16112 for ; Fri, 4 May 2001 18:54:46 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA17349 for ; Fri, 4 May 2001 18:54:45 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id XAA137142 for ; Fri, 4 May 2001 23:45:14 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id XAA111804 for ; Fri, 4 May 2001 23:54:08 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A42.007DCB7A ; Fri, 4 May 2001 23:54:00 +0100 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <80256A42.007DCB58.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 4 May 2001 23:52:05 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4913 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: "Jason Crawford" wrote: > << > I think the key part of Geoff's post is "the subset that it can use". The > problem with allprop is that it will return all the live properties > irrespective of whether the client is aware of the properties' semantics. > Sometimes this is what the client wants, say if it is naively displaying a > property sheet; but most likely it is not since there is no way for the > client to interpret the values or know if/how they can be changed. > >> > Actually I'd think that property sheet case would be pretty common. It may be common, but it isn't very interesting, especially since a client likely cannot display the value in a meaningful way or update the value. > And > removing allprop isn't going to prevent people from doing the same thing... > now with two requests rather than one. And sometimes for wide directories > it will be difficult to avoid this (suspected) problem even without > ALLPROP. No dispute that people can write dumb and/or harmful clients. > If this is actually the pivotal concern, I think the best you can > do just warn people of the potential cost that we see of using allprop. > From there on in, let time tell if it's really a problem. If we discover > it is, let's *really* solves the problem then. I'm willing to remove > ALLPROP, but it doesn't sound like doing that really would solve the > problem and it's not clear if there is a problem. I'm actually indifferent to removing allprop -- but I do think that the default for no body and no Depth: header being allprop depth infinity is bizzare. > > It's the old NRA argument -- allprop doesn't kill servers, clients kill > > servers ;-) > At first I thought that analogy was flawed, but as I think about it, I > think that the situation is analogous. This discussion seems to have all > of the same aspects. The differences I see are... > > 1) I don't think it's clear that there actually is a problem in 2518 that > we need to solve. > 2) In 2518, the people that would be vicitimized by the concern are > actually in (more) control over whether they are vulnerable. (Client > programers can discover that they don't really want all those random > properties and perhaps conclude that it's slowing their response time and > stop using ALLPROP. I think clients can disconnect if a response is too > long. And I think servers (with guidance from us) can chose to reject > certain requests if they really feel that they are too expensive.) > > << > I have to agree that it is a stealth action to undermine (the effects of) > allprop. > >> > I'm guessing you're joking, but I'd like to hear why that was put in that > spec. Was there some issue involved that we haven't mentioned here? Not really. Delta-V was spec'd to not return all versioning properties in allprop requests _because_ it was felt that the response would be too expensive for servers to compute, and the scenarios where a client can really make use of all the versioning values taken at a point in time are limited if not minimal. If the issue is tackled in RFC2518 then there would be less incentive for Delta-V to take such a stance. > As it stands now, I have a mild preference for leaving allprop in. I'm > *very* willing to support another position if it will bring us to agreement > and not do any serious damage. > > J. > Tim From w3c-dist-auth-request@w3.org Fri May 4 19:04:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22053 for ; Fri, 4 May 2001 19:04:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA04039; Fri, 4 May 2001 13:43:49 -0400 (EDT) Resent-Date: Fri, 4 May 2001 13:43:49 -0400 (EDT) Resent-Message-Id: <200105041743.NAA04039@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA04019 for ; Fri, 4 May 2001 13:43:44 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA26756 for ; Fri, 4 May 2001 13:43:43 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA408616 for ; Fri, 4 May 2001 13:41:25 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id NAA28788; Fri, 4 May 2001 13:37:48 -0400 Importance: Normal To: Tim_Ellison@uk.ibm.com Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 4 May 2001 12:45:49 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 05/04/2001 01:42:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4909 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << I think the key part of Geoff's post is "the subset that it can use". The problem with allprop is that it will return all the live properties irrespective of whether the client is aware of the properties' semantics. Sometimes this is what the client wants, say if it is naively displaying a property sheet; but most likely it is not since there is no way for the client to interpret the values or know if/how they can be changed. >> Actually I'd think that property sheet case would be pretty common. And removing allprop isn't going to prevent people from doing the same thing... now with two requests rather than one. And sometimes for wide directories it will be difficult to avoid this (suspected) problem even without ALLPROP. If this is actually the pivotal concern, I think the best you can do just warn people of the potential cost that we see of using allprop. From there on in, let time tell if it's really a problem. If we discover it is, let's *really* solves the problem then. I'm willing to remove ALLPROP, but it doesn't sound like doing that really would solve the problem and it's not clear if there is a problem. > It's the old NRA argument -- allprop doesn't kill servers, clients kill > servers ;-) At first I thought that analogy was flawed, but as I think about it, I think that the situation is analogous. This discussion seems to have all of the same aspects. The differences I see are... 1) I don't think it's clear that there actually is a problem in 2518 that we need to solve. 2) In 2518, the people that would be vicitimized by the concern are actually in (more) control over whether they are vulnerable. (Client programers can discover that they don't really want all those random properties and perhaps conclude that it's slowing their response time and stop using ALLPROP. I think clients can disconnect if a response is too long. And I think servers (with guidance from us) can chose to reject certain requests if they really feel that they are too expensive.) << I have to agree that it is a stealth action to undermine (the effects of) allprop. >> I'm guessing you're joking, but I'd like to hear why that was put in that spec. Was there some issue involved that we haven't mentioned here? As it stands now, I have a mild preference for leaving allprop in. I'm *very* willing to support another position if it will bring us to agreement and not do any serious damage. J. From w3c-dist-auth-request@w3.org Fri May 4 19:09:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22090 for ; Fri, 4 May 2001 19:09:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA16403; Fri, 4 May 2001 19:03:11 -0400 (EDT) Resent-Date: Fri, 4 May 2001 19:03:11 -0400 (EDT) Resent-Message-Id: <200105042303.TAA16403@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA16380 for ; Fri, 4 May 2001 19:03:06 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA17888 for ; Fri, 4 May 2001 19:03:06 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id XAA129014 for ; Fri, 4 May 2001 23:46:54 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id AAA95638 for ; Sat, 5 May 2001 00:02:29 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A42.007E90A0 ; Sat, 5 May 2001 00:02:25 +0100 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <80256A42.007E8EA6.00@d06mta07.portsmouth.uk.ibm.com> Date: Sat, 5 May 2001 00:02:04 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4914 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Lisa. Regards, Tim Ellison -------- Original Message -------- "Lisa Dusseault" wrote: > I think the only problem with this plan is that folks are worried > about the extra work clients will have to do to do PROPNAME/PROPFIND > pairs (with unioning) rather than a simple ALLPROP. So I ask again > (as a client implementor who doesn't mind doing this): are there any > client-side folks out there who believe the extra work is too > onerous? And, if so, do you have clear requirements for what an > updated ALLPROP needs to do in order to work for you? To go a little further than Dan did, I would like to know why a client would do a propname depth 1, a _union_ of all the properties, and a propfind depth 1. How would they _ever_ display all these disparate properties? What, exactly, is the scenario, and is it known that the scenario would work. 1. The only working scenario I know of that requires discovery of unknown properties is the "explore information about this resource" functionality. E.g. one could imagine using Windows Explorer to right-click on a resource on a WebDAV server, choose "Properties", then choose the "custom" tag, and it might want to display even unknown property names there at the user request. But I can't see that happening for multiple resources at once. For a single resource, obviously it doesn't require doing a union. Also note that this scenario may not require getting the values of all the properties -- the display would be simplest if it displayed only the names of properties, since some properties have long complex XML values, and then let the user select interesting properties to display the value. 2. I'll explore the replication scenario as well but it's basically an unworkable scenario based solely on RFC2518. That's because property replication is impossible to do with only standard elements of WebDAV, even if we did keep allprop. - If the client doesn't know what properties exist, it can't know which of them are dead properties. It can't replicate live properties. Replication would require some way of listing or marking up those properties which can be replicated safely. - If the client DOES know what dead properties it can safely replicate, it can ask for them explicitly. - With the current discussion of getlastmodified in mind, clients can't know when properties change (unless they rely on a particular WebDAV implementation). Thus it's impossible to know when to replicate property values. - The client can do 'propname' and individual specific PROPFIND requests for each resource if absolutely necessary. These can be pipelined for efficiency. In fact, it may be easier to separate them out and pipeline them, than it would be to do depth requests and then to have to deal with the size of a serious depth allprop request. - Operating against regular webDAV servers, it's quite possible clients will discover that serious depth allprop requests won't work. I wouldn't be surprised if various resource limitation safeguards programmed into various WebDAV servers would cut off the response part way through or fail it completely. With all these considerations, I do not think replication of properties is decently possible in RFC2518 without writing serious server and client protocol extensions. If these server and client protocol extensions are being done in order to do replication properly, then surely they will design something better than allprop anyway. Lisa From w3c-dist-auth-request@w3.org Fri May 4 21:09:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23182 for ; Fri, 4 May 2001 21:09:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA18047; Fri, 4 May 2001 21:02:31 -0400 (EDT) Resent-Date: Fri, 4 May 2001 21:02:31 -0400 (EDT) Resent-Message-Id: <200105050102.VAA18047@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA18026 for ; Fri, 4 May 2001 21:02:27 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA25346 for ; Fri, 4 May 2001 21:02:26 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA01892 for w3c-dist-auth@w3.org; Fri, 4 May 2001 18:05:39 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 4 May 2001 18:05:39 -0700 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20010504180539.B1374@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ccjason@us.ibm.com on Fri, May 04, 2001 at 12:45:49PM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4915 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Fri, May 04, 2001 at 12:45:49PM -0400, Jason Crawford wrote: > << > I think the key part of Geoff's post is "the subset that it can use". The > problem with allprop is that it will return all the live properties > irrespective of whether the client is aware of the properties' semantics. > Sometimes this is what the client wants, say if it is naively displaying a > property sheet; but most likely it is not since there is no way for the > client to interpret the values or know if/how they can be changed. > >> > Actually I'd think that property sheet case would be pretty common. And > removing allprop isn't going to prevent people from doing the same thing... > now with two requests rather than one. That is my point exactly. Tossing allprop is not going to affect Geoff's issue with computed properties. > And sometimes for wide directories > it will be difficult to avoid this (suspected) problem even without > ALLPROP. If this is actually the pivotal concern, I think the best you can > do just warn people of the potential cost that we see of using allprop. > >From there on in, let time tell if it's really a problem. If we discover > it is, let's *really* solves the problem then. I'm willing to remove > ALLPROP, but it doesn't sound like doing that really would solve the > problem and it's not clear if there is a problem. Right! > > It's the old NRA argument -- allprop doesn't kill servers, clients kill > > servers ;-) > At first I thought that analogy was flawed, but as I think about it, I > think that the situation is analogous. This discussion seems to have all > of the same aspects. The differences I see are... > > 1) I don't think it's clear that there actually is a problem in 2518 that > we need to solve. > 2) In 2518, the people that would be vicitimized by the concern are > actually in (more) control over whether they are vulnerable. (Client > programers can discover that they don't really want all those random > properties and perhaps conclude that it's slowing their response time and > stop using ALLPROP. I think clients can disconnect if a response is too > long. And I think servers (with guidance from us) can chose to reject > certain requests if they really feel that they are too expensive.) Yup. I'd prefer the guidance approach. mod_dav (in its default configuration) will simply refuse Depth:infinity PROPFIND requests (of any variety). Not necessarily nice, but that was the approach I took. I'd much rather have a "recommendation" from the Working Group on how to do that. > << > I have to agree that it is a stealth action to undermine (the effects of) > allprop. > >> > I'm guessing you're joking, but I'd like to hear why that was put in that > spec. Was there some issue involved that we haven't mentioned here? I doubt it was joking. It truly was a stealth action. I've never noticed it before. Looks like it was in 14.1 and 15 at least. --------------------- In Lisa's post, she posits some possible scenarios. Here is an *actual* scenario, today: Subversion (SVN) (the version control system, which uses DeltaV for its network protocol) exposes the notion of properties on the resources. The client can get/set them at will, and they are committed along with content changes to the repository. SVN uses a CVS-like model, or "client-side" if you will. The content is pulled down to the client, edits are made, and at commit time, everything is pushed back up to the server. (blah blah blah about conflict resolution) So... when the checkout is performed and content is pulled down to the client, we need to do a PROPFIND/allprop to fetch all the properties that may have been attached to the resource. The user can then add/change/delete the properites, and commit them back. That allprop is the key, and our actual use scenario. --------------------- I explained how a propname followed by a fetch was non-trivial for the client, but Tim said "nah, that's trivial." Sorry, but I have to disagree. You're talking about a good chunk of code to union all of those names and their namespaces, assigning prefixes to all of them, generating the new request with all that data, then parsing through all the results where you have a mix of 200'd properties and 404'd properties. That is very non-trivial in my book. [ and yes: I'm both the client and server implementor ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri May 4 21:13:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23226 for ; Fri, 4 May 2001 21:13:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA18125; Fri, 4 May 2001 21:08:26 -0400 (EDT) Resent-Date: Fri, 4 May 2001 21:08:26 -0400 (EDT) Resent-Message-Id: <200105050108.VAA18125@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA18105 for ; Fri, 4 May 2001 21:08:22 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA25638 for ; Fri, 4 May 2001 21:08:22 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA01901 for w3c-dist-auth@w3.org; Fri, 4 May 2001 18:11:40 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 4 May 2001 18:11:40 -0700 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20010504181140.C1374@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from dbrotsky@Adobe.COM on Fri, May 04, 2001 at 11:33:59AM -0700 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4916 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Fri, May 04, 2001 at 11:33:59AM -0700, Dan Brotsky wrote: > At 12:45 PM -0400 5/4/01, Jason Crawford wrote: > >As it stands now, I have a mild preference for leaving allprop in. I'm > >*very* willing to support another position if it will bring us to agreement > >and not do any serious damage. > > That was the point I was trying to make (apparently not very well :^) > in my earlier message. The problem with leaving ALLPROP in is that > we're clearly going to be changing its semantics (e.g., forbidding ^^^^ "clearly" is not all that clear :-) ... assuming it is left in, then I believe we'll make some guidance as to how clients should use it, and what servers can do when they see it. But changing its semantics would be a backwards-compat bitch. IMO, we just note that servers are allowed to return errors on allprop/infinity if they want to (just because, or because they see that it will be too expensive). >... > I think the only problem with this plan is that folks are worried > about the extra work clients will have to do to do PROPNAME/PROPFIND > pairs (with unioning) rather than a simple ALLPROP. So I ask again > (as a client implementor who doesn't mind doing this): are there any > client-side folks out there who believe the extra work is too > onerous? Yes. It is burdensome when the existing specification meets my needs exactly. Nobody has yet shown that the existing spec is *broken*. The only thing raised so far is "it bogs the server when computed props exist" and the alternative to do a propname/propfind; but the alternative has the *same* server performance characteristics. And I maintain worse perf from a systemwide standpoint. > And, if so, do you have clear requirements for what an > updated ALLPROP needs to do in order to work for you? Personally, I would recommend leaving it just as it is, with a note in the spec that the server can return error in certain cases. The client should interpret that as "whoops. we asked too much" and back off to a nicer algorithm. (and better yet, just start with the nice one) For my particular scenario, the "fetch by namespace" would be ideal. I could put all of the SVN user properties into a particular namespace and just fetch those. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri May 4 21:16:36 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23290 for ; Fri, 4 May 2001 21:16:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA18323; Fri, 4 May 2001 21:11:17 -0400 (EDT) Resent-Date: Fri, 4 May 2001 21:11:17 -0400 (EDT) Resent-Message-Id: <200105050111.VAA18323@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA18303 for ; Fri, 4 May 2001 21:11:13 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA25914 for ; Fri, 4 May 2001 21:11:13 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA01910 for w3c-dist-auth@w3.org; Fri, 4 May 2001 18:14:34 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 4 May 2001 18:14:34 -0700 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20010504181434.D1374@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org References: <80256A42.007DCB58.00@d06mta07.portsmouth.uk.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <80256A42.007DCB58.00@d06mta07.portsmouth.uk.ibm.com>; from Tim_Ellison@uk.ibm.com on Fri, May 04, 2001 at 11:52:05PM +0100 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4917 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Fri, May 04, 2001 at 11:52:05PM +0100, Tim_Ellison@uk.ibm.com wrote: > "Jason Crawford" wrote: > > If this is actually the pivotal concern, I think the best you can > > do just warn people of the potential cost that we see of using allprop. > > From there on in, let time tell if it's really a problem. If we discover > > it is, let's *really* solves the problem then. I'm willing to remove > > ALLPROP, but it doesn't sound like doing that really would solve the > > problem and it's not clear if there is a problem. > > I'm actually indifferent to removing allprop -- but I do think that the > default for no body and no Depth: header being allprop depth infinity is > bizzare. That was an unfortunate choice. Even worse, I'm not sure how we can change that without breaking clients and servers across the globe. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat May 5 01:57:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03512 for ; Sat, 5 May 2001 01:57:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA28660; Sat, 5 May 2001 01:50:16 -0400 (EDT) Resent-Date: Sat, 5 May 2001 01:50:16 -0400 (EDT) Resent-Message-Id: <200105050550.BAA28660@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA28624 for ; Sat, 5 May 2001 01:50:10 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id BAA12237 for ; Sat, 5 May 2001 01:50:10 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sat, 05 May 2001 01:52:29 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 5 May 2001 01:52:29 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102DB9224@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Sat, 5 May 2001 01:49:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4918 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Greg Stein [mailto:gstein@lyra.org] > I have to agree that [allowing a server to not return versioning > properties with DAV:allprop] is a stealth action to undermine > (the effects of) allprop. > I'm guessing you're joking, but I'd like to hear why that was put in that > spec. Was there some issue involved that we haven't mentioned here? I doubt it was joking. It truly was a stealth action. I've never noticed it before. Looks like it was in 14.1 and 15 at least. Since this topic was discussed at length at the last IETF DeltaV meeting, and then reported to this mailing list in the official minutes for that meeting, I'm not sure that "truly a stealth action" is either a fair or accurate description of the process. Since the deltav properties cannot be understood in their raw form by a user, nor (for the most part) can they be updated by a PROPATCH, Lisa's comments apply, and it would be pointless for a client to retrieve them if that client does not explicitly understand their semantics (in which case, it can ask for them explicitly). Cheers, Geoff From w3c-dist-auth-request@w3.org Sat May 5 02:00:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04019 for ; Sat, 5 May 2001 02:00:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA28679; Sat, 5 May 2001 01:50:26 -0400 (EDT) Resent-Date: Sat, 5 May 2001 01:50:26 -0400 (EDT) Resent-Message-Id: <200105050550.BAA28679@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA28641 for ; Sat, 5 May 2001 01:50:13 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id BAA12239 for ; Sat, 5 May 2001 01:50:13 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sat, 05 May 2001 01:52:29 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 5 May 2001 01:52:29 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102DB9223@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Sat, 5 May 2001 01:49:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4919 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Tim, Lisa, and Dan (:-). Cheers, Geoff -----Original Message----- From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] I agree with Lisa. Regards, Tim Ellison -------- Original Message -------- "Lisa Dusseault" wrote: > I think the only problem with this plan is that folks are worried > about the extra work clients will have to do to do PROPNAME/PROPFIND > pairs (with unioning) rather than a simple ALLPROP. So I ask again > (as a client implementor who doesn't mind doing this): are there any > client-side folks out there who believe the extra work is too > onerous? And, if so, do you have clear requirements for what an > updated ALLPROP needs to do in order to work for you? To go a little further than Dan did, I would like to know why a client would do a propname depth 1, a _union_ of all the properties, and a propfind depth 1. How would they _ever_ display all these disparate properties? What, exactly, is the scenario, and is it known that the scenario would work. 1. The only working scenario I know of that requires discovery of unknown properties is the "explore information about this resource" functionality. E.g. one could imagine using Windows Explorer to right-click on a resource on a WebDAV server, choose "Properties", then choose the "custom" tag, and it might want to display even unknown property names there at the user request. But I can't see that happening for multiple resources at once. For a single resource, obviously it doesn't require doing a union. Also note that this scenario may not require getting the values of all the properties -- the display would be simplest if it displayed only the names of properties, since some properties have long complex XML values, and then let the user select interesting properties to display the value. 2. I'll explore the replication scenario as well but it's basically an unworkable scenario based solely on RFC2518. That's because property replication is impossible to do with only standard elements of WebDAV, even if we did keep allprop. - If the client doesn't know what properties exist, it can't know which of them are dead properties. It can't replicate live properties. Replication would require some way of listing or marking up those properties which can be replicated safely. - If the client DOES know what dead properties it can safely replicate, it can ask for them explicitly. - With the current discussion of getlastmodified in mind, clients can't know when properties change (unless they rely on a particular WebDAV implementation). Thus it's impossible to know when to replicate property values. - The client can do 'propname' and individual specific PROPFIND requests for each resource if absolutely necessary. These can be pipelined for efficiency. In fact, it may be easier to separate them out and pipeline them, than it would be to do depth requests and then to have to deal with the size of a serious depth allprop request. - Operating against regular webDAV servers, it's quite possible clients will discover that serious depth allprop requests won't work. I wouldn't be surprised if various resource limitation safeguards programmed into various WebDAV servers would cut off the response part way through or fail it completely. With all these considerations, I do not think replication of properties is decently possible in RFC2518 without writing serious server and client protocol extensions. If these server and client protocol extensions are being done in order to do replication properly, then surely they will design something better than allprop anyway. Lisa From w3c-dist-auth-request@w3.org Sat May 5 11:31:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16090 for ; Sat, 5 May 2001 11:31:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA07282; Sat, 5 May 2001 11:24:47 -0400 (EDT) Resent-Date: Sat, 5 May 2001 11:24:47 -0400 (EDT) Resent-Message-Id: <200105051524.LAA07282@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA07261 for ; Sat, 5 May 2001 11:24:41 -0400 (EDT) Received: from matrixmail.matrix-one.com (matrixone.com [4.17.165.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA14028 for ; Sat, 5 May 2001 11:24:42 -0400 Received: from kdyer by kdyer (8.10.1/8.10.1) with SMTP id f45FO2Q00687; Sat, 5 May 2001 11:24:02 -0400 (EDT) Reply-To: From: "Kevin Dyer" To: "Lisa Dusseault" , "Dan Brotsky" , Date: Sat, 5 May 2001 11:24:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4920 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think everyone on this thread is in agreement. I would like to offer a different POV for Lisa's first scenario: > 1. The only working scenario I know of that requires discovery of unknown > properties is the "explore information about this resource" functionality. > E.g. one could imagine using Windows Explorer to right-click on a resource > on a WebDAV server, choose "Properties", then choose the "custom" tag, and > it might want to display even unknown property names there at the user > request. But I can't see that happening for multiple resources at once. > For a single resource, obviously it doesn't require doing a union. > > Also note that this scenario may not require getting the values of all the > properties -- the display would be simplest if it displayed only the names > of properties, since some properties have long complex XML values, and then > let the user select interesting properties to display the value. If one solely thinks about a "WebDAV" client as something like a Windows Explorer then you're correct. But think about the marriage of Collaborative Product Commerce tools ( or PDM ) with WebDAV. Folders and files are nodes in a hierarchical network that have complex relationships. The client is now requesting how to navigate the relationships between nodes. The complex XML values provide the additional attributes, alternate or substitute components, and possible T&Cs for digital rights to access files or the next node. Depending on what nodes are returned to an initial query the client may have to perform a significant amount of ancillary requesting to meet the minimum display requirements. The server-side of this configuration must walk the thin-line between two extremes of the WebDAV world. It must still serve the requests of the minimilist clients so that a Windows Explorer or Office integration will still be able to find, display, author files and yet service the requests of the more challenging clients. Just a different point of view, Kevin From w3c-dist-auth-request@w3.org Sat May 5 16:09:43 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17748 for ; Sat, 5 May 2001 16:09:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA12208; Sat, 5 May 2001 16:07:04 -0400 (EDT) Resent-Date: Sat, 5 May 2001 16:07:04 -0400 (EDT) Resent-Message-Id: <200105052007.QAA12208@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA12124 for ; Sat, 5 May 2001 16:06:57 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA31065 for ; Sat, 5 May 2001 16:06:57 -0400 Received: from gmgw02.oraclecorp.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail4.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f45K1lD03718 for ; Sat, 5 May 2001 13:01:47 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by gmgw02.oraclecorp.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f45K68u03603 for ; Sat, 5 May 2001 13:06:08 -0700 (PDT) From: "Eric Sedlar" To: Date: Sat, 5 May 2001 12:59:33 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B102DB9223@SUS-MA1IT01> Importance: Normal Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4921 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Maybe we should examine what it takes to replicate WebDAV servers. I think that this is a general problem people are going to want to address, and I know of several people trying to do this. --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, May 04, 2001 10:49 PM > To: w3c-dist-auth@w3.org > Subject: RE: Issue: ALLPROP_AND_COMPUTED > > > I agree with Tim, Lisa, and Dan (:-). > > Cheers, > Geoff > > -----Original Message----- > From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] > > I agree with Lisa. > > Regards, > > Tim Ellison > -------- Original Message -------- > "Lisa Dusseault" wrote: > > > I think the only problem with this plan is that folks are worried > > about the extra work clients will have to do to do PROPNAME/PROPFIND > > pairs (with unioning) rather than a simple ALLPROP. So I ask again > > (as a client implementor who doesn't mind doing this): are there any > > client-side folks out there who believe the extra work is too > > onerous? And, if so, do you have clear requirements for what an > > updated ALLPROP needs to do in order to work for you? > > To go a little further than Dan did, I would like to know why a client > would > do a propname depth 1, a _union_ of all the properties, and a propfind > depth > 1. How would they _ever_ display all these disparate properties? What, > exactly, is the scenario, and is it known that the scenario would work. > > 1. The only working scenario I know of that requires discovery of unknown > properties is the "explore information about this resource" functionality. > E.g. one could imagine using Windows Explorer to right-click on a resource > on a WebDAV server, choose "Properties", then choose the "custom" tag, and > it might want to display even unknown property names there at the user > request. But I can't see that happening for multiple resources at once. > For a single resource, obviously it doesn't require doing a union. > > Also note that this scenario may not require getting the values of all the > properties -- the display would be simplest if it displayed only the names > of properties, since some properties have long complex XML > values, and then > let the user select interesting properties to display the value. > > 2. I'll explore the replication scenario as well but it's basically an > unworkable scenario based solely on RFC2518. That's because property > replication is impossible to do with only standard elements of > WebDAV, even > if we did keep allprop. > - If the client doesn't know what properties exist, it can't > know which of > them are dead properties. It can't replicate live properties. > Replication > would require some way of listing or marking up those properties which can > be replicated safely. > - If the client DOES know what dead properties it can safely > replicate, it > can ask for them explicitly. > - With the current discussion of getlastmodified in mind, clients can't > know when properties change (unless they rely on a particular WebDAV > implementation). Thus it's impossible to know when to replicate property > values. > - The client can do 'propname' and individual specific PROPFIND requests > for each resource if absolutely necessary. These can be pipelined for > efficiency. In fact, it may be easier to separate them out and pipeline > them, than it would be to do depth requests and then to have to deal with > the size of a serious depth allprop request. > - Operating against regular webDAV servers, it's quite possible clients > will discover that serious depth allprop requests won't work. I wouldn't > be > surprised if various resource limitation safeguards programmed > into various > WebDAV servers would cut off the response part way through or fail it > completely. > > With all these considerations, I do not think replication of properties is > decently possible in RFC2518 without writing serious server and client > protocol extensions. If these server and client protocol extensions are > being done in order to do replication properly, then surely they will > design > something better than allprop anyway. > > Lisa > > > > > From w3c-dist-auth-request@w3.org Sat May 5 21:17:42 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19185 for ; Sat, 5 May 2001 21:17:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA19732; Sat, 5 May 2001 21:13:00 -0400 (EDT) Resent-Date: Sat, 5 May 2001 21:13:00 -0400 (EDT) Resent-Message-Id: <200105060113.VAA19732@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA19708 for ; Sat, 5 May 2001 21:12:51 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA17912 for ; Sat, 5 May 2001 21:12:51 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f461CFj02020; Sat, 5 May 2001 18:12:15 -0700 (PDT) From: "Lisa Dusseault" To: "Greg Stein" , Date: Sat, 5 May 2001 18:10:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20010504181434.D1374@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4922 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > That was an unfortunate choice. Even worse, I'm not sure how we can change > that without breaking clients and servers across the globe. Easy, even if it were needed. Redefine "allprop" as "all properties defined in 2518". But I question whether it's needed. Since not all servers return all RFC2518 properties in response to allprop (e.g. not returning DAV:lockdiscovery), and since obviously clients and servers across the globe aren't already broken, is any client relying on allprop for getting all properties? lisa From w3c-dist-auth-request@w3.org Sun May 6 09:11:59 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09984 for ; Sun, 6 May 2001 09:11:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA03186; Sun, 6 May 2001 09:10:01 -0400 (EDT) Resent-Date: Sun, 6 May 2001 09:10:01 -0400 (EDT) Resent-Message-Id: <200105061310.JAA03186@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA03164 for ; Sun, 6 May 2001 09:09:56 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA00465 for ; Sun, 6 May 2001 09:09:58 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA08046 for ; Sun, 6 May 2001 09:07:37 -0400 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id JAA88922 for ; Sun, 6 May 2001 09:03:58 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Sun, 6 May 2001 09:05:22 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/06/2001 09:09:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: replicating properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4923 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Lisa says: With all these considerations, I do not think replication of properties is decently possible in RFC2518 without writing serious server and client protocol extensions. If these server and client protocol extensions are being done in order to do replication properly, then surely they will design something better than allprop anyway. DAV4J implements copy across servers by GET/PUT, PROPFIND/PROPPATCH. This seems like simple symmetry that the protocol should support. DAV4J does the properties by trying the PROPPATCH, getting the errors back, and filtering out the ones that didn't make it because they were live on the destination server. That is, simulating keepalive behavior. Live properties on the source server may be converted to dead properties on the destination. This seemed sensible enough in situations where servers support different live properties. The only thing that would make this simpler is if PROPPATCH supported keepalive like copy. This would eliminate the need to simulate it by the multiple round trips currently being made to copy the properties. I had proposed such an extension to PROPPATCH a while back. From w3c-dist-auth-request@w3.org Sun May 6 09:23:48 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10076 for ; Sun, 6 May 2001 09:23:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA03533; Sun, 6 May 2001 09:21:41 -0400 (EDT) Resent-Date: Sun, 6 May 2001 09:21:41 -0400 (EDT) Resent-Message-Id: <200105061321.JAA03533@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA03509 for ; Sun, 6 May 2001 09:21:36 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA01221 for ; Sun, 6 May 2001 09:21:37 -0400 Received: from southrelay03.raleigh.ibm.com (southrelay03.raleigh.ibm.com [9.37.3.210]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA210592 for ; Sun, 6 May 2001 09:15:26 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay03.raleigh.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id JAA44374 for ; Sun, 6 May 2001 09:21:12 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Sun, 6 May 2001 09:16:34 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/06/2001 09:21:18 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4924 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: Greg (and Jason seems to agree): Personally, I would recommend leaving it just as it is, with a note in the spec that the server can return error in certain cases. The client should interpret that as "whoops. we asked too much" and back off to a nicer algorithm. (and better yet, just start with the nice one) I also agree, but think the default should probably be changed to depth 0. Althought clients are free to deal with that too. DAV4J's Resource.getProperties() method uses a depth 0 default in its marshalling. It doesn't really matter what the protocol specifies. Clients can use what they want. allprop is just one option for getting properties. If servers are slow or fail on it, client writers will discover this and adjust accordingly. I don't think there's any need for the protocol to try to solve it any further. Some servers can return all the properties pretty fast. As slow as the DAV4J server is on most operations, it can return all the properties pretty fast since they're all in a single XML document. Depth infinity isn't that slow either, but their might be a lot of files returned! From w3c-dist-auth-request@w3.org Sun May 6 10:28:46 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11006 for ; Sun, 6 May 2001 10:28:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA05650; Sun, 6 May 2001 10:24:52 -0400 (EDT) Resent-Date: Sun, 6 May 2001 10:24:52 -0400 (EDT) Resent-Message-Id: <200105061424.KAA05650@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA05628 for ; Sun, 6 May 2001 10:24:48 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA05057 for ; Sun, 6 May 2001 10:24:49 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 06 May 2001 10:27:02 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 May 2001 10:27:02 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102EF4D98@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sun, 6 May 2001 10:27:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4925 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I personally would like to be a bit more proactive than "let's wait until it breaks before worrying about it". By then, all the broken, non-interoperable clients and servers have been deployed, and its too late for a clean or simple fix. The fact that DAV:allprop can be efficiently implemented by a server that supports only the 2518 properties and the relatively few number of dead properties that clients create these days is not the problem. It is the fact that large numbers of expensive to compute properties are currently being defined, both in the protocol and as custom properties, that raises the concern. Having clients "discover and adjust" is not a good technique for achieving interoperability. The fact that DAV4J ignores the 2518 requirement that by default a PROPFIND MUST be DAV:allprop, is a good example of the interoperability problems that arise when the protocol makes a poor choice of exposing functionality. A client writer would need to be aware of the various "variations from the protocol" that have been chosen by various server implementors (e.g. returning "errors" on requests that the server feels are "too expensive"), and then try a sequence of alternative requests to get the desired result. Cheers, Geoff -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Sunday, May 06, 2001 9:17 AM To: w3c-dist-auth@w3c.org Subject: Re: Issue: ALLPROP_AND_COMPUTED Greg (and Jason seems to agree): Personally, I would recommend leaving it just as it is, with a note in the spec that the server can return error in certain cases. The client should interpret that as "whoops. we asked too much" and back off to a nicer algorithm. (and better yet, just start with the nice one) I also agree, but think the default should probably be changed to depth 0. Althought clients are free to deal with that too. DAV4J's Resource.getProperties() method uses a depth 0 default in its marshalling. It doesn't really matter what the protocol specifies. Clients can use what they want. allprop is just one option for getting properties. If servers are slow or fail on it, client writers will discover this and adjust accordingly. I don't think there's any need for the protocol to try to solve it any further. Some servers can return all the properties pretty fast. As slow as the DAV4J server is on most operations, it can return all the properties pretty fast since they're all in a single XML document. Depth infinity isn't that slow either, but their might be a lot of files returned! From w3c-dist-auth-request@w3.org Sun May 6 17:01:34 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13745 for ; Sun, 6 May 2001 17:01:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21545; Sun, 6 May 2001 16:12:37 -0400 (EDT) Resent-Date: Sun, 6 May 2001 16:12:37 -0400 (EDT) Resent-Message-Id: <200105062012.QAA21545@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA21525 for ; Sun, 6 May 2001 16:12:32 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA28068 for ; Sun, 6 May 2001 16:12:33 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA321208 for ; Sun, 6 May 2001 16:10:09 -0400 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id QAA53466 for ; Sun, 6 May 2001 16:06:33 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Sun, 6 May 2001 16:08:24 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/06/2001 04:11:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4926 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Geoff says: Having clients "discover and adjust" is not a good technique for achieving interoperability. The fact that DAV4J ignores the 2518 requirement that by default a PROPFIND MUST be DAV:allprop, is a good example of the interoperability problems that arise when the protocol makes a poor choice of exposing functionality. A client writer would need to be aware of the various "variations from the protocol" that have been chosen by various server implementors (e.g. returning "errors" on requests that the server feels are "too expensive"), and then try a sequence of alternative requests to get the desired result. This is not really an interoperability issue unless servers routinely fail allprop requests. I don't think the protocol anticipate all the policies of clients might choose to use in requests. That's like saying all distributed object applications that make a lot of fine-grained remote procedure calls should be prevented from doing so by redesigning RPC protocols so only some new kind of course-grained service calls can be made. DAV4J does not introduce an interoperability problem with its use of Resource.getProperties(). The protocol on the wire is DAV compliant. This (client) method simply marshalls its default depth as 0 instead of infinity. If you want infinity, you need to say so. The DAV4J server is unaware of this convention, and if it gets a PROPFIND without a depth header, it does depth infinity. I'm still inclined to leave allprop alone, and just not use it, or use it very carefully, in any clients I might write. The DAV4J cross-server copy does rely in allprop to copy the resource properties. From w3c-dist-auth-request@w3.org Sun May 6 18:41:52 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14501 for ; Sun, 6 May 2001 18:41:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA24433; Sun, 6 May 2001 17:44:38 -0400 (EDT) Resent-Date: Sun, 6 May 2001 17:44:38 -0400 (EDT) Resent-Message-Id: <200105062144.RAA24433@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA24411 for ; Sun, 6 May 2001 17:44:33 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA01088 for ; Sun, 6 May 2001 17:44:34 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 06 May 2001 17:46:43 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 May 2001 17:46:43 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102EF4DCE@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sun, 6 May 2001 17:46:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4927 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: Oops. I meant to say "ignores the 2518 requirement that by default a PROPFIND must be Depth:infinity". Cheers, Geoff -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Sunday, May 06, 2001 10:27 AM To: w3c-dist-auth@w3c.org Subject: RE: Issue: ALLPROP_AND_COMPUTED I personally would like to be a bit more proactive than "let's wait until it breaks before worrying about it". By then, all the broken, non-interoperable clients and servers have been deployed, and its too late for a clean or simple fix. The fact that DAV:allprop can be efficiently implemented by a server that supports only the 2518 properties and the relatively few number of dead properties that clients create these days is not the problem. It is the fact that large numbers of expensive to compute properties are currently being defined, both in the protocol and as custom properties, that raises the concern. Having clients "discover and adjust" is not a good technique for achieving interoperability. The fact that DAV4J ignores the 2518 requirement that by default a PROPFIND MUST be DAV:allprop, is a good example of the interoperability problems that arise when the protocol makes a poor choice of exposing functionality. A client writer would need to be aware of the various "variations from the protocol" that have been chosen by various server implementors (e.g. returning "errors" on requests that the server feels are "too expensive"), and then try a sequence of alternative requests to get the desired result. Cheers, Geoff -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Sunday, May 06, 2001 9:17 AM To: w3c-dist-auth@w3c.org Subject: Re: Issue: ALLPROP_AND_COMPUTED Greg (and Jason seems to agree): Personally, I would recommend leaving it just as it is, with a note in the spec that the server can return error in certain cases. The client should interpret that as "whoops. we asked too much" and back off to a nicer algorithm. (and better yet, just start with the nice one) I also agree, but think the default should probably be changed to depth 0. Althought clients are free to deal with that too. DAV4J's Resource.getProperties() method uses a depth 0 default in its marshalling. It doesn't really matter what the protocol specifies. Clients can use what they want. allprop is just one option for getting properties. If servers are slow or fail on it, client writers will discover this and adjust accordingly. I don't think there's any need for the protocol to try to solve it any further. Some servers can return all the properties pretty fast. As slow as the DAV4J server is on most operations, it can return all the properties pretty fast since they're all in a single XML document. Depth infinity isn't that slow either, but their might be a lot of files returned! From w3c-dist-auth-request@w3.org Mon May 7 05:25:08 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04894 for ; Mon, 7 May 2001 05:25:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA18762; Mon, 7 May 2001 05:21:57 -0400 (EDT) Resent-Date: Mon, 7 May 2001 05:21:57 -0400 (EDT) Resent-Message-Id: <200105070921.FAA18762@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA18733 for ; Mon, 7 May 2001 05:21:39 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA16172 for ; Mon, 7 May 2001 05:21:40 -0400 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id CAA04866; Mon, 7 May 2001 02:22:38 -0700 (PDT) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id CAA00513; Mon, 7 May 2001 02:18:56 -0700 (PDT) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id LAA06466; Mon, 7 May 2001 11:13:22 +0200 (MET DST) Message-ID: <3AF6688A.35505819@adobe.com> Date: Mon, 07 May 2001 11:19:06 +0200 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4928 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, > But I question whether it's needed. Since not all servers return all > RFC2518 properties in response to allprop (e.g. not returning > DAV:lockdiscovery), and since obviously clients and servers across the globe > aren't already broken, is any client relying on allprop for getting all > properties? GoLive 5 uses "PROPFIND ALLPROP" (with depth 0/1) for retrieving properties of resources on the server; we are *not* using "ALLPROP" with "depth infinity" (but - btw - we are using "PROPFIND PROP" with "depth infinity"). It should be not a big deal for us to replace our "PROPFIND ALLPROP" with "PROPFIND PROP" in future releases. Therefore - regarding future releases - it's not a big problem for us if "ALLPROP" does not longer exist in the spec. On the other hand: GoLive 5 is using "ALLPROP" so - for compatiblity reasons - its *very* important that existing servers keep there support for "ALLPROP" for a while; GoLive 5 relies on "ALLPROP" and is *not* able to work with a server which does not support "ALLPROP". Best, Hartmut From w3c-dist-auth-request@w3.org Mon May 7 17:44:27 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23145 for ; Mon, 7 May 2001 17:44:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21954; Mon, 7 May 2001 16:37:18 -0400 (EDT) Resent-Date: Mon, 7 May 2001 16:37:18 -0400 (EDT) Resent-Message-Id: <200105072037.QAA21954@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA21934 for ; Mon, 7 May 2001 16:37:13 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA13448 for ; Mon, 7 May 2001 16:37:13 -0400 Received: (qmail 19297 invoked by uid 0); 7 May 2001 20:36:31 -0000 Received: from pd950c287.dip.t-dialin.net (HELO lisa) (217.80.194.135) by mail.gmx.net (mp004-rz3) with SMTP; 7 May 2001 20:36:31 -0000 From: "Julian Reschke" To: Date: Mon, 7 May 2001 22:36:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B102EF4D98@SUS-MA1IT01> Subject: data-typed properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4929 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, writing a WebDAV server, we found that it's a useful feature a) for the server to pass information about a property's datatype to the client and b) for the client -- when creating new properties -- to pass data type information to the server. (something similar is currently done by MS Webfolder, IIS and MS's sharepoint server -- but Microsoft's solution isn't properly documented and relies on outdated technlogy (XML data). I'm therefore corrently writing up a proposal how to do this in a well-defined and open way (while implementing at the same time), based on XML Schema Part 2 (datatypes) and possibly SOAP. If somebody else is working on a similar extension, it would be nice to exhange ideas. Julian From w3c-dist-auth-request@w3.org Wed May 9 12:53:12 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16623 for ; Wed, 9 May 2001 12:53:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA07440; Wed, 9 May 2001 12:47:10 -0400 (EDT) Resent-Date: Wed, 9 May 2001 12:47:10 -0400 (EDT) Resent-Message-Id: <200105091647.MAA07440@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA07420 for ; Wed, 9 May 2001 12:47:04 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA13894 for ; Wed, 9 May 2001 12:47:04 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA29442; Wed, 9 May 2001 09:46:57 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Cc: "Lisa Dusseault" Date: Wed, 9 May 2001 09:45:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4930 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hmm, not sure why this message was caught by the spam filter; for some reason Lisa was bumped from the list. I've added lisa@xythos.com to the accept2 list -- Lisa,let me know if I should re-add you to the list as well. - Jim -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Wednesday, May 09, 2001 9:38 AM To: Dan Brotsky; Sridhar Erukulla Cc: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org Subject: [Moderator Action] RE: File creation date, version creation date, and getlastmodified This sounds so similar to the "structured documents" that were discussed on this list ages ago. As I recall, one of the scenarios for having a resource that was a cross between a collection and a document was to gather a web page together with its images in one place. In some ways, it's treated like a single document -- the browsing client should just see the resultant web page when they try to view the resource. Yaron's brief proposal: http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JanMar/0220.html Judith's elaboration: http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JanMar/0239.html Jim's issues and clarifications: http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JanMar/0301.html The draft "draft-hopmann-collection-props-00.txt" had a property related to this, "isstructureddocument". I replied to some questions about the intent of this property: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0028.html I'm not at all sure that the model that would work for web pages (which have multiple independent pieces) would work for your assets, but it's possible that some of the same mechanisms could apply. I think there is some common ground: - A casually browsing client usually needs to see a "structured document" or "asset" as a single resource, with a dominant view. They may not need to understand anything about the interior structure. - When dealing with casually browsing clients or old clients, the server can pretend that the resource is a simple resource with a content-type of html, ms-word, pdf or whatever the content-type of the "default" document inside the container is. - An advanced client may need to break open the container to examine or deal with the pieces, but probably not all the time. E.g. the container would be broken open when editing or changing structure (e.g. deleting pieces, deleting old versions). - While the contents of the container may be versioned, the container itself may not be (unclear). lisa > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Dan Brotsky > Sent: Thursday, May 03, 2001 11:20 AM > To: Sridhar Erukulla > Cc: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org > Subject: RE: File creation date, version creation date, and > getlastmodified > > > At 1:03 PM -0400 5/3/01, Sridhar Erukulla wrote: > >In our document management system we have two concepts, 'Object' > >and 'Document'. An 'Object' comprises of a 'Document' and all its > >properties. The function GetLastModified for a document retrieves > >when the actual document was modified where as for an object when > >the object was modified which includes the properties and > >document. > > > >We found that this distinction was critical in distinguishing the > >physical actions like library maintenance, caching etc. vs. the > >business operations like using workflow. > > Adobe's InScope server does a similar thing distinguishing "Assets" > from "Versions" (which are the content and dead property snapshots of > the asset); assets as a resource have content and properties (the > latest version) but also properties that the version doesn't have. > Many of these "non-content" properties are about the workflow. > > Our approach (prior to delta-V) has been to establish a conventional > relationship between the asset URLs and the version URLs; in fact > assets are (non-DAV-compliant) collections of their versions. > > With delta-V stabilizing we are hoping, going forward, to use delta-V > mechanisms to connect assets and their versions. > > dan > -- > Daniel Brotsky, Adobe Systems > tel 408-536-4150, pager 877-704-4062 > 2-way pager email: From w3c-dist-auth-request@w3.org Wed May 9 14:42:04 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20996 for ; Wed, 9 May 2001 14:42:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15832; Wed, 9 May 2001 14:34:00 -0400 (EDT) Resent-Date: Wed, 9 May 2001 14:34:00 -0400 (EDT) Resent-Message-Id: <200105091834.OAA15832@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA15809 for ; Wed, 9 May 2001 14:33:55 -0400 (EDT) Received: from conductor.synapse.net (conductor.synapse.net [199.84.54.18]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA24436 for ; Wed, 9 May 2001 14:33:55 -0400 Received: (qmail 3880 invoked from network); 9 May 2001 18:33:44 -0000 Received: from ppp-44-52.ott.aei.net (HELO sri01) (216.221.44.52) by conductor.synapse.net with SMTP; 9 May 2001 18:33:44 -0000 From: "Sridhar Erukulla" To: "'Lisa Dusseault'" , "'Dan Brotsky'" , "'Sridhar Erukulla'" Cc: , Date: Wed, 9 May 2001 14:34:12 -0400 Keywords: Official Message-ID: <000601c0d8b6$a5445420$37c9c8c8@ByteQuest.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: Disposition-Notification-To: "Sridhar Erukulla" Subject: RE: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4932 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, You put the words that I think this discussion boils down to: > - While the contents of the container may be versioned, the container > itself may not be (unclear). > > lisa Putting the question back, what does getlastmodifed refer to? the container or the contents? Sridhar From w3c-dist-auth-request@w3.org Wed May 9 14:44:20 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21028 for ; Wed, 9 May 2001 14:44:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15787; Wed, 9 May 2001 14:33:19 -0400 (EDT) Resent-Date: Wed, 9 May 2001 14:33:19 -0400 (EDT) Resent-Message-Id: <200105091833.OAA15787@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA15632 for ; Wed, 9 May 2001 14:33:08 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA24328 for ; Wed, 9 May 2001 14:33:08 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA18321; Wed, 9 May 2001 11:33:11 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Cc: , "Eric Van der Vlist" Date: Wed, 9 May 2001 11:31:22 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: =?iso-8859-1?Q?RFC_2518_..._in_French!_=28Version_fran=E7aise_de_RFC_25?= =?iso-8859-1?Q?18=29?= Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4931 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks to the translation effort of Jean-Jacques Thomasson , and Eric van der Vlist , the WebDAV Distributed Authoring Protocol specification is now available in a French language translation, at: http://www.ics.uci.edu/pub/ietf/webdav/protocol/rfc2518.fr.html I am extremely grateful for this translation -- my mind boggles at the amount of work that must have been involved in the translation effort. Protocol specifications are hard enough to read when you're a native English speaker, so I can only imagine how painful it must be to try and understand an RFC when English is a second or third language. This translation makes it much easier for French speaking people to understand the WebDAV Distributed Authoring Protocol, and I hope this leads to more implementation and use of WebDAV in the French speaking community. - Jim From w3c-dist-auth-request@w3.org Wed May 9 19:16:40 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28849 for ; Wed, 9 May 2001 19:16:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA05442; Wed, 9 May 2001 19:13:12 -0400 (EDT) Resent-Date: Wed, 9 May 2001 19:13:12 -0400 (EDT) Resent-Message-Id: <200105092313.TAA05442@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA05402 for ; Wed, 9 May 2001 19:13:06 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA19828; Wed, 9 May 2001 19:13:06 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA15611; Wed, 9 May 2001 16:13:05 -0700 (PDT) From: "Jim Whitehead" To: "Lisa Dusseault" , "DeltaV" , Date: Wed, 9 May 2001 16:11:13 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Summary: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4935 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Let me see if I can summarize points of consensus I saw in this thread. Problem Statement ----------------- The initial problem statement appears to be: In RFC 2518, the definition of the getlastmodified property is intentionally ambiguous on the issue of whether property changes cause the getlastmodified property to be updated. As well, the underlying definition of the Last-Modified header in HTTP is also ambiguous. The implied (but never explicitly stated) problem is that client implementors might want getlastmodified to have more precise semantics. In particular, it might be useful to know (a) *if* any (dead) property was changed (b) *when* any (dead) property was changed. (c) *when* the body (and only the body) was changed A client can observe the value of getetag to determine *if* the body has changed. However, no scenarios were provided to motivate this capability. Solution Space -------------- I detected no rough consensus on any solution. Assuming such a rough consensus is not developed, the likely outcome will be: - The specification of getlastmodified will remain the same. Solutions that were discussed, but which did not receive widespread support: - Introduce an "propetag" property that contained an etag for all (dead) property content. - Introduce a "proplastmodified" property that contained the last modified date for (dead) property modifications. - Introduce a "lasttouched" property that contained the timestamp of the last time the resource (either body or properties) was updated - Jim From w3c-dist-auth-request@w3.org Wed May 9 19:17:58 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28864 for ; Wed, 9 May 2001 19:17:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA05373; Wed, 9 May 2001 19:10:55 -0400 (EDT) Resent-Date: Wed, 9 May 2001 19:10:55 -0400 (EDT) Resent-Message-Id: <200105092310.TAA05373@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA05346 for ; Wed, 9 May 2001 19:10:48 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA19705 for ; Wed, 9 May 2001 19:10:48 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f49NAXj03736; Wed, 9 May 2001 16:10:33 -0700 (PDT) From: "Lisa Dusseault" To: "Jim Whitehead" , "WebDAV WG" Date: Wed, 9 May 2001 16:09:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: Summary: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4934 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I continue to believe that rough consensus exists to change the default > behavior of PROPFIND away from the current specification. The > default Depth > value should be 0, not infinity (or an error should be reported). I hope you mean default depth=0 for PROPFIND, not for MOVE and COPY. (PROPPATCH should default to the same as PROPFIND though). lisa From w3c-dist-auth-request@w3.org Wed May 9 19:24:52 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28993 for ; Wed, 9 May 2001 19:24:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA06484; Wed, 9 May 2001 19:23:03 -0400 (EDT) Resent-Date: Wed, 9 May 2001 19:23:03 -0400 (EDT) Resent-Message-Id: <200105092323.TAA06484@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA06464 for ; Wed, 9 May 2001 19:22:58 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA20800 for ; Wed, 9 May 2001 19:22:58 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA21289 for ; Wed, 9 May 2001 16:22:57 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 9 May 2001 16:21:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Issue: LIVE_AND_NON_LIVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4937 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is a seemingly simple issue: The specification should explicitly state which properties are live, and which are non-live. It was initially raised by Judy Slein: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0025.html - Jim From w3c-dist-auth-request@w3.org Wed May 9 19:30:53 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29088 for ; Wed, 9 May 2001 19:30:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA06832; Wed, 9 May 2001 19:29:29 -0400 (EDT) Resent-Date: Wed, 9 May 2001 19:29:29 -0400 (EDT) Resent-Message-Id: <200105092329.TAA06832@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA06774 for ; Wed, 9 May 2001 19:29:20 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA21312; Wed, 9 May 2001 19:29:20 -0400 Received: from gmgw01.oraclecorp.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail4.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f49NOFD12678; Wed, 9 May 2001 16:24:15 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-33.us.oracle.com [130.35.171.33]) by gmgw01.oraclecorp.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f49NSfv10170; Wed, 9 May 2001 16:28:41 -0700 (PDT) From: "Eric Sedlar" To: "DeltaV" , Date: Wed, 9 May 2001 16:32:56 -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.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: Summary: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4938 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I believe that one or more of the possible solutions to this could receive a consensus after a face-to-face discussion. I suggest bringing this one up again at the next IETF. I for one would be happy with either "proplastmodified" or "lasttouched", along with disambiguating "getlastmodified". --Eric > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, May 09, 2001 4:11 PM > To: Lisa Dusseault; DeltaV; w3c-dist-auth@w3.org > Subject: Summary: File creation date, version creation date, and > getlastmodified > > > Let me see if I can summarize points of consensus I saw in this thread. > > Problem Statement > ----------------- > > The initial problem statement appears to be: > > In RFC 2518, the definition of the getlastmodified property is > intentionally > ambiguous on the issue of whether property changes cause the > getlastmodified > property to be updated. As well, the underlying definition of the > Last-Modified header in HTTP is also ambiguous. > > The implied (but never explicitly stated) problem is that client > implementors might want getlastmodified to have more precise > semantics. In > particular, it might be useful to know > (a) *if* any (dead) property was changed > (b) *when* any (dead) property was changed. > (c) *when* the body (and only the body) was changed > > A client can observe the value of getetag to determine *if* the body has > changed. > > However, no scenarios were provided to motivate this capability. > > Solution Space > -------------- > > I detected no rough consensus on any solution. > > Assuming such a rough consensus is not developed, the likely outcome will > be: > > - The specification of getlastmodified will remain the same. > > Solutions that were discussed, but which did not receive > widespread support: > > - Introduce an "propetag" property that contained an etag for all (dead) > property content. > - Introduce a "proplastmodified" property that contained the last modified > date for (dead) property modifications. > - Introduce a "lasttouched" property that contained the timestamp of the > last time the resource (either body or properties) was updated > > - Jim > > From w3c-dist-auth-request@w3.org Wed May 9 19:31:30 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29121 for ; Wed, 9 May 2001 19:31:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA06864; Wed, 9 May 2001 19:29:35 -0400 (EDT) Resent-Date: Wed, 9 May 2001 19:29:35 -0400 (EDT) Resent-Message-Id: <200105092329.TAA06864@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA06791 for ; Wed, 9 May 2001 19:29:22 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA21315 for ; Wed, 9 May 2001 19:29:22 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA24652; Wed, 9 May 2001 16:29:19 -0700 (PDT) From: "Jim Whitehead" To: "Julian Reschke" , "WebDAV WG" Date: Wed, 9 May 2001 16:27:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4939 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Julian, Geoff, Since it appears there is some agreement on this issue, could one of you please write up, in specification language, your proposed modification to the specification to resolve this issue? - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Thursday, April 26, 2001 9:15 AM > To: WebDAV WG > Subject: AW: Issue: XML_LANG_CLARIFY > > > > Von: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Clemm, Geoff > > Gesendet: Donnerstag, 26. April 2001 17:59 > > An: WebDAV WG > > Betreff: RE: Issue: XML_LANG_CLARIFY > > > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > 1) If you don't validate (and although the RFC shows DTD > > fragments, they > > can't be used for validation), any attribute can appear on > any element. > > It's > > up the RFC to define what this means. > > > > The RFC is equally capable of declaring that an attribute on a > > paricular element type is syntactically illegal. Whether or not the > > XML "DTD validates" is not especially relevant or interesting (we have > > many syntactic constraints in the protocol that cannot be expressed > > conveniently in DTD form). > > I agree. I think this is what I said as well :-) > > > 2) The current RFC current defines that xml:lang is to be > persisted, no > > matter whether it appears on the property element or an ancestor. > > > > To be precise, RFC 2518 states: > > > > Language tagging information in the property's value (in the > > "xml:lang" attribute, if present) MUST be persistently stored along > > with the property, and MUST be subsequently retrievable using > > PROPFIND. > > > > This statement does not specify whether an xml:lang attribute > > can appear in the DAV:prop element, or just in the actual property > > value elements. In other words, a statement of the form "no > > attributes can be placed on a DAV:prop element" would not conflict > > with this language in RFC 2518. > > Yes. The current wording isn't very precise because if refer's to the > property's value without having defined what the property value > actually is. > However, I would claim that if intent was to say that xml:lang should be > persisted only for child elements of the property element, this would have > been redundant anyway (I thought we agree that attributes of > child elements > of the property element need to be persisted anyway, right?). > > > 3) Actually, I would prefer to state that *any* attribute > can appear on > > the > > property element, and that they all should be persisted. It makes the > > spec > > easier and would conform with Canonical XML. > > > > Just to make sure we aren't talking past each other, I have very > > different opinions on what we should allow on the DAV:prop element (I > > prefer no attributes, but can live with "only xml:lang" or "only > > attributes in the xml namespace"), and what we allow on the property > > elements, e.g. DAV:displayname, DAV:getcontentlength, etc. (I prefer > > all attributes allowed, and must be maintained by the server). > > > So when you say "any attribute can appear on a property element", if > > you are referring to elements like "DAV:displayname", I agree with > > you, but if you are referring to the DAV:prop element, I disagree. > > And the spec is free to disallow attributes on DAV:prop but allow > > attributes on elements like DAV:displayname. > > Seems that after all we agree :-) > > From w3c-dist-auth-request@w3.org Wed May 9 19:44:51 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29379 for ; Wed, 9 May 2001 19:44:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA07551; Wed, 9 May 2001 19:43:07 -0400 (EDT) Resent-Date: Wed, 9 May 2001 19:43:07 -0400 (EDT) Resent-Message-Id: <200105092343.TAA07551@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA07531 for ; Wed, 9 May 2001 19:43:02 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA22328 for ; Wed, 9 May 2001 19:43:00 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f49Ngoj05048; Wed, 9 May 2001 16:42:50 -0700 (PDT) From: "Lisa Dusseault" To: "Jim Whitehead" , "WebDAV WG" Date: Wed, 9 May 2001 16:41:35 -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) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: Issue: LIVE_AND_NON_LIVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4940 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm not sure I agree with Judy's original post that "Other live DAV properties (supportedlock, getetag) should be copied / moved live if possible, but should not be copied / moved dead." It seems to me that there are at least two kinds of live properties, the distinction between which has caused confusion in the past (at least to me). There are live properties which are typically read-only and calculated (or only altered indirectly), such as lockdiscovery, supportedlocks, getetag, creationdate, getlastmodified, resourcetype. These should usually be recalculated as the result of a MOVE or COPY so one might as well say they are not moved or copied. There can also live properties which are writable and which have an effect on the server either immediately or at a later date (if they didn't have an effect, they'd just be dead). This category includes auto-checkout and auto-checkin from DeltaV. If they are writable, they should usually be "written" when the resource is copied or moved. There are also dead properties which are not calculated by the server, nor is their value used by the server. So the distinction of interest for MOVE/COPY is seemingly whether the property is in theory writable, not whether it's live/non-live. Can we get some more context about what the "issue" is? is it only for purposes of MOVE/COPY that the spec should distinguish whether between live and non-live, or are there other reasons to distinguish? Is the goal to be able to define a way to identify which properties should be copied or moved? lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, May 09, 2001 4:21 PM > To: WebDAV WG > Subject: Issue: LIVE_AND_NON_LIVE > > > This is a seemingly simple issue: > > The specification should explicitly state which properties are live, and > which are non-live. > > It was initially raised by Judy Slein: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0025.html > > - Jim From w3c-dist-auth-request@w3.org Wed May 9 19:54:09 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29493 for ; Wed, 9 May 2001 19:54:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA07871; Wed, 9 May 2001 19:52:36 -0400 (EDT) Resent-Date: Wed, 9 May 2001 19:52:36 -0400 (EDT) Resent-Message-Id: <200105092352.TAA07871@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA07851 for ; Wed, 9 May 2001 19:52:31 -0400 (EDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA23139 for ; Wed, 9 May 2001 19:52:29 -0400 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f49NplP00943 for ; Wed, 9 May 2001 16:51:47 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f49Npkp00862; Wed, 9 May 2001 16:51:46 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f49NoVc01404; Wed, 9 May 2001 16:50:31 -0700 Date: Wed, 9 May 2001 16:50:31 -0700 From: "Roy T. Fielding" To: Jim Whitehead Cc: WebDAV WG Message-ID: <20010509165031.A1373@waka.ebuilt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: ; from ejw@cse.ucsc.edu on Wed, May 09, 2001 at 04:21:05PM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: Issue: LIVE_AND_NON_LIVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4941 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > The specification should explicitly state which properties are live, and > which are non-live. It would be better to specify which ones cannot be live (client must be capable of writing them) and which ones cannot be dead (client is never allowed to write them), since that is the interoperability concern. I'm not sure if that covers the whole set (i.e., some may depend on the way that a resource is implemented). Oh, and the issue should be labelled LIVE_AND_LET_DIE, because webdav just isn't funny enough yet to reach draft standard status. ....Roy From w3c-dist-auth-request@w3.org Wed May 9 20:09:17 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29644 for ; Wed, 9 May 2001 20:09:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA05994; Wed, 9 May 2001 19:16:04 -0400 (EDT) Resent-Date: Wed, 9 May 2001 19:16:04 -0400 (EDT) Resent-Message-Id: <200105092316.TAA05994@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA05695 for ; Wed, 9 May 2001 19:14:52 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA20062 for ; Wed, 9 May 2001 19:14:51 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA16575; Wed, 9 May 2001 16:14:49 -0700 (PDT) From: "Jim Whitehead" To: "Lisa Dusseault" , "WebDAV WG" Date: Wed, 9 May 2001 16:12:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Summary: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4936 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > I continue to believe that rough consensus exists to change the default > > behavior of PROPFIND away from the current specification. The > > default Depth > > value should be 0, not infinity (or an error should be reported). > > I hope you mean default depth=0 for PROPFIND, not for MOVE and COPY. > (PROPPATCH should default to the same as PROPFIND though). Yes, my comments apply solely to PROPFIND. You are right, though, default Depth values for other methods should also be revisited. - Jim From w3c-dist-auth-request@w3.org Wed May 9 20:31:05 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29906 for ; Wed, 9 May 2001 20:31:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA01933; Wed, 9 May 2001 18:38:41 -0400 (EDT) Resent-Date: Wed, 9 May 2001 18:38:41 -0400 (EDT) Resent-Message-Id: <200105092238.SAA01933@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA01913 for ; Wed, 9 May 2001 18:38:36 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA16351 for ; Wed, 9 May 2001 18:38:36 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id PAA29104 for ; Wed, 9 May 2001 15:38:34 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 9 May 2001 15:36:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3AF6688A.35505819@adobe.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Summary: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4933 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Let me see if I can summarize points of agreement from the recent discussion concerning PROPFIND ALLPROP. If you disagree with this summary, please send a message to the list (a) explaining the difference, and (b) describing what *you* believe is the rough consensus. Problem Statement ----------------- PROPFIND ALLPROP Depth infinity places a significant processing load on some server implementations. Apache mod_dav provides an option limiting PROPFIND ALLPROP Depth infinity for just "core" (RFC 2518-defined) properties. The DeltaV specification introduces several new properties that (a) are expensive to compute, and (b) not capable of interpretation by non-DeltaV clients. It is generally believed that PROPFIND ALLPROP Depth 1 is less likely to incur a large processing load on the server than PROPFIND ALLPROP Depth infinity. However, it is possible to have a deep hierarchy with few resources, and a single collection with many resources, and hence there is no guarantee that PROPFIND ALLPROP Depth 1 will be less computationally expensive than PROPFIND ALLPROP Depth infinity. Thus, if the goal is: "reduce the likelihood that a client request will result in a computationally expensive server operation", then PROPFIND ALLPROP Depth infinity and Depth 1 will both need to be addressed. Both the DeltaV and the Access Control specifications limit the properties returned by PROPFIND ALLPROP (of any depth). This effectively changes the semantics of PROPFIND ALLPROP. Client implementors involved in this discussion indicate that they have dependencies on PROPFIND ALLPROP at Depth 0/1. To date, there have been no reported cases of client dependencies on PROPFIND ALLPROP Depth infinity. At present, RFC 2518 states two default behaviors for PROPFIND: (a) a request without a Depth header should be treated as if it is Depth infinity. (b) a request without a body should be treated as a PROPFIND ALLPROP To date, there have been no reported cases of clients depending on this default behavior. Solution Space -------------- I continue to believe that rough consensus exists to change the default behavior of PROPFIND away from the current specification. The default Depth value should be 0, not infinity (or an error should be reported). The default computation should be PROPNAME, not ALLPROP (or an error should be reported). I detected no consensus on how to address the PROPFIND ALLPROP Depth 1/infinity issue. Assuming this group does not come to consensus, I believe the following will happen: - The revision of 2518 will contain an implementation note concerning the effects of PROPFIND ALLPROP at Depth 1/infinity - The DeltaV and ACL specifications will contain language prohibiting the return of certain properties (i.e., properties defined in each specification) for any PROPFIND ALLPROP. - Server implementations (such as mod_dav) will continue to have configuration options limiting PROPFIND ALLPROP Depth infinity. - Jim From w3c-dist-auth-request@w3.org Thu May 10 03:47:22 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20695 for ; Thu, 10 May 2001 03:47:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA22947; Thu, 10 May 2001 03:19:58 -0400 (EDT) Resent-Date: Thu, 10 May 2001 03:19:58 -0400 (EDT) Resent-Message-Id: <200105100719.DAA22947@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA22921 for ; Thu, 10 May 2001 03:19:39 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA23239 for ; Thu, 10 May 2001 03:19:39 -0400 Received: (qmail 643 invoked by uid 0); 10 May 2001 07:18:57 -0000 Received: from pd950c2c8.dip.t-dialin.net (HELO lisa) (217.80.194.200) by mail.gmx.net (mail01) with SMTP; 10 May 2001 07:18:57 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "WebDAV WG" Date: Thu, 10 May 2001 09:18:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Issue: LIVE_AND_NON_LIVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4942 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Thursday, May 10, 2001 1:21 AM > To: WebDAV WG > Subject: Issue: LIVE_AND_NON_LIVE > > > This is a seemingly simple issue: > > The specification should explicitly state which properties are live, and > which are non-live. ...and which of the live properties are "protected", right? From w3c-dist-auth-request@w3.org Thu May 10 05:50:01 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21767 for ; Thu, 10 May 2001 05:50:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA26202; Thu, 10 May 2001 05:12:03 -0400 (EDT) Resent-Date: Thu, 10 May 2001 05:12:03 -0400 (EDT) Resent-Message-Id: <200105100912.FAA26202@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA26174 for ; Thu, 10 May 2001 05:11:57 -0400 (EDT) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA00515 for ; Thu, 10 May 2001 05:11:57 -0400 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id CAA12159; Thu, 10 May 2001 02:09:29 -0700 (PDT) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id CAA07163; Thu, 10 May 2001 02:04:17 -0700 (PDT) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id KAA21478; Thu, 10 May 2001 10:58:41 +0200 (MET DST) Message-ID: <3AFA599A.2F73EBEF@adobe.com> Date: Thu, 10 May 2001 11:04:26 +0200 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jim Whitehead CC: WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Summary: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4943 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > PROPFIND ALLPROP Depth infinity places a significant processing load on some > server implementations. Apache mod_dav provides an option limiting PROPFIND > ALLPROP Depth infinity for just "core" (RFC 2518-defined) properties. If you mean the mod_dav "DAVDepthInfinity" configuration flag here, this applies - as far as I know - to all PROPFIND Depth infinity requests, not only to PROPFIND ALLPROP Depth infinity. So, if this flag is set to "off" (the default value), the client is not allowed to send a PROPFIND PROP Depth infinity. Greg, will this change in future releases of mod_dav? So, will the "DAVDepthInfinity" configuration only apply to ALLPROP? Best, Hartmut From w3c-dist-auth-request@w3.org Thu May 10 09:51:41 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26794 for ; Thu, 10 May 2001 09:51:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA08554; Thu, 10 May 2001 09:48:09 -0400 (EDT) Resent-Date: Thu, 10 May 2001 09:48:09 -0400 (EDT) Resent-Message-Id: <200105101348.JAA08554@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA08518 for ; Thu, 10 May 2001 09:47:59 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA24967 for ; Thu, 10 May 2001 09:47:55 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id OAA151600 for ; Thu, 10 May 2001 14:31:15 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id OAA85272 for ; Thu, 10 May 2001 14:46:44 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A48.004BAF75 ; Thu, 10 May 2001 14:46:41 +0100 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <80256A48.004BAD42.00@d06mta07.portsmouth.uk.ibm.com> Date: Thu, 10 May 2001 14:43:02 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Pedantic Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4944 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: Just to be pedantic, in versioning-15 section 14.2 "A collection has all the properties of a version." Taken out of context this is misleading. Section 14.3 "In particular, a working [collection] resource is initialized to contain ... of the checked out [collection] version." I suggest adding the word 'collection' twice, as indicated above. Section 14.3.1 Should this be marked a required property? Tim From w3c-dist-auth-request@w3.org Thu May 10 13:59:38 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05096 for ; Thu, 10 May 2001 13:59:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA27568; Thu, 10 May 2001 13:48:14 -0400 (EDT) Resent-Date: Thu, 10 May 2001 13:48:14 -0400 (EDT) Resent-Message-Id: <200105101748.NAA27568@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA27547 for ; Thu, 10 May 2001 13:48:05 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA19144 for ; Thu, 10 May 2001 13:48:05 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA21936 for ; Thu, 10 May 2001 10:48:00 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 10 May 2001 10:46:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: =?us-ascii?Q?Re:_RFC_2518_..._in_French!_=28Version_francaise_de_RFC_25?= =?us-ascii?Q?18=29?= Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4946 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Eric van der Vlist [mailto:vdv@dyomedea.com] Sent: Thursday, May 10, 2001 1:27 AM To: Jim Whitehead Cc: WebDAV WG; jjthomasson@nagora.com Subject: [Moderator Action] Re: RFC 2518 ... in French! (Version francaise de RFC 2518) Jim Whitehead wrote: > > Thanks to the translation effort of Jean-Jacques Thomasson > , and > Eric van der Vlist , the WebDAV Distributed Authoring > Protocol specification is now available in a French language translation, > at: > > http://www.ics.uci.edu/pub/ietf/webdav/protocol/rfc2518.fr.html The translation is now also available at: http://xmlfr.org/ietf/rfc2518.html And I'd like to highlight the work done by Jean-Jacques Thomasson who did the actual translation (hosting it is, by comparison, a piece of cake)! Thanks for the thanks! Eric > I am extremely grateful for this translation -- my mind boggles at the > amount of work that must have been involved in the translation effort. > > Protocol specifications are hard enough to read when you're a native English > speaker, so I can only imagine how painful it must be to try and understand > an RFC when English is a second or third language. This translation makes > it much easier for French speaking people to understand the WebDAV > Distributed Authoring Protocol, and I hope this leads to more implementation > and use of WebDAV in the French speaking community. > > - Jim -- See you in Berlin for XML Europe 2001: http://gca.org/attend/2001_conferences/europe_2001/tutorialsmon.htm ------------------------------------------------------------------------ Eric van der Vlist http://xmlfr.org http://dyomedea.com http://xsltunit.org http://4xt.org http://examplotron.org ------------------------------------------------------------------------ From w3c-dist-auth-request@w3.org Thu May 10 14:01:40 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05192 for ; Thu, 10 May 2001 14:01:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA27480; Thu, 10 May 2001 13:46:53 -0400 (EDT) Resent-Date: Thu, 10 May 2001 13:46:53 -0400 (EDT) Resent-Message-Id: <200105101746.NAA27480@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA27426 for ; Thu, 10 May 2001 13:46:37 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA19031; Thu, 10 May 2001 13:46:37 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA21038; Thu, 10 May 2001 10:46:30 -0700 (PDT) From: "Jim Whitehead" To: "Eric Sedlar" , "DeltaV" , Date: Thu, 10 May 2001 10:44:41 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Summary: File creation date, version creation date, and getlastmodified Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4945 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Eric Sedlar writes: > I believe that one or more of the possible solutions to this could > receive a consensus after a face-to-face discussion. I suggest bringing > this one up again at the next IETF. I for one would be happy with either > "proplastmodified" or "lasttouched", along with disambiguating > "getlastmodified". Since the mailing list is the final arbiter of consensus, why not resolve the issue on the list? Many issues in other IETF standards get resolved this way... One thing that could help move this issue forward is for someone to post a message to the list, in specification langiuage, giving a concrete proposal. I haven't seen one yet... - Jim From w3c-dist-auth-request@w3.org Thu May 10 17:14:06 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08434 for ; Thu, 10 May 2001 17:14:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA04499; Thu, 10 May 2001 15:02:21 -0400 (EDT) Resent-Date: Thu, 10 May 2001 15:02:21 -0400 (EDT) Resent-Message-Id: <200105101902.PAA04499@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA04479 for ; Thu, 10 May 2001 15:02:14 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA27576 for ; Thu, 10 May 2001 15:02:14 -0400 Received: (qmail 30974 invoked by uid 0); 10 May 2001 19:01:34 -0000 Received: from p3ee24614.dip.t-dialin.net (HELO lisa) (62.226.70.20) by mail.gmx.net (mail05) with SMTP; 10 May 2001 19:01:34 -0000 From: "Julian Reschke" To: "WebDAV WG" Date: Thu, 10 May 2001 21:01:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C0D994.64999D70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4947 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C0D994.64999D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, attached is a an attempt to define a way to marshall datatype information for WebDAV properties in terms of XML Schema (part 2). (the archive contains an HTML version and an XML version conforming to the RFC2629 DTD). Feedback appreciated. Julian ------=_NextPart_000_0000_01C0D994.64999D70 Content-Type: application/x-gzip; name="property-datatypes.tar.gz" Content-Disposition: attachment; filename="property-datatypes.tar.gz" Content-Transfer-Encoding: base64 H4sIACjk+joAA+w9aVMjR7L+in5FRb94u0yE1EICZgYMsjEwHmyuB8zOejfeh1J3CZVpdWu7uhHy xv4Xvu3ffJlZRx86uGZnvS9QxGCpuyorK+/MOhymfJC1UqGC4Y1oTUQ/5LetcZqMRZpNWyHPeDYd C9VaW/OH2Sj65jmftc7a2tuNjW/W4PPuLf0XnnToN77pdte/WXvXfbf5bqPT3YTn3bXuu+43bO1Z oz3xk6uMp4x982sqlrb7Wcj4a+DzlT87392NInYrUiWTeNfr+GseE3GQhDK+3vWkSlrv329utTre d70dFAAGzWO16w2zbLzdbk8mE3+y7ifpdbuztbXVvsM2HjQVPOztZDKLRO/AChEbJCn7LPoHe39i RsSkUDtt3WxHZdNIMGy562XiLmsHSnm9xl7j740V/N0KRZCkPANEt1mcxKLxj8be9jAB5Oc2yeNQ pJE07XiQyVvxYMMfzg5+wUZBEiXpNvsvLaPfNhh8BkmctQZ8JKPpNhuK6FZkMuBNxlPJoyZTPFYt JVI5KDVX8jexzTrr47tvAfrHThn2On1mG7/FxvgQcWoNhbweZuXHT8BjZcyvRaufCn7TAkUXMCy/ TWRIyHSXTtQgs/GlR11/zKjrX3jUcxx0xNNrGbciMQBydsVIj2CepprK9BjaXxzO9Fi3Par8g9ZX ez8cU/vaFPDVgY+6oEXUdhzQZ3bWa3NnbaZamnxd0m55JK9BkLNkDEP6QTKe0nTqKK0RSv4wya5A BwqMZhGaGKGLk3TEI/1irg7OwTd4gE0ljLY0QiDnN93HoNNPovBpyDxJTQ06Fx/2S8i8pc9XQGYO YcgyliVna2uuvnS7c01G8XgZ4kZ4SGLo8cqjkQYcG9+PRCg5GHQZZ+zvBJY+fpyYZ6FU44hPt5Eq /4AuO20y9b2dtnYT/SScgrPgfTD/QcQVuBfT1wNcU1CeXQ/cUiCiaMxD7ZnMbzXmAf3uemwiw2y4 663DK00AcGebHqPp7Xo0PfBMWQr/Qta/JpLuesYEuXaBiMF0eEanit9zoMN3QB4c15jHFnGQHa93 D3/vYZbwHCYJLfppu9rMqKAHj9tZiH/SOahpbs+gNn+ivR3OhqkYQL90EPhZEnhs/3jv8nLXI/1C XO3w5sH91RniCQi2eRmRNvHCssQM9/btfy9mR6fGjk5BaYvtOnZ3U9Na5Tl6kI30eqcimyTpDfsM fwAQ+zFN8vG9Ru2psH7y2QefXejQ9n6Wzk8CdnR6dXhxenjFDi72Plw9E6PrVIi4P82Eeik6hZqh vv4hyr4NHx3I/+Faq7n7PHM2J3zKuhDHf8m5rOzzTFwn6XS7guFRPEBHhMaVR89E96VoHt6NJZB3 m51CxDnqi7Q8+ZcgY7WNjEQob+sWq2w3yCF4D4fUxvQANIjFO71LaJ4rlgxYNpSKnYhRAsa309sZ 9xor8LnCp2ES5CMwMQy+w4hHaGxikbUOULLgSYgvqDn9WVmRMRvkUQTxkGZPHKCxyIYwgQixuZWY VNCwlyJA5kEIgr/APEKK99ZH1hKfCShBrY4KiKQA0xgDi6CZiHAossMYwjQBHim+1vPh6oZ9SFJA aPXo8OrDmyaTGhhXTT0V+GnhXqORUT71PE0yyEGGPGMJjJCadxAkTmFWKmHgy7JU9vNsHlpczZuD v3BipLOl/uhzQmIphxHv5Cgf4VSVvGMjcMlDDR7RR3z6guVjUGwRNlkqwMMG+A06J32VRAKes/7U TKOEI7JyyjI5EgYxYriM+RgFCDw8EiBhuRJsBmcFAw1EKpDToI4C4wEcEdoHMhMED8YbmVGBjjF2 8simg7jACGADIa2joXfa45IECohdVIbzDfI0RTmsDx8ANJg0DwIAAbPjGXV1fq+Uk0qRDSgrxS/t jgxbvA+MgyRQ+Rn43d7j26JvXIpuTVEuhzxMJuwAjEWQJSmo47MQVwTG1/n0Aw0WoAhsreE2kaCZ ggwZA22sWLICABiGfZtCQBuI/UTJWhSvVvffsKuyGl4mAaA3ZasI743P9mC0C2yq0A2L9FaEPum7 HWbPENqBJ6TVWARyABEnmQwIk0QcKlJ4Y+kOnBKGbC/PhgkqPjtPEwh6kgilsaHy8ThJQbm0pcT3 SWxN5BQ1LRfKL/qISBj9ANI0QjEAexIiJFAkML5SvwPNo2mkFskpoYWmGCWBuwG0kcmShowB1TzI yuiPBKAcsvOLs/MPR6cHOEoqsjyNLbYCdMU5PN95QqQaMADp5CiAFLJmvWzA8ziSI1DJEOYYgdUT gDhgFCQjPU0YEzFqzCclIv8nXRPCn6sa8TdVi4mmxInwiMsoS7Yn60ELTWSLA6zvdWXI6817ijLb ZJOhDIbWmv2aENHBaCGuhAfQSilI67VfUXn/V1Aq1vDgmwoAb+HhTJZiATHR34DXmRn3OwNktwDR W9be6pZVLSBYkCvn2Iithz8gW2vEATniaTCUt6Tw7NPF8TZr1FUebYiyFbQ93Vy1z/N+JIN2Ba22 swJP6EPIs+rHihPNCDAapjNJFyaVFNOjjREY7bdf87PfYX7GWcxHwB8Lj2zqFfEJRHMfQgbUdW1c EUKOsdoIWAIYmS8uMtX9+zUslY7bfMjnOgji3hkjCpVMRI5D3cJQqBQFPRfBgol167DAhaRJmFOD hyGse731OoQzsMq3Ukxw5mhGySg/ApsNr7dRh7UPccu1Ca7RSp/vXe1/NGb7ERCRWvCnDvXwjo/G wBqEqnKKBSB8LgZ4DOQuQp6hXhnyAEygCJ8CFURz8yEKkJ96LAE2kQCbywlggbbRYz4M8q3XezuD I0pwJvsykuDRQQSVBFPEHymF77zeuzlSCIGMEWr5m44/ngr4vdd7PwN473TvyYC2vN7W7JxN8PVw 9w5Yv87avClGETTJQW3PTbSyGJgL95XX+2cd1oV7uRgAp5jC9dYhxh8V2wtDTAQaCGdxb1fJtv0/ YL5ZRKCY11LcVoPTzqNeo/H7923/bgeCjqHsROrm3i/YvcjaA4gGxEXzwfhjANWGoBXThBsxxRgJ Qnnv5NPlldfU/2WnZ/T94vB/Ph1dHB7g98uPe8fH7otp0ViBn2efjk0L/Fb03T87OTk8PdDdT/Z+ 8XQE7p2dXx2dne4de5h+UpTcWHFxMsZoED72Md4Gwo9TSpohYQ2FDg1D7FWQHesWnc4WxJxYhtn1 fnYzQpOGGTM0h0YUXh9BCBtgMn0B8SQkXDTisbgVEWjDXw2o/9XhJUX2y6jYdVQEPEfMc4mMyVs8 nZi7uP7PJ8f2la5mgOEBjg0gGwWOQp7CU0jr8oinpZQFJ4H5ChZyNEqAUypgYCwwXoss0BFFJOJr iMbNSjCEvtsea1NVETph+6VT2ZgzlWIamLpgioy4lFImauW5KRGLKEWD2QDNlS0vdf1OByOAKs82 O+8dzz5eXZ2zQ8wpdQyPA81PglotE9kbdgGUx7Jr080RGZEKoAqkNFqBqKITDMWIUzCWxJSPwaQ1 Z26TgPeRMdOCZ5QTITVwNDQ7+hubswqPmXcbBr2kETxMHj/ADPupuJXIY0pXIbIl7RDaISunG9XM GwUa2wP2A3nHvDu17QE8EDGUEcsj6ObQ+lYXeXCtPRBNKjSZzqYEgryFbMpDsmgUt8GIY4KcA4k8 tlow7s+XHce0ojk7B8llnUqv3l+hLbHmjSnSkWzAdEDbUh4hXTPDYM3wkIozVmMRTRzBFcl8LGvA u1IvNBXYFGCFckB+LyvmbRPZIVfP4lPLqt2XZphcwLEIpibSJzNOG4VXv/pcv2pTn5JfrWY+y7xp 13pTxuaUyfq5jMARJTFJgIwHKVdWRXQxPtR2BOXhsaU0kATiDSuX01qYWaHhLRYcfLbcJnadC9uL YIz8eujqaKNcZQ48aqFxMqZcXC7XYRHf1opQD4WSKQkYyPcYq1UASbdEB6ECju7NPJgMBcBLlJLQ wVbnsBSaKGEognODyJTqb9Rcq1IZBXRPulSni4PYQhcHyWSY7+iTwM6kgjADCUwwzhhSld2V9ZrA sYwmBHbGTCLjN/AjvOXgKq4ph5cIjJAZJWB3prooZpF6wBMh1deJ6md6MroqD6ld2NRAlcgyBBlD 3lxwk+hs9L5MZGQ5aEGRXpfnA7qWACSq0+FYRC+f7RlGE7zq/ACcrVyW4QAdknEmR2BPwGolKVLC sAvww3YklCYWhUBGUYkSXlAsoO2oqQII9ebVaL3UaNlqS8loLSq2LDNf64X5ckagunI51WDcckk8 BeEA3lIAax6OgN9DDhksGiDQcmstsPoel8PeJhqQETqygENshTI5ZZzy3mhK7lxJ9KWo/DRqJG90 HnANpgS0M0kiwbHIm2pJ8tlMGNLdZm4lFv1sOXjpLgxeKr0wdulS7OKiFo5qqdf9qFyi0dMBhqYC DEVBMsfGfa6kMkWl8TgiEzGjnKA8RTDjswfM9boz1wdzVZ2soIlpAY1caS6VAibmYScPjGAywjeA cYkMRXj0pMho5SguQWmWJI/4+TdgrY6WCb4x8iYGNyMDHhD50SJIqOcyQ3V0pBkM6xZjFFu1+cU6 NHgpn980be6iozikzRMI4j1g9Ned0b9K9P5HlsexwGoj5hSguP1EUWQ534wr0MwohDgimmpJI6lC qkp0R2h7MVshG1mTMOMvKXLwIbApZZlNo2Z1MYqTjKU6P9bRaSRvRckVlUgFEIy5+FcmdyQ0qYhw WV0HzRzze3xawgr9FswGUMKkCOHH149hjM59nU/EWIZ0XCe1aKuSUV/GLk90Ioj2CByrVScUaRjc SFtNoglXHelMdQ/t952QqVef+FKfaFcNSj5x+aLBMs+44cpkR4Nq0GnrHZhXGvdWmFgEFOokj4xt 08SxJeHSCeFsgKUEloARpA21wlqVosG0S8m0usyGwj6lqdY6N2nVVi+JY3sqZZDC4/YP0BHjTr1m KWYG5QZupNo5O/ANZmJtXZkzqmb9MVvlZaPwQlPsUy5VIVkwTBJFwQdYPpkZO0frAhHTRCTKmIRD E0eqIh0ya/+ybP5oS1UUJROdNuAaDc3ZLDWjacWfGjyAugYrCA4oEdpCDmRWeu+m77J5nNcD1mej UkQ08zW2XtpKZbEqFcEgmXF6ZE9MmG1WvCkD1GwCbGnBPsusnFiBLIlqEs+Xa+0AgQxqDOaaYCWh TWvAOnUXTaZYYStp4MMLbAAQKYQ9sF6J/y40CwzxsHoJLwv9bfd5SntsGPqWdsfv4PuPicq2Gfro QZL4YH3xoVlvbV3B3LepZtO+G0XlN8dUON1md/BpEBJR9u3BtiWL3s2l66rbB6ayamanHwJp5x29 WRQy1fo+3LXa4y/1DjDRtvOJ7d/Wt/zNNa/YTqpnA6JQ3mFaTLG67xSf/2UbPC1uTgmd0OyWjQX2 GPBICWzcLlpXING7+gjmYQmXUrOC1uWi9YxcaJmsCoYVAtZde8dO8iiTLb238kUCMEJASu/R/A/n vlXlWRFAM41PS0CN8jgdMzyyLWdFCGk0K0YF8x8jVHqpYq7UlISYmIFvShxfY2c/W8Fy7+fJYRVN 86JOGfO4xPuaNC4yfS7APzJFYEpwmw/YXmtyvYI+nrP8ikIHnpXjB3gngIYYetABOQgFEp1Pqbw/ khkGyHNTCBddLjPgxUaGBQZ8dh/Dq/H+jzPe2avh/v9hSp9pMze6XfYphg5UfsBQ+jCGEH262IrW 5q4X4sdoNLDZgY2IMR6l3OJOhVbiana21rVMga9hpl3xHZd4CjtdCfuNjeuLgNulO1dt0TmQp5fE ccp6dZhOCNQWlPWBAZsg6ezM2eDXHP+5Ob7dF7ckx69si1uW4m8WxW/XD/iq97brpNBsAbcrUbPl Mso6XQ3KemwFL5XZhz5IMMfEPCxIYr1EovAgFW38NNs8cVcrorGyE8neVXUwVVrbpsJRubq104YO RAnb05rkP6oqEJTWuSn6ly/XET4k/q5mV14VdUjrHWEPpJXlfYsLopLatsWnhCTE868VkQDxw5pH epEvqtt8/bTYEoSsb9cb1NxHxcyWAZYeId6/e9/+JEp+3RDw9xVDFM/nSwyFiMiR0mizLVgdzGMi z86yyHN+6Lk0knkg+/s6UcVmKfmjLSBmPxAW8iaqyOBqmxa8LM2FV9m7YJfpG3ibRUqboeY6HbuI Vk0NgyGWSJNYuHrghDYHmO0VtfikUq8tKrM+O8r0dq0CewAy3/e5pSKDP9piry4suOdT1auxdefE o1TwcPq1HNRrIPbyQMxu/i8HYkv3/i+LxN6W9iTPbKJyFXdpdmXphQCzPaZ6UrCJl6NQD8AKN8xQ bGh3X9G9KW6T1dUBSfsIQqvIrpPgOmJpI4tWLVxvBd2AJClQbg8s5Q2TIXR2JxF1Cabcf67eNJje 3/iIUvzqGHccJrkCBLHeQ9rxRus/ph4hrYKWR6zArMNTLAeD5wKfB1Yn3rrViX0zQWQCn+Cyvt0j VOWUWbrAZnrbA82qWAxrsIfwW6U7gnBZpqkHKNr3Be5lspupG+W9C60ju8OoWLMv9n72hYgryzNg oIOMkNNGKU9xw9kbn50B8o6Zei5kC81usXlkxs19JcNWzMRZxf60iDRX6bCqHElcftIpikJ2mq03 jcouwCptae3f7osg0vTFkKNwpHqje3wTJ5PYIQCwVs31AAoSWlzK7id55toVM3jzCDnQ7u3SbA98 SA6E1OfbcRP5YgmgY/F2iyDqTXWvWn1l82MywZ3DVFLF9Ug6Nh0LUxWdXSurrY4VqggM0czBiwkY 6/PgpjgwXFv8QmlzpctyDfXVazzLa9gDXtW9tg+f71rmPN4Vabzeg4uSkyjQ0mL77b8ymrBLyyDy eIEF/kNUZG1e2i2+7vJ4qQjZo3xlEZp3km+ZyLxfKDJLgg0aJaiM0gSWodshfmdFZ3sPge1a7PJh q8bCXIsYj0HgqXrwPXrjMYIx4QgePQFHZTYzQFT/uj/oxZJjz25WQlZ3dHOZvGxZebmi7S+uHmxO AIE1YIcQGyTpK5NefMrRnZCt+Yg5B2SXHnNcezLPcKRXvj3heoPyQWRkaPnssb3eQNOpoAuEkaAd Zlr2vogsGdt7DjR0e6izeiZTo2Wu9qr2rV020ir8O09veRqyT7GkC3Wzqdf7IeVhjKHkpU8O/B5v 2TGituLVrwPB1M2X5jodXyrpizCHpy2w9EK1gRDtAUTY9A1R1XcZPfcYKiJEuwbpAq4f9s/vOxvN UrFtBa/JwGEqD0/wVpP7ztbWO3czzUrBvEcQHJIp3IN3cvxYQleqnoG+UuZzkkLK9Bn8I+Yw5JGT NJP56BFULpVPry7w3uL37YvD/dbdKGrhj7UuGgYTp6FEwYxv8jE7hvw+x9Moq4D7G9bx16oE/Ly+ fw9vKsT6IPppztMp0uv9c+l12Skdcfy30wvIpI+vtjptr7f0ZOYc+lx2asI0vdeXTz2TNN3Sds7f EWm6c0hT3oQ6jzLdL0kZm3tU84fFFPoxiehY2C9+8/7zUGYCbypsskP4+YHL32ST7cHXfZiHNmaU iPyEAWXcZAf+l7RrgKy2a8/Il6p0JfsF4Baq5NZc6haBw6uDfrSDdhd90L1utWs+6j7aYLi1teRK 2TqZ1hwFeu7Szd5PeSR5XLrndea6plLj4vpV9uOo/3FZ00se/TbiMV7eBgQRrLPZNTeLLO5zkoOg knqcfmYb7zubW8ta/yjwxszp7PVSNab3e4cnEGhs35d1dyYI+ZXo4JvrX78vZuqHwuste1tjbR3P dj2WflWJR6tE6fYaVIpFd9cUyjG2g5V6onH6Arcumvvr5gzQqF//Sit+KY9VZJbv6ByyPXgNPTG1 odsEsLCphrR9xVlYOmtkDt8Br+Utx//vAl2OZ1YozR2EWCvDy0qx/USCjom7ccQhcoWx6Cyv/gC6 VLSNqdrlTkvp2p3BaZyKMU/x9lONXZON8TY8Qg3wcLCKy1tDOh46GSZ4VVpqD2s0qSSMpWtQFWgZ 2HNYWFy5keAfHSh3ot6tjfJ+ckvkMXyK6eJMs36KdR+e8uuUj4fmLokgykNR4EYnqCMsKw/1LNRc ElaK05U7HzMlooEDh5TB8hAemcWT41IvdeJEJnza1OPgigVWqEcwF3N4o45/gV9a3P3qrpmZkUHL 0OINhEY8NrVWVdBP3AViTBe5/F973/qdRpLke7/ic/Q/ZNM6jTTLw5Jsd1uNGNMSspnRawFdt6+P PyAoSbUGiqHAbXVP/+8bEfmuynogkGd2L9XntEU9MiMjIzMjIyN+MfG8oQH4Io5IKPoNdykBYXeq 4nRIHkUE8kvGxir4i2AA+sVMOGqpJoWRwEtVqiqoq0oXPoscnuBGulYJgF3CwRVBi8gJMVg8FF2Y 5/RgGIktQ2gC4rYmdyibmWMSEWYJwhNPLsa+wJwEEaKgWy5uKErwdOqRuQIFhp9VUM8rMmbel+Cz tke4es2nQ0U60oBVnDcyhCk0XH7quLeP7vGAvk9cxxNMn87y1eih8CJFZ7HZZe1uUYQ0Y2G9dy2m oNe7l8ftVu8Da16c2A9aF2/bF61Wp33xVpXVa3b/zk4vO8ctdtLuwqzePu8yBJN63+x0mhe9dqsL 6u2vV51Wt8suO6x9fnXWbp2UodTjs+sTKIr9ct1TxV1c9thZ+7zda0Hdl0DCB1nQB6Cl2SOCrrst dnkqaIO6z5sIPsXetTqt9gV73z47s8qDd5DkFpXWab991yNK8JegxiAWCz5vdY7fwc/mL+2zNlR8 2VHlnbZ7F9iSUyyAXTU7vfbx9Vmzw66uO1eX3ZbsRlTOBngsN/KGd8by4+xeri8vOBarHKBozfLI mgULwGQg3TMEaPPowQIb4cen/IqKHenenKoaTwFBfkCNf3VKpP+vrvxpA6pfH5n+KyP/14u956+e y/xfL17s7WP+r739Tf6vb3JR/q8K5WMBdQkGJ3nTlbifZDgqcf24hPvyV/uvq3BrXmJ/bWw9q393 cnnc+3DVYvCMdT90e61zVpTvDefDIr70V3wIevVR8cELi39Vt8KHMZQbGrfxrj8FFR5P1DE7QBGX lQtSpvMLKVZaqN/OYM2Bv/jGfqksZFuEgs43s7CM+XO/PwIyKZcI7HBA4+XmFU5LkRIg8FuxrWhR FGZqQLBsI7LXUVHvwYrxfan5haSIb6RFo+RVqIOuNO+PorcLdVBfoTed+9iaeGZ/w4sb+PMHtZGt 1+hnfebdISEX7+s18Wd9EAy9htjj0t/xwhiDtxaT+exB73XlDettwtaWzSBcfA93tRm7Vv5OgXOn ptlDv6j7RC11isui/AlHxfP+Q5E9eH2QM9wtFVmNRLlSgc9Qvybs7oYA9LaS0NRr+jmrVIwm1GW6 ANiKwu11QdhvrYZhv7U+EPutdaDYG/yqzXk/4T/rArLfWhnJHpRTqL4/u/Pmj4Kzx+8fjWi/FYO0 zyRnZVx7IrjKR4yQ3ZXA7WEgWUR/K4h73o7I3LNlGnYbSFtNDVNcImpyjcAfY384pLkf/6tLsB9x qucGvqXVjYpaB7Tt1pqwbbeWB7f9anaZAritoWDwgapbuTL07NazXNizquZb/w528fgXfIIS2Kh/ 9/H4pNlrfsRuy0Ckhe8+fULDmvgWi9UlOlr1eBTarWcJMLQx7pI/mJO7yyDFckauGSoWC10rViwW uDJY7FYqWqzFX0KMrSWAwG49WyMKLBb2tDCwa+4MP6k3HgcEq6S3JkS+4Zo5TWhTNV+uBl669Ww9 6KVbz2z4Uns4rguklMRkXSilsulrgymlSWsJnFLepjSsUiwxGazU5vF6IEmpH9eISYrlrReUlC8N MVTSfCPIjbNpjKW1IGnS1LgGKE2S0LVgaWJJ0bl9H+f2JUAysYwVUTJtiV0XFubWszWAYW6tAw0T KVkVDjOxq2I4l/jmUkCXER1pDXCWSMJ68CylrK8AaIlFSETLJD1xKThKLNCM2I8samtBncQ6Hg07 mW/SSwNS1Nuu1aAS5WK6FqxELGwVsESuzT8OLRG/XQYu0TlSq1wtWwcOoqFYrQyEiGU9Bgkxvrda I94hErU2wEMqDBEPJcnx0ZAFalg0NsqIiNAf34yEObbR0GAU+oFrL83SUbPohRhIBd11wytYj0x8 BWwhmgAzcLOk9eZRqAnRj3PAJtif5AN2kBbgOqFVaXuwaJtp465nIRY0COWwbuAVmPblml1ivWbU WI9BY0XNHqbRI1lOFK5GpqAkom2sJg/JcBv/w4RBjm1LIvAUrZECtVEXOBsxMUKOWKIkZCFTpBh6 7jlEUaJXNCLQFnWFa+EQPZOKei3axrqNZJEmgHzpXh9uIV/H1wVc6NZP0ufkKE7hZj7+1w/B1efj +WYuzjEX//vPjbknwSSkQue0aDbFgBlspMIT1t3YhEarnmKyXRf6oDhxyAs/mLDTW2rfZ4DrGRav NcHnqYUjEz+PDBx4IMnIS+aoGD6Mb4JRyOUaT7GXQ9GTfSs+zAuil2Qh4IWlQuDxGut0qtrIt9Ow cO7WuaQloOA91Yq2Kg6eMXfZk0g9hn5nPDPnH2Mg6xLqBtzd/7o1YikGf2vN4psvRsYth9Q0FPxd PYZ912D2t5lKy16C0hLTWhLWwOSNwNPsA9YDYYdVrwnDjoxXK4PYYSlrQbEzbWl5YOyynQ2WWY1T ENaKdheuA0ONjsnWBKJGVv41oqgRbWuAUSMdakUcNdu2uS60NKJsTXBp9vHWCnhpJP6rAqaZY2g1 xDR5ZLAWyDQsLDdmmt3nqyOjWb29CjQaFrQWbDSyg+cHRzN02CwHlCy8L2NnkYzolTSxOuC4qKAE PK6cXjNxhKlkIh+HIcWJXB1EispJRpHKedynA45EKzNRdHK7H8WRfFathGs+ymG0UEex5dXr8Eh8 YN8CzoLCMTsqCQ/LEv9EOqHyGAUZHIAvMQR1eY8upaUV8F1kTEMsoKHUrZZUNENJgNSUdDRDqTsI 5nMmH2ARVlBCHOomFrVghCzoKAUZl7B38PI5O++HYZU1v3hVIyZBvnEM25qZP7zzHM/Om+z5/t7B T+qREUBQn96D8DUq7D/22Ku9H9mL1y/ZwU+vXsAr9AC9lCl0oCJjCHT0gBE5YEYNlAjypsTjBkqI fFOCV4V9D3ZdXr/xlo8OVHbhF9z97D1glzXEv/WavIFfaEdkOarbwsFGH/HjG5+1M6J0YxSCgNM+ ObfgATUsgTB4qRxp3xGCEMp51DYJMOHZqMsKYHGntRLUpKk/x1kLPe6ZHd6pFzjja+EPJNZk7mNh uRwDCe1W79R0rBTOeuiwEwiriyj0bgHT1QhroXLUiS1o+NNghn3Cg6nvZ6jOTaBHqH033p0/meh1 xp+p6g5ppEnbh96j2X7bP/xjEcx/Rqdt/lfZuIOe2PZd6dBt3yWPbsctWWOsGO7o7brnqlK5gcsH ksTmB3kHhEdWxm9JF3H+S7mLLuckLovEaYlQp/jUKAxKhm6CbQyoi/rqmH4gN1hKYqB+FZIupl1D ZKmUEc5fSmVQ0SAToTpyB7SZ5Yxq+Pebzv2wKMxgk9AGbZ6Jye74qsS1GRjLL0o8Aij2FrRVvUUT Nn+vpmb0hnuCJ3SraAhELsCp2HKQE4IqMsdHp2oVcfb+4DgV62iZ6fu83QNabnBABrMHWpZwv7jA HUJ34CNDHNP2yxcvWc8b3E+CUXD3wLr/WEAfmu9RuJkx8dNvJuPPzpsq/ozxADRcBHQAmgo3u+6a kWbxteE/GF8a9l8esP1XewfG0nDbH9AOwHzpJ/by9WuoRj9Ta8jcH9+MdEAN3YOHi5nfiCNN1Wt4 HwkyWOtecYoSpEgGq6GYiGA1JdwxoaUuFkLL5TCvzKLjfKrM2qBfcVHNgAHbyOj/Qhl1x1LmFc/u 3hLiuZ9bPPdziacNxbaRzo10RqVzP690loQ9wLmjexyEXfKu7YO5a+OQfeam7UOViZuxDVtEOk2u xWppmbUoMECzolaV6fsr1dU06yKkQbOeZpXxeyvVYe11OYShtdWtMnFzpVpOzFo4MqJZy0lVwCUu VYu5C5U6gbERfa02ouk6r6XNorA6hNv4FRqmDmHfqCM0I/z7r8ar2FzrvUxgj6eqIxX/ZW9vf//F j4T/8vzlixc//rgP7+8dHLza4L98iwuxL7aeFX7tnvU4jpnhMIO+K7i6gXzQiY5wup8H7F3vXFg1 +P8NdMLBLp4j77EYHArbSQP02DWLm476A7I8yCAcCvxnwwDUg4n5ojguvPcx9OLh0HyERFSeH1T2 f2IsrWK7GUO0RfRnMyx2WBZGbwwgWYxvPAzpCVWQwIAMWORVJJH9QrYzFw3ph+w3bzSC9cv/yuN0 0S31K0U6jmC9rxr1FjitLyp7+/lpPQ8QewE7ggWL+XTBkefYr3RH2e9VNYRYAtM4jPNDA+1Hek6M XIo1LjA1kIxaTwqG8rjQ1xcOrgFb1Cp6cygQYFl0H/QRVTjcq/aBrnuPKqCHRpkF/d04JKJgPT3k mn1YGfuDWRAGt/PKIBgjzfMix4vhX4T9r4GuyR+MuMMJ3nWQLWp5QLyAHBiqCl1jNrhV82W82IL3 lWAdEatoMZpXeOi0h3Vgexg1mBFNDOs2G5DYA1/RPSRel+5P0f/8yPKoCKUVGSzjAcdW9cOg8tNP L19X9rS7mHFtEfyNwjsMg7HyiBD3UDuVADCkxIpAaG6+OxdhpKwHIz0IvVIoqgAy9gnqKbjFU8oy DB2P1Q1BAB4Fi9mAi4KFqSNoEhiZGBtFHplAFveTCDFOqJ9AHyOEqb/KwuhIKuQHmsLLItSIVKj6 UTQsjKbZDFEUsE0YP4YTIg5s4CpsyTRxguf0SOwcBJ29YID9yePFjgjPhZz+KnRyvsO/LyiwyJ2a pr9i0L+DYFul3Y8CNzHcqZZLSG9p91OZlYQhtwR/lnbLujfFK0BAjQsGMhCPiri3IsyeeudCswOx DNR35CrMbqAxDujUblXWWsheS7HXwVloQJeX91ScleRmcFe/ZnP4unMm8RFwJcBDuWpia6D269no il4vMtma0iMw0kt8KCsy6Kya3XujKR5phAJNZejjAa5JDZ53SJmF1ahy68/CeWXkIQYEchiW9wHs nX0gUUw40ANHRc1ZxfqdN7D9G5f3ynu75VL/ZjD0bu/u/f/6PBpPguk/oNTFl9++PvxeKpeavxyf tE7fvmv/7e9n5xeXV//Z6fau/+/7Xz/8P2CmaIaTOKwghSgiILOAClCcURCIw6A/Fw0qVaul8hvx 0W6EzT1vPEU2aKeiL/0ZOvtozxIYTQYGng0UpiY3JHYuymKCKnl6IT0UCalT3COITjxsxg/76L9T mStS+E7OLFJzJFYJd8XjKHmYajahRJ6HdolyacPKi53PdJMLiCX+w/fP9149/5nAsjnu15DXSxvS Csbwi6HwRm6XefTSXDgxFghie8WyzS12UvH4IUageiF8IExMwvYlbGyydyKkOGnRxIC0VDzQehQx CWW7Ka8SuTczItoszmiDagT9xduR2aSBz/0hlm9QjEYxhhwVlHEyLUcecCNkuRR/gpbIXaN/Crp3 cjeLGy7dLUuUnJTGJZRvCdHyfYAG03Qa46kArvCjQ0X6TWMp8qnGFKrzkE0W2mXJ5hkMksmOJDP4 w6rsz6RxYZNE7eqv0iOLmb9sw6477RzN+sOoIbM1SMUSbaGlQhHrkGzZAKS/Zk94eWd3NAEWGxwq D5dBINXEgpdbYlIm0KMXv0Otjjvbok/hdAqbaumMwmniur8+3KeV0r3CSRYZOcBkU0R7kKqJ93VO iE82AhB5VZpuBKWQiVwlanXm1Q5gF6NqVYpE6M3mwltF759MTuDeR6C7B9MK91wQLBEBqIw7ieVp 4l8+Yr07u98dlXRrS5+kHlIQ+yIkSjhJo1EBkUzoD2geWn65Zq6VD1veQdVEDUiJTHrb21iwbrkh epIcnTIglCktwkjdycVr7z9rc5pfOD3RloIebm/4WaEcai71pu8Sf2ZfCRXyIIbiWvQxstnLoZXO KNhdnvkTrrrxd3HfVXHtQ/H4SO8vMHJiR2iyYuawaok0XPcq+U7GQuhG3i2m8BgtxhPdyZJ8VIdp q84JwneP6VUtbWj2OETl2qhXtJ0QRyLkiKYSzhlJr0LhTZpI9QtKYcLPneWq5CONC4804yjmr/2S XYTgZZTqes3VxJXbTRvAN/4UtGyV9+Ck0zztWU0k+GSb6I4M9+RHzDQ8D5mbd7wSbuwsSu4t1f5C QvPtGYiqEfDeRYshro/pyQ+j+c9pRMvSoNN/uJv/HCXVSZS9jCbRGdyEAWyRRUKWyD2YqEs5W3Ap vzlMnhShcHSqK8ZnI5Yw6Ol1xYsJhcz4v3sVMv/uRKjddZoAWfaskMnAQsHFOn4QeRHk5FDycDAY EB0S6Px8F8wejko3gyn0xS/HV+nirYhKmx9yVYhzI9R4+qH9rWoM50OosNs7eWSFhXhteninbu1s SsqlQ9i72ZXt6tqiUwZhtCd1btKUkW90cqAFc2yKO0uMzGv+xTcfl4LSpxuV6lZC0wvHoj8PIwVn KG3iq7NgcmfTblPknhRoDXP3S+vrFHTTtI7w8I0HZBuXthwM4D+latJQrg1pWg7XZ+NqjmJORNOh 96Oqjtv0o0xltgApJr0RTiRRWTP5lDpS30ifFLKvyOJ2k/kV4ZlUISJNDGZ3l7enEiFBi7awByvs hAp6LMO/h4eTYAiap+XcUnvDnekcIm9zQZTq/JZ9d8S2I+RI3SeLR64C3ZwpRLfZmk3KAJdLv0vq JxTi2hty7qGe4r/Rt8fmjmN+jIm0IZ2RHaKQcM/eFluau5WT89WrlJyce5E8jXvGdiQ2tccWM5ku qtL/0vdHWOlOic5FSVIqoTcv7Tpm2OSdkTfGGMc+kFqMrm0seWIeaNm1a9/Z1hsW6gLN1UJ2ubOU co3pIVKwKWlpU33BWMbtr3Ozmo6d01m9CrtzstymIifLc7I9WnY62yOsfTT3C7m4T0f/RNs6mO/4 NA/zLSKSeR/r2hy8jxSdj/V4ZXK/kIf7WuNMrOmJeWtwc2VmmuxbE/dSGOTQzenYxVhb+PGTtvmh IxaPszUsfUP/S9REDivFRGYWpNeTrDb8Ia7D+Al6tfpf4lpXskrKIW2iRkQk936vod3TLiipqTpP ndLylSe3bspui4x4Nb16c0hdZxpeuXpPDZNfkilYHQgLy13au+gioG3EliK1rb1TjkoPXlgyl+w0 a6NlMRQG37x2TV8bZYUN1oJiBoJJwaWsy/hulV7idice/AftnzwoE5T6PMl0Kw7oCaZLs2foTTFX lMDq0Bhelk9ElHZ87eMbjvVVgmfzhxJCJACLd/jd3U+8aTejYPAZHUbULjfRHsx73fogLystctDd ERSvUjIFQ5kLrpBODfSrfLWwDsp434UOyurBSM0A3td5MZNZQE+AUdmrEyWQ2iRRiyUJwT5bjFLE LcSsLuQKsgMF7movkBXlqzYvqukpj2BNV+01JCDGNEnFyM9JxshfWa5lncN5kosIvtrD7qNN21Ch 6Q2HOamkF/NSyYEe1nPYQ5N0QyxJCa3jyyA1jZYotfKtUjH5LSBI3NNJlYShe7oa1HFoUVpwnFYK fvRnqHGOzWlcYX8jP0vqFv44Zk2Nl6RDb2pvdOxNUsHCErBtegaWdREfjSI+1d7Q5+VSdf51Xtpd jpiPGOUwDyuodaLbI5bI1zGnchq1bt0OOrCg631WVrl8Hrf0VGf7HZtrwRK3Bl+wOWVuoQuFiFso 24kaXbd5O3bLrMQs985ILYLDcd5EjVYFqwNizVUqt7nqWtJYiBlyCmJsRD3dCHoVNes5x+O0uuwm tl3ti5774w0PVPgz2XLtNHfLweYyRHJ+uzcxuP/TclJ1G7ZzbLjxnX60mbUbkyeGy18qc5xWWK6z G26LhSQrVqwsc9pwmGodJRVSTCW6MKeHVcpVyHSbyixC06G2C5Z9FNWknSRTRXJhUWU/dePnqjCu 9tv8LThts2lXusFcdCN3VVTm84RjmViTo4Iae54wR+gWRSwY6XWmG5Uf3ZaYmSDJEBKZwehKLtmW rinmakJP/N3vjkATh75mFbZXbJSVz5p5ClGInh/pz62v6ewvWSAKheg6GV8plxP77KnCftMxyoWz oT01UKLvZZwG407NfcW6bMFbk+RFiXgKMTM4lCgT31CkWMa4jjLWxZXEJiadMRXMdyKDUD6IaYBc IeL5cXe2uR67y9BDhj0XC58ss6hlb9v2oIt1OV8+jc1Kv1EsS+XazZl0WYOvirmqKjrUthSRSnE7 iBhU3XqC1nSTD6aW0Rhol0/HsSRh9JOazH9X1dzjZkbVpfXHOJuwiZGBFXJguN+iO8meHHG+i/Zb /ZIow0mMT+h244g0k3KXGVZnnS8Y7tDC/dm598zafRIWp1TSM22o0mPTkIWY2X+R5KxpiG9EU5b1 9/X+rGpTyCu832t01G1tURAqi9pq0E5PH/nm2bwbxwNLbOFvB8L+MR+PNJFefxgREAGeknPukXAp NPVw+y7HRids9UEYRodulvH7OAzj6xii7DyMrGEAHOW0Q72Yxa0RnaCTzPXc7deqIv0DYYZa4gvy 2Y+45hg01muiDyJ9FxnhKSNiro1iEWsBSvcFdyG1RMnFcOEoz+2QV/Bh1NPc7eNgG5giTiNqtdOE 6BXPGjOi9uofxqt/6rlPrfxZQ8Fpx4qxMnbDyVdBk7JyOd2NxEuayykHOhaL87HXYiquUQjgjRAL h4eitN28p0jWDPiYKTDFWmDF9CQzC63yhHttS2OmuwrFeTmazo5QkO733GrOEqWAnnm/n1KKXnvv D5JXY4eGk9W3Eqxe2Ii2JYf+1CxyDxNL7hK1Q/s1qSBWxeptUG4rsdZt08rCTViKNptAw8KVbVM3 durxXWFMP1WqVUqZUROVs5dcWii/JXqiYXTOKpZ+BCr/yN3uPiXOz9KY7bBuJw8i27BXq/3lo+D7 kdgrSKOv2kR8H91FJMXhxKccOlbHFcyApNJ/xmtWUhsupo16OIapopHftkk7oMfYM10TE6gJvPoa 0oLvmrPUI0OORLfOd3jX/nv17XKT6igAflUoyG0b6909KonZohRT07r8gWPj4dyrUXnJdm7hXZDs aZ2wW8k1QbsUzKXMoLGzCmxMzdB1jQMfl1nU6INsmc8j68uOQUVddDwstW6lOXeM+7PPbDGhMeEN zWQew9QD978UpbpwC9xEh1gEFYWvgBHzeSM5sIiHYsqIIthoELR0YE/XGP3ont901+Kg/eebvxg8 wo+yiKotT1XedaKmJ5C89MeId26ezf84BM2cJxDSxTq7yulgSq9E3e1qziezge3+FJ8cRgPtRc3+ ybZnxm/pzurezgShHhXaXGgoqFGPK3iJYQcyrvtZVe8yhEUNZiz21iz6VrER8/KNRqXL20PpvX1w gN7bd0Kcvn9FV1G6vUjeqo63tDaTzI9I3qea7voYXEJhXdXO8ldrNtqALVB8MEP8o1N6DltPLMIk aZXl4ScJToCmiNpuB9G1cNswbx2V/tafELpnsfG3xeghwSy2bdu3YmtTRh0KQrTYaC7uFuH8aarh +TKKja43Bebiqvsk1TSnM38E1VwO5sGTVXLeR25dBF+esCF/W0w8qOTEGzxpJSMSLi5m2XXQFPSY XiHBwrBIIWxPV5WSL6iNZO7pqhIyhgMHpe7pKpKSRk16Qt5JYaP5ZuKtUJFShbSW975zefGWdT9c 9Jq/stPLDju/vOi9c+qC0b1xkvY3FemtKE2YhBwh6DmFxBwJb3JP7zaiRyOGqjHyJ58R4rR3eSwA CBEOAEG6f0fYuBFDa5UJ5fGkBwAp/v2OM4C+bhWvEDHE6F4pZE1+nmzrKlz3MFYwXoSwl4IKgucG YlWVBwji+CAWOfb6dUrk2PNI5FjkmCGmr8VIikdMJumrxi49rgYYBxdujcAQBQewSbZkWenMvols LW9WdZpURbiEKU8Dsy1Kok4xrZ+OmehK3sQOmMgVVCqBRllcer9t3EVBB124SEJy7FxXlDNW4B4S lA9U789hA/WAeJbwKaYvwpduMYVheE+5uLSI0iwX8gSBMCD8L1DKF8qA9FlkuR1wLA6MToDZS7sK gP45wugaqCyY6QKBYsrQOKE0gz50GjGdz3eCqunMAwFA4GJOX5kjJxNxRmooxoY6BUGZp1UKEF8V J1FE5ZyXaWZF5CSYMuBNPtsCBzBH2Wd/MjROe2Fi/uJTEnaZ9al/A2uYMXomFHQjsvBi8i6Jl0w5 nER8ikEdwjZBJ4aLwT1vSOhko5WM0uw6YJA3utXlIXcwy+GNpxNPUT7XB/Zb/6HMK8JspJiRcgyt gUHJQ2ftFhgUzkwALIFSHRNe2a36iekqExo89L4OQJVBGiaeNxS5UDnyNeU/RdYPMSwGuAHEqfJ0 ujjfMJPxJFmU71bB+A4xEQ8Vq1plpTQ2G6BL6qryJT7wGDcNN55I2obig6nnQ5nBixLSKbhQlGFE pdYFjkQCq1BCZt33J6w1uUMhzTtKMZJn7GNE89Sbjf2QZ9YAgZpQ7jISPhQseDr1KPkjSg/PU0pS oMmZeV+CzzoNmasHfcoTTPlMETKMWosZ98JHTyr3dlJogUbrIX7rzPMpS7QaU4Q0ruktNrus3YVV th/6fFD03rWYwgPqXh63W70PrHlxYj9oXbxtX7RanfbFW11Yr9n9Oypnxy120u4enzXb513WPDtj 75udTvOi1251y6z161Wn1e0y0OHa51dn7dZJGYo9Prs+gbLYL9c9Xd7FZY+dtc/bvRbUfglEfJAl fQBqmj0i6brbYpengjqo/LyJCerYu1an1b5g79s6Wx4vEF5CqltUXKf99l2PaMFfgh6DXCz5vNU5 fgc/m7+0z9pQ82VHF3ja7l1gY1AjbbKrZqfXPr4+a3bY1XXn6rLbsrsUlacBZuMdecM7c4VL7m9a I08XE1rX5RjGtHke5RRlMjAY+3iwmMH8gcmOVW9zMdT0RuWxah4451BgjqGt3CECBS6H7sJ9JZpb z/6ANqL7RGXoDQKePfYQRs8EiPsTXji8DyjPtvM1wrzDFI7i3f4A5+xcL/9yefKBv0impEP2PeWI kIeGaOWs3PbH/ujhENGOv3gwLfdhkZ35/RHM4zDtVNBj69Z8P/R/9w7Z3sH0689Ux7s9u4YDuhxf vKIvaNYC+ir3HvaydX8ZegpTmPYqNzOv/5nHJxyy/pfAHwqi9rOaLYh68RSVH+Ss/OAJKr/idY/7 szt/UsEY6kO2741FPeL2jLOe38ePOi3HZwfqM7tv6ROYEM7ER5Em8ccnVW6mtFlxS5eDFc/drBDt NzgSE0oeq3CIaJFUs9ay49Q9F9RV74M5Br2ZxDlo+02IKD9MEk+cw9hF+yCrHw3KXkvCcEuzn5Os m2A0XJao5Ua5IgvmXIsobpH+RkQ5GUWHeLZwvX7tHmf7++6Zx7if2gQhYCRT/H4hN/lE7NazN2NY sTANAKhv7A/Dyl6dBOIm7CFgBXk4RCb9SZ8lr0cqj4rGLJUmnMxFiQOQ/s/fTPuyHaQkoHZBLXPu mk3oBecJxAi1eyOHQAoCv2kNcZS0iJSUAtcvkSiY6c2mWBY34RDO7EfZ9xV/uFNFtyfzxmfvYacU z0VQKmekHNgmBpS3ifpd6REhKMGEjEZXyYL45/aXcT9P00EodtxG+MrxEzjGg/DctoqlWsINrNF4 PmbGu8UPvvK5sq+J1Va03KM4LU9NI8emeeUEy8bIJjwmVUE6hm3Q1W3J/cYK4ogx5p0W6wBn76os FFnfZ/eK2bCPHA5ApKHg4fn8x1GpJIV9tW6wGZQSwqWIj8wcaIkf0bSZieOhjg0iPokRGuRpr45D kXVIH7JcDq4ZEXks6m4WDyEqNso5AgxT3Yb0SzHRc41gvPI6OiXJjBQRMgzIH99pgdH184wK8hTf tKxbdNpDI22gxPHR4iNFZmJJGyy2E2hWy2Vyl1I5JYfLrjFavtFwKXyj8fLtBkxm0F2+EZMeF8Rb FRkw7gUPr8yykj5xkhhZQu2y7Re1irDk8VKK5aVvIKrmdB9JgD9GrO9jbltiVwggRYBXSWe22ejG bW2r7I8eVZAALVa25B5Q9TnPMfKOLIORmRfUe1gIFxO0yU1246fJOY6S03tBgIg1VOgFqOb8Hk+J 54fs3BsHhhkwby8JzFsU5qmYjmzLMJlzlcGvcjLr33JzMTxwwRM4o5hVXaA9lTCX0v7z/VclPf/5 E0pIjCZn6lNMBseP0OEmWSFDedQlfG/Z3nP8hVlAoaiqHiixAONsgibBiTrBQZj9cM3UyXLEYYo6 juJHOLBTlC4EsfM44DGeDIgjhOpaG3kR/Pbv2EZZ0E77NnJ6duMNAswPiOeA/MiPtVu9UyoGhyDl VmBk1MX0TrKgOTLEn/NzlhuP3cBrSBNlJRVthiHn6ya7RWx3JeaTH5UkCc8PgttbytuK532DQTAb ZtSv2iOPaoR3yTDwOAOFsZ6fFxFfqPsmD0wcqtGMpLkC7MNu4eeweFIWG+bVzPbqSe74kh+aXBy3 2PUFbNTbF60Tx0yoylITBr9p1xzSOZnsWCkBocz/qY4fWojO5Xm4MxRzVz/8zE4DTOCzg0zYLdM5 GZTWF2fe+NOSmFCI3EVAZiCQW34CyB/SGW1/FAbG0bSDsH7obEY1uXFDmkh1CWh95cerfajzqz9e jLG5of+Vp1kXFWATxKE6B2kfltnMm1JeYjrylCkV6NCGt8Qgc04CMffHniSNZnh/0p+C/ExBp0Mm BJSgM0Z1aKTqhHXXQxMdVgnvD0BF5QVCjWPzDBW+oswndII/C+7Q1adYFfaCaWzpEWiImFFVqApR MgY8cWefTj7xXHUuxEromiUjW63vzW8piyv+UdvzhxUJXhkSlFIj/7sUKZaD7MhK2b3vD4Pf2Ako 1YN5QDmQHtWAkMqpYnCsm2rjhXRSobsjNNLMSN7FHp7rJqrnNsS9WYOldYpZQpssszRDTaGpzkb0 kHDqDdBDwpqnmFOpVAec2m8Am445ZhYTXBpoIpjx9DMhDuzBgg7r6X64uLuD+7TaUbrSMc6sPKRD DJoTORUI5xNap8aggOFYWkyEF0DVak8Kp7L5BJzP4BPVzt0miEOtr1MYn+SIMwLGBPNgEIxijCFf H+KJng7UgsI5/mDxW/p1mC43mik52Ujzn2C/N1wPT5flKM/M7g/ysTUcAGnIWCa/w7nsm/B0Saas JGZiY5XJEKFqhLHsFOvnQ+Hx0sFWYQXfGq4wM2kPKFxDPifLC2/gYG2T09XIQwcrWqqlB5hcS9Hb Q3HQYzyrtCL58vbWH/jGfMELVPtjkYR6p9s7YXu7qiGypcJ9jPukcmqtLaroSsmIKntEp2aLd0Tb hM67vuheX11ddtD957jZa7297HyoypXRHQYYU1GXspkgRrW5DX/a1HlMmfVWPRuMHw3OeUs4s+/3 Gj2Z7v5YZFV3HhIu+Jaqz9Hf6A8VciVKTD6aEzbAf9ZqEWibqGnTZcmMwU8ouVkahkIH4psgmHmI iCG9qtqd+fTiUEwUR2nl2Sw2bCQdW/CTi1IIBQmWb/HYGaWhh5w9QkzghYTYDAfMgmuUmUxOQhtb lvmTxK5fgfk/fL/36sefM/fATqPx0mJnfL0mtplPXfLKw7/XyrGOW1RTBStBRg2UjLVz48YuJBEh Ii7i9hlF7NgoCZ9jW6aTME/zrWP1gsxoIRtlGvHlVHxjfa/ItkJtpNAq6qIBN1iErL1gVmudqOik vAW77oKjcuFKEquaHEp4fapCVaPdVzJpY0oTDc/WWE1JMSAJjU3B0U9b3tWqHYv3dq/Xt/1RaKy9 0Y/4Oq2f6YhtetKo38/k+im8nKBo/3eP8l7hxt+jOCYLHkrGQEW/yxsHtV9UMdTwiHt6QX0vi5FM KubpQjy3h0CWsI7JKD5bx2Rzp05V7MBDdbSokJPlbwcxB8+LppCQp4uZ16VzelyUcgF/q5BtkcgF 3r6JwW4gUptRhHBvTJoGYmlpqWhr/plr+H88LbSF3M00MyGKYFgK/7izXox/7s6LNdYaWKicseOz ZreLaRAmn/cxl7xkhbghuNi7PLbyywt412hud/uA1I6D5+eRhSUi4OMIObGhxLFCcge6L0Kv+zCG ckPJ8o9JEz7CnhgK06eEuNbIepYEBvPRPGBXpam53rXWrXCKaGQJdYBXUELQvCwTUSHhzjZ+Vy6V 7ZRhTg0DqseUrwq7VOHh33jQYs8sKoIkqPwHnAkJtqlgmXggebEW9fO1uhwldom0qgmbtPSUqhH4 f6O1rmSTiWG1+mn62fRyfbGte/9JuR5d5jN23LmnBFuNdsuwS4w17h0BUjbM4UixxxrwUPq/jBej uT/FlZobvY6Kzeqe+V9SELpzYshZV5LamyM4PYtbhGrZkM7Ld2izEgePgjayw3E2qUcC3AgjG4GX oDwwDB5kt/7dYubJDw3fZrW6xYAGM+KsY+9/3Pu0jOtQdVqNzqlxts//yQmXAyAVEk3bgSh0Kbz3 vHnj/2yuzbW5Ntfm2lyba3Ntrs21uTbX5tpcm2tzba7Ntbk21+baXJtrc22uzbW5Ntfm2lybK/n6 b3NpLbMAaAEA ------=_NextPart_000_0000_01C0D994.64999D70-- From w3c-dist-auth-request@w3.org Fri May 11 19:37:54 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22891 for ; Fri, 11 May 2001 19:37:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA21042; Fri, 11 May 2001 19:36:02 -0400 (EDT) Resent-Date: Fri, 11 May 2001 19:36:02 -0400 (EDT) Resent-Message-Id: <200105112336.TAA21042@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA21022 for ; Fri, 11 May 2001 19:35:55 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA10656 for ; Fri, 11 May 2001 19:35:54 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA05070 for ; Fri, 11 May 2001 16:35:58 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Fri, 11 May 2001 16:34:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: WebDAV Interop. Event Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4949 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit WEBDAV Interoperability Testing Event ------------------------------------- Where: Univ. of California, Santa Cruz Baskin Engineering Building Santa Cruz, California When: July 19-20, 2001 (set-up available the afternoon of July 18) Who: Developers or testers of WebDAV and DeltaV clients and servers. Cost: Free, though once the costs are better understood, I will probably request a voluntary contribution from those who can afford it. How to Register: Send email to Jim Whitehead . As previously mentioned on this list, there will be an interoperability testing event for WebDAV clients and servers. The intent of this exercise is to gather together, in one physical location, the developers/testers of WebDAV/DeltaV clients and servers, to exerce as many client/server pairs as possible. This will quickly surface interoperability problems. Once identified, these problems can sometimes be fixed on the spot (if developers have brought source code), or can be targeted for resolution in the Draft Standard (i.e., revised) version of RFC 2518. Similar interoperability events have been held in the past for Internet mail standards, and have been very successful. They are an extremely efficient way to do interoperability testing against a broad array of clients/servers, allowing problems to be quickly identified and resolved. Invariably, the net result of an interop. event is a set of clients and servers that work better, hence offering better value for end-users. While many details still need to be worked out (I'll send them to the list as they are resolved), some of the most important aspects of the event are as follows: * Results from the event are NOT intended for distribution to the Press. This is not an interoperability demonstration like those sometimes held at trade shows for marketing purposes. Instead, this is a normal part of the *engineering* activity of creating an interoperability standard. * Since the intended room for this event is not super-big, I request that a maximum of two people attend per independent code base (if this seems too restrictive, let me know). * You will need to provide your own machines, with the client and/or server software installed. UCSC will provide networking capabilities. * If you're intending on participating, please let me know via email to . * If you're traveling from afar, you should try and get accommodations as early as you can. Santa Cruz is a popular vacation location in the summer... Here is a Web page giving hotels: http://www.scccvc.org/accom/accsearch.cfm If it's in your price range, the West Coast Santa Cruz Hotel is nice, and most rooms have an ocean view. http://www.westcoastsantacruz.com/ WestCoast Santa Cruz Hotel 175 West Cliff Drive, Santa Cruz, California 95060 831-426-4330 * 800-426-0670 * FAX 831-427-2025 Here's a list of Bed and Breakfast places as well. http://santacruz.about.com/citiestowns/caus/santacruz/cs/accomscbedbreak/ind ex.htm - Jim From w3c-dist-auth-request@w3.org Fri May 11 19:43:21 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22951 for ; Fri, 11 May 2001 19:43:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA16320; Fri, 11 May 2001 18:00:45 -0400 (EDT) Resent-Date: Fri, 11 May 2001 18:00:45 -0400 (EDT) Resent-Message-Id: <200105112200.SAA16320@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA16265 for ; Fri, 11 May 2001 18:00:36 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA02658; Fri, 11 May 2001 18:00:36 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id WAA08792; Fri, 11 May 2001 22:42:45 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id XAA239950; Fri, 11 May 2001 23:00:02 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A49.0078D88C ; Fri, 11 May 2001 22:59:57 +0100 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org Message-ID: <80256A49.0078D6CA.00@d06mta07.portsmouth.uk.ibm.com> Date: Fri, 11 May 2001 22:58:21 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Pedantic Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4948 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: Apologies to "dist-auth", my mailer is screwed up and this went to the wrong list, twice. I intended it to go to Delta-V. ------------ Just to be pedantic, in versioning-15 section 14.2 "A collection has all the properties of a version." Taken out of context this is misleading. Section 14.3 "In particular, a working [collection] resource is initialized to contain ... of the checked out [collection] version." I suggest adding the word 'collection' twice, as indicated above. Section 14.3.1 Should this be marked a required property? Tim From w3c-dist-auth-request@w3.org Mon May 14 11:03:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14524 for ; Mon, 14 May 2001 11:03:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA08470; Mon, 14 May 2001 10:50:57 -0400 (EDT) Resent-Date: Mon, 14 May 2001 10:50:57 -0400 (EDT) Resent-Message-Id: <200105141450.KAA08470@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA08450 for ; Mon, 14 May 2001 10:50:51 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA04300 for ; Mon, 14 May 2001 10:50:50 -0400 Received: from maggie [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 14 May 2001 16:50:18 +0200 From: "Stefan Eissing" To: Date: Mon, 14 May 2001 16:50:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: WG: PROPFIND allprop with more properties (was AW: Resource class) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4950 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Von: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von > Tim_Ellison@uk.ibm.com > > "Stefan Eissing" > > This touches on an issue I (the guy with the webdav [maybe caching > > a little] proxy) have with discovering type and status of a WebDAV > resource. > > "maybe caching a little" ;) > >[...] > No. DeltaV defines those properties so if there is no DeltaV the client > would use some other way to distinguish a resource's classification as > written in whatever spec. they are probing for. Thanks for the clarification. > > If not, does OPTIONS then remain a better place to look for methods? > > Pass -- we've been round that loop a few times. Geoff has written it both > ways, probably more than once. I've read up on it in the mailing list archive. The argument goes that a) Depth header makes it more efficient and b) doing it in one PROPFIND make it consistent Now for a proxy with a little bit of caching, this is the way to go. But then, oops, I found that the versioning properties did vanish from PROPFIND/allprop in revision 14.1 of the draft. With the current state of things, I'd have to do 2 PROPFINDS (one allprop to catch all dead properties, one specific DAV:supported* to know about versioning and resource status). Has it been discussed already (could not find it in the archive) to enhance allprop by allowing the client to specify additional properties? This would make the body of a PROPFIND look like and the result would be the joined set of a PROPFIND/allprop and PROPFIND/prop. (The only related thing I could find was the "WebDAV PROPFIND Extension To List Specified Namespaces" Draft from August 1999. Which is a nice draft, but I assume it is too late to move the versioning props into a separate namespace...) Stefan From w3c-dist-auth-request@w3.org Tue May 15 12:43:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02592 for ; Tue, 15 May 2001 12:43:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA16079; Tue, 15 May 2001 12:39:03 -0400 (EDT) Resent-Date: Tue, 15 May 2001 12:39:03 -0400 (EDT) Resent-Message-Id: <200105151639.MAA16079@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA16059 for ; Tue, 15 May 2001 12:38:57 -0400 (EDT) Received: from server1.software-ag.de (server1.software-ag.de [193.26.194.2]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA09835 for ; Tue, 15 May 2001 12:38:55 -0400 Message-ID: <2B1792E820ACD411AD5A00508BF9A3FC0141034A@daemsg03.software-ag.de> From: "Pill, Juergen" To: w3c-dist-auth@w3.org Date: Tue, 15 May 2001 18:27:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: lock and access control lists on (working) versions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4951 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hello, 1) Would it be possible with DETA-V to have different access control list for different versions of a resource, e.g. V1 of resource /foo will allow user A to modify and read, but V2 of resource /foo will allow user A to read read only? 2) Would it be possible to have two distinct locks on two different (working) resources? Does that make sense at all? Best regards Juergen Pill From w3c-dist-auth-request@w3.org Mon May 21 05:38:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04367 for ; Mon, 21 May 2001 05:38:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA19298; Mon, 21 May 2001 05:19:24 -0400 (EDT) Resent-Date: Mon, 21 May 2001 05:19:24 -0400 (EDT) Resent-Message-Id: <200105210919.FAA19298@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA19274 for ; Mon, 21 May 2001 05:19:02 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA23650 for ; Mon, 21 May 2001 05:19:02 -0400 Received: (qmail 7812 invoked by uid 0); 21 May 2001 09:18:29 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 21 May 2001 09:18:29 -0000 From: "Julian Reschke" To: Date: Mon, 21 May 2001 11:18: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.2416 (9.0.2911.0) In-reply-to: <2B1792E820ACD411AD5A00508BF9A3FC0141034A@daemsg03.software-ag.de> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: Problem with Adobe GoLive 5.0's parsing of PROPFIND Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4952 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, we are currently doing interoperability testing with our WebDAV server. We found that GoLive 5.0 (evaluation version) seems to do a validation of PROPFIND responses based on an internal DTD (or something similar). For properties in the DAV: namespace that contain a child element "href" (something completely legal), it reports: "DAV-server response is not correct according to the DAV-Protocol, you will probably lose some important information", with the details "Predecessor of a Href-Tag must be a Response-, Locktoken, or Owner-Tag." Do we have Adobe employees reading this list? Julian From w3c-dist-auth-request@w3.org Mon May 21 05:49:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04412 for ; Mon, 21 May 2001 05:49:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA19716; Mon, 21 May 2001 05:35:01 -0400 (EDT) Resent-Date: Mon, 21 May 2001 05:35:01 -0400 (EDT) Resent-Message-Id: <200105210935.FAA19716@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA19690 for ; Mon, 21 May 2001 05:34:53 -0400 (EDT) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA24880 for ; Mon, 21 May 2001 05:34:52 -0400 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id CAA08970; Mon, 21 May 2001 02:39:02 -0700 (PDT) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id CAA17446; Mon, 21 May 2001 02:33:44 -0700 (PDT) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id LAA28301; Mon, 21 May 2001 11:28:04 +0200 (MET DST) Message-ID: <3B08E102.99155728@adobe.com> Date: Mon, 21 May 2001 11:33:54 +0200 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Julian Reschke CC: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Problem with Adobe GoLive 5.0's parsing of PROPFIND Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4953 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Julian, could you send the significant part of your server response so that we are able to check what is going on? Best, Hartmut Julian Reschke wrote: > Hi, > > we are currently doing interoperability testing with our WebDAV server. > > We found that GoLive 5.0 (evaluation version) seems to do a validation of > PROPFIND responses based on an internal DTD (or something similar). > > For properties in the DAV: namespace that contain a child element "href" > (something completely legal), it reports: > > "DAV-server response is not correct according to the DAV-Protocol, you will > probably lose some important information", with the details "Predecessor of > a Href-Tag must be a Response-, Locktoken, or Owner-Tag." > > Do we have Adobe employees reading this list? > > Julian From w3c-dist-auth-request@w3.org Mon May 21 06:04:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04527 for ; Mon, 21 May 2001 06:04:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA20346; Mon, 21 May 2001 05:57:12 -0400 (EDT) Resent-Date: Mon, 21 May 2001 05:57:12 -0400 (EDT) Resent-Message-Id: <200105210957.FAA20346@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA20321 for ; Mon, 21 May 2001 05:57:06 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA27119 for ; Mon, 21 May 2001 05:57:05 -0400 Received: (qmail 20515 invoked by uid 0); 21 May 2001 09:57:02 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001-rz3) with SMTP; 21 May 2001 09:57:02 -0000 From: "Julian Reschke" To: "Hartmut Warncke" , "Julian Reschke" Cc: Date: Mon, 21 May 2001 11:57:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3B08E102.99155728@adobe.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: Problem with Adobe GoLive 5.0's parsing of PROPFIND Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4954 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK, here we go. This is a response to a PROPFIND with depth 1 on a collection resource: /wcm/webdav/test/ Mon, 21 May 2001 09:50:49 GMT 2001-05-21T09:50:49Z / "-18707824559904386492400" HTTP/1.1 200 OK /wcm/webdav/test/ANSI.TXT Fri, 18 May 2001 17:39:34 GMT 29 2001-05-18T17:39:34Z ANSI.TXT text/plain "983715736990207574624990438302415" mailto:fax@greenbytes.de HTTP/1.1 200 OK > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke > Sent: Monday, May 21, 2001 11:34 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: Re: Problem with Adobe GoLive 5.0's parsing of PROPFIND > > > > Julian, > > could you send the significant part of your server response so > that we are able > to check what is going on? > > Best, Hartmut > > > Julian Reschke wrote: > > > Hi, > > > > we are currently doing interoperability testing with our WebDAV server. > > > > We found that GoLive 5.0 (evaluation version) seems to do a > validation of > > PROPFIND responses based on an internal DTD (or something similar). > > > > For properties in the DAV: namespace that contain a child element "href" > > (something completely legal), it reports: > > > > "DAV-server response is not correct according to the > DAV-Protocol, you will > > probably lose some important information", with the details > "Predecessor of > > a Href-Tag must be a Response-, Locktoken, or Owner-Tag." > > > > Do we have Adobe employees reading this list? > > > > Julian > From w3c-dist-auth-request@w3.org Mon May 21 07:26:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05461 for ; Mon, 21 May 2001 07:26:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA22259; Mon, 21 May 2001 07:14:25 -0400 (EDT) Resent-Date: Mon, 21 May 2001 07:14:25 -0400 (EDT) Resent-Message-Id: <200105211114.HAA22259@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA22238 for ; Mon, 21 May 2001 07:14:19 -0400 (EDT) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA32539 for ; Mon, 21 May 2001 07:14:20 -0400 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id EAA14921; Mon, 21 May 2001 04:17:07 -0700 (PDT) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id EAA23359; Mon, 21 May 2001 04:11:07 -0700 (PDT) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id NAA06247; Mon, 21 May 2001 13:06:09 +0200 (MET DST) Message-ID: <3B08F7FF.7BAEC286@adobe.com> Date: Mon, 21 May 2001 13:11:59 +0200 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Julian Reschke CC: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Problem with Adobe GoLive 5.0's parsing of PROPFIND Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4955 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The problem is probably caused by ... mailto:fax@greenbytes.de ... because we do some rough checks against the WebDAV DTD of RFC2518; a DAV-href-tag is not expected in the user defined tag "julian". An error message is displayed but this should actually not have any further consequences. Best, Hartmut Julian Reschke wrote: > OK, > > here we go. This is a response to a PROPFIND with depth 1 on a collection > resource: > > xmlns:dt="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > > /wcm/webdav/test/ > > > > > > > > > > > > > Mon, 21 May 2001 09:50:49 > GMT > > > > > dt:dt="dateTime.tz">2001-05-21T09:50:49Z > / > > > > "-18707824559904386492400" > > HTTP/1.1 200 OK > > > > /wcm/webdav/test/ANSI.TXT > > > > > > > > > > > > > Fri, 18 May 2001 17:39:34 > GMT > > > 29 > dt:dt="dateTime.tz">2001-05-18T17:39:34Z > ANSI.TXT > text/plain > "983715736990207574624990438302415" > > mailto:fax@greenbytes.de > > > HTTP/1.1 200 OK > > > From w3c-dist-auth-request@w3.org Mon May 21 07:38:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05739 for ; Mon, 21 May 2001 07:38:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA22546; Mon, 21 May 2001 07:28:56 -0400 (EDT) Resent-Date: Mon, 21 May 2001 07:28:56 -0400 (EDT) Resent-Message-Id: <200105211128.HAA22546@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA22517 for ; Mon, 21 May 2001 07:28:50 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA00976 for ; Mon, 21 May 2001 07:28:51 -0400 Received: (qmail 26285 invoked by uid 0); 21 May 2001 11:28:18 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp030-rz3) with SMTP; 21 May 2001 11:28:18 -0000 From: "Julian Reschke" To: "Hartmut Warncke" , "Julian Reschke" Cc: Date: Mon, 21 May 2001 13:28:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3B08F7FF.7BAEC286@adobe.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: Problem with Adobe GoLive 5.0's parsing of PROPFIND Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4956 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with your analysis. Do you intend to fix this? > -----Original Message----- > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > Sent: Monday, May 21, 2001 1:12 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: Re: Problem with Adobe GoLive 5.0's parsing of PROPFIND > > > > The problem is probably caused by ... > > > mailto:fax@greenbytes.de > > > ... because we do some rough checks against the WebDAV DTD of RFC2518; a > DAV-href-tag is not expected in the user defined tag "julian". > > An error message is displayed but this should actually not have > any further > consequences. > > Best, Hartmut > > > Julian Reschke wrote: > > > OK, > > > > here we go. This is a response to a PROPFIND with depth 1 on a > collection > > resource: > > > > > xmlns:dt="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > > > > /wcm/webdav/test/ > > > > > > > > > > > > > > > > > > > > > > > > > > Mon, 21 May > 2001 09:50:49 > > GMT > > > > > > > > > > > dt:dt="dateTime.tz">2001-05-21T09:50:49Z > > / > > > > > > > > "-18707824559904386492400" > > > > HTTP/1.1 200 OK > > > > > > > > /wcm/webdav/test/ANSI.TXT > > > > > > > > > > > > > > > > > > > > > > > > > > Fri, 18 May > 2001 17:39:34 > > GMT > > > > > > 29 > > > dt:dt="dateTime.tz">2001-05-18T17:39:34Z > > ANSI.TXT > > text/plain > > "983715736990207574624990438302415" > > > > mailto:fax@greenbytes.de > > > > > > HTTP/1.1 200 OK > > > > > > > From w3c-dist-auth-request@w3.org Mon May 21 10:06:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09791 for ; Mon, 21 May 2001 10:06:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA26199; Mon, 21 May 2001 08:41:55 -0400 (EDT) Resent-Date: Mon, 21 May 2001 08:41:55 -0400 (EDT) Resent-Message-Id: <200105211241.IAA26199@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA26179 for ; Mon, 21 May 2001 08:41:49 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA07885 for ; Mon, 21 May 2001 08:41:50 -0400 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id FAA26929; Mon, 21 May 2001 05:44:44 -0700 (PDT) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id FAA27328; Mon, 21 May 2001 05:40:20 -0700 (PDT) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id OAA13347; Mon, 21 May 2001 14:35:22 +0200 (MET DST) Message-ID: <3B090CE9.5590FB71@adobe.com> Date: Mon, 21 May 2001 14:41:13 +0200 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Julian Reschke CC: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Problem with Adobe GoLive 5.0's parsing of PROPFIND Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4957 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think we will try to improve that situation in future releases, Best, Hartmut Julian Reschke wrote: > I agree with your analysis. > > Do you intend to fix this? > > > -----Original Message----- > > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > > Sent: Monday, May 21, 2001 1:12 PM > > To: Julian Reschke > > Cc: w3c-dist-auth@w3.org > > Subject: Re: Problem with Adobe GoLive 5.0's parsing of PROPFIND > > > > > > > > The problem is probably caused by ... > > > > > > mailto:fax@greenbytes.de > > > > > > ... because we do some rough checks against the WebDAV DTD of RFC2518; a > > DAV-href-tag is not expected in the user defined tag "julian". > > > > An error message is displayed but this should actually not have > > any further > > consequences. > > > > Best, Hartmut From w3c-dist-auth-request@w3.org Tue May 22 12:02:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23714 for ; Tue, 22 May 2001 12:02:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA04980; Tue, 22 May 2001 11:56:47 -0400 (EDT) Resent-Date: Tue, 22 May 2001 11:56:47 -0400 (EDT) Resent-Message-Id: <200105221556.LAA04980@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA04954 for ; Tue, 22 May 2001 11:56:35 -0400 (EDT) Received: from dirk.holoweb.net (dirk2.holoweb.net [216.94.134.20]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA07042 for ; Tue, 22 May 2001 11:56:35 -0400 Received: from holoweb.net (gw1-tor.intrasect.com [216.94.134.192]) by dirk.holoweb.net (8.9.3/8.9.3) with ESMTP id LAA57288; Tue, 22 May 2001 11:56:51 -0400 (EDT) (envelope-from zodiac@holoweb.net) Message-ID: <3B0A8EA9.8DF13928@holoweb.net> Date: Tue, 22 May 2001 12:07:05 -0400 From: Laurie Harper X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Reschke CC: Hartmut Warncke , w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Problem with Adobe GoLive 5.0's parsing of PROPFIND Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4958 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > mailto:fax@greenbytes.de > Just to be clear: the element 'julian' appears in the default namespace, which is the DAV namespace. Since that namespace doesn't define an element named 'julian' this is likely to cause trouble. You probably want to place that element in a different namespace, one controlled by you. L. -- http: www.holoweb.net/~zodiac/ | jabber: zodiac(@)jabber!org email: zodiac(@)holoweb!net | icq: #78724820 ----------------------------------------------------------------- condom: general protection error, child process produced. From w3c-dist-auth-request@w3.org Thu May 24 19:42:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22803 for ; Thu, 24 May 2001 19:42:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA20558; Thu, 24 May 2001 17:50:08 -0400 (EDT) Resent-Date: Thu, 24 May 2001 17:50:08 -0400 (EDT) Resent-Message-Id: <200105242150.RAA20558@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA20538 for ; Thu, 24 May 2001 17:50:03 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA19896 for ; Thu, 24 May 2001 17:49:57 -0400 Received: (qmail 10425 invoked by uid 0); 24 May 2001 21:49:23 -0000 Received: from p3ee2464e.dip.t-dialin.net (HELO lisa) (62.226.70.78) by mail.gmx.net (mail01) with SMTP; 24 May 2001 21:49:23 -0000 From: "Julian Reschke" To: "Laurie Harper" , "Julian Reschke" Cc: "Hartmut Warncke" , Date: Thu, 24 May 2001 23:49:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3B0A8EA9.8DF13928@holoweb.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Problem with Adobe GoLive 5.0's parsing of PROPFIND Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4959 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Laurie Harper > Sent: Tuesday, May 22, 2001 6:07 PM > To: Julian Reschke > Cc: Hartmut Warncke; w3c-dist-auth@w3.org > Subject: Re: Problem with Adobe GoLive 5.0's parsing of PROPFIND > > > Julian Reschke wrote: > > > > mailto:fax@greenbytes.de > > > > Just to be clear: the element 'julian' appears in the default namespace, > which is the DAV namespace. Since that namespace doesn't define > an element > named 'julian' this is likely to cause trouble. > > You probably want to place that element in a different namespace, one > controlled by you. Contrary to some big company in Redmond, I am well aware of the fact that the DAV: namespace shouldn't be abused with proprietary extensions. This was just an example. Moving it to some other namespace doesn't change GoLive's behaviour (and even if it would, it would still be a problem for GoLive because other WebDAV specs (ACL for instance) *do* use DAV:href in DAV properties where GoLive doesn't expect them). From w3c-dist-auth-request@w3.org Thu May 24 22:29:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24947 for ; Thu, 24 May 2001 22:29:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA08590; Thu, 24 May 2001 22:25:42 -0400 (EDT) Resent-Date: Thu, 24 May 2001 22:25:42 -0400 (EDT) Resent-Message-Id: <200105250225.WAA08590@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA08570 for ; Thu, 24 May 2001 22:25:35 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA12339 for ; Thu, 24 May 2001 22:25:35 -0400 Received: from gmgw01.us.oracle.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f4P2Lpv15024 for ; Thu, 24 May 2001 19:21:51 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-33.us.oracle.com [130.35.171.33]) by gmgw01.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f4P2P2X18490 for ; Thu, 24 May 2001 19:25:02 -0700 (PDT) From: "Eric Sedlar" To: "WebDAV WG" Date: Thu, 24 May 2001 19:29:38 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Issue: Locking namespaces vs. resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4960 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit There was a long discussion of locking a URL (so that a resource can't move when locked) in the fall of 1999, and in looking back through the archive, I didn't get a feeling of resolution that the spec should be changed in any way. The discussion started with: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0113.html from Yaron, and there were a number of proposals to actually specify whether you wanted a namespace lock or a resource lock, rather than leaving this vague. I still think this is very useful, for performance reasons (I think Greg Stein mentioned that mod_dav must recursively search the source directory for locks before doing a MOVE for just this reason--not a good thing), and we definitely have a greater cost to lock names vs. locking resources. I'd like to be able to expose both and let good clients deal with 302 responses and improve server performance, rather than having servers implement only one and letting the client guess what LOCK means. --Eric From w3c-dist-auth-request@w3.org Fri May 25 00:29:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27464 for ; Fri, 25 May 2001 00:29:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA11080; Fri, 25 May 2001 00:26:50 -0400 (EDT) Resent-Date: Fri, 25 May 2001 00:26:50 -0400 (EDT) Resent-Message-Id: <200105250426.AAA11080@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA11057 for ; Fri, 25 May 2001 00:26:42 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA20277 for ; Fri, 25 May 2001 00:26:42 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA263944; Fri, 25 May 2001 00:24:15 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id AAA85850; Fri, 25 May 2001 00:20:29 -0400 Importance: Normal To: "Eric Sedlar" Cc: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 25 May 2001 00:25:45 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 05/25/2001 12:25:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: Locking namespaces vs. resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4961 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: << There was a long discussion of locking a URL (so that a resource can't move when locked) in the fall of 1999, and in looking back through the archive, I didn't get a feeling of resolution that the spec should be changed in any way. >> We didn't resolve it, but we were close. In Dec 99 the locking discussion got defered as some of the advanced collections issues were suddenly hotly debated. << from Yaron, and there were a number of proposals to actually specify whether you wanted a namespace lock or a resource lock, rather than leaving this vague. I still think this is very useful, for performance reasons >> I assume people tend to lock resources because they want to work on them and modify them. I can't imagine one wanting to allow folks the resource they are working on unless... (1) moving it doesn't prevent them from being able to "check their modifications in". Or (2) they know there is no one that will move it. How common are these? Are there other cases? << (I think Greg Stein mentioned that mod_dav must recursively search the source directory for locks before doing a MOVE for just this reason--not a good thing) >> I think there is an alternative algorithm that can be used whereby locking marks the bindings between the locked resource and the root resource of the namespace. The cost of marking/unmarking should be O(log(n)) where n is the number of resources in the system. The cost of checking before breaking a binding should be O(1). In other words, not expensive if this algorithm can be used. Is there a problem doing this? It doesn't sound expensive. Is it? J. From w3c-dist-auth-request@w3.org Fri May 25 13:13:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21659 for ; Fri, 25 May 2001 13:13:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA17345; Fri, 25 May 2001 13:05:20 -0400 (EDT) Resent-Date: Fri, 25 May 2001 13:05:20 -0400 (EDT) Resent-Message-Id: <200105251705.NAA17345@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA17317 for ; Fri, 25 May 2001 13:05:12 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA22541 for ; Fri, 25 May 2001 13:05:11 -0400 Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f4PH1Ov14913; Fri, 25 May 2001 10:01:24 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by gmgw02.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f4PH4aj17669; Fri, 25 May 2001 10:04:36 -0700 (PDT) From: "Eric Sedlar" To: "Jason Crawford" Cc: "WebDAV WG" Date: Fri, 25 May 2001 09:57:28 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Importance: Normal Subject: RE: Issue: Locking namespaces vs. resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4962 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Thursday, May 24, 2001 9:26 PM > To: Eric Sedlar > Cc: WebDAV WG > Subject: Re: Issue: Locking namespaces vs. resources > << > There was a long discussion of locking a URL (so that a resource can't > move when locked) in the fall of 1999, and in looking back through the > archive, I didn't get a feeling of resolution that the spec should be > changed in any way. > >> > We didn't resolve it, but we were close. In Dec 99 the locking discussion > got defered as some of the advanced collections issues were suddenly hotly > debated. > That's why I brought it up. I thought we could resolve this without too much more debate. > << > from Yaron, and there were a number of proposals to actually specify > whether you wanted a namespace lock or a resource lock, rather than > leaving this vague. I still think this is very useful, for performance > reasons > >> > I assume people tend to lock resources because they want to work on them > and modify them. I can't imagine one wanting to allow folks the resource > they are working on unless... (1) moving it doesn't prevent them > from being > able to "check their modifications in". Or (2) they know there is no one > that will move it. How common are these? Are there other cases? > Geoff cited a number of cases where an administrative type of person might want to move whole directory trees while a user is editing a file. On UNIX, this wouldn't be a problem, since the client would have an open file descriptor, and the data would still get saved. In WebDAV, the client would have to process the 302 and use the new URL. > << > (I think Greg Stein mentioned that mod_dav must recursively > search the source directory for locks before doing a MOVE for just this > reason--not a good thing) > >> > I think there is an alternative algorithm that can be used whereby locking > marks the bindings between the locked resource and the root resource > of the namespace. The cost of marking/unmarking should be O(log(n)) where > n is > the number of resources in the system. The cost of checking before > breaking > a binding should be O(1). In other words, not expensive if this algorithm > can be used. Is there a problem doing this? It doesn't sound expensive. > Is > it? > O(log(n)) can still be expensive as n grows, and some people want a very large n on their website. It's not like it's horrible, though, either. Keeping track of open locks that must be moved is much easier, however, since my guess is that the number of open locks will be less than log(n) on most systems. So, allowing LOCKED files to move is still less of a performance burden. I don't care that much if we want to say that WebDAV locks must always lock the part of the namespace needed by that URL, or if we provide clients a choice (it's clear that we must provide a way to lock the namespace, though). I think we should just be clear in the spec as to what locks do, though. --Eric From w3c-dist-auth-request@w3.org Fri May 25 14:19:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22755 for ; Fri, 25 May 2001 14:19:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA19095; Fri, 25 May 2001 13:47:41 -0400 (EDT) Resent-Date: Fri, 25 May 2001 13:47:41 -0400 (EDT) Resent-Message-Id: <200105251747.NAA19095@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA19074 for ; Fri, 25 May 2001 13:47:35 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA26318 for ; Fri, 25 May 2001 13:47:35 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA24544 for ; Fri, 25 May 2001 10:47:34 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Fri, 25 May 2001 10:45:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Re: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4963 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added mikhailfranco@netscape.net to the accept2 list. - Jim -----Original Message----- From: mikhailfranco@netscape.net [mailto:mikhailfranco@netscape.net] Sent: Friday, May 25, 2001 10:21 AM To: lmnet@attglobal.net Cc: w3c-dist-auth@w3.org Subject: [Moderator Action] Re: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Larry Masinter wrote: > > The decision to use separate methods instead of just POST (which > I think was the original question) was arrived at after a lengthy > discussion; the first record I can find is from October 1996: > http://lists.w3.org/Archives/Public/w3c-dist-auth/1996OctDec/subject.html#25 > > Note that SOAP takes a different view; it only uses POST. I don't > think the considerations have changed substantially, except perhaps > that we're talking about using other headers and/or message body > elements rather than content-type to do method dispatching. WebDAV is ugly precisely because the HTTP and XML are horribly entangled. It's defined as a protocol, but the stack is not layered. It really implies a data model, yet that data model is not rigourously defined. It has taken 5+ years to define, standardize, and implement. In those 5 years the world has changed. SOAP evolved from XML-RPC, which was largely invented to perform site and content management at Userland, so the original domain and requirements are similar to WebDAV. In much less than those 5 years, SOAP has evolved from XML-RPC, been adopted by major corporations (Microsoft, IBM, etc.), is reasonaly standardized and on its way through the W3C, become the basis of all web services architectures, acquired a complete layered stack (including WSDL and UDDI), and is likely to be the basis of all future web-delivered functionality ! In the history of computing, it has often been the case that a general purpose solution, bound to a specific application domain, has delivered a more versatile, powerful, and ultimately longer-lived solution, than a bespoke specialized language or protocol. There are some high-value exceptions, like Verilog and VHDL, but flexibility usually wins in a Darwinian world requiring constant incremental adaptation. SOAP-based web service architectures rely on a design-driven process of data modelling/schemas, selecting an interface to publish, followed by auto-generation of components for service discovery, messaging, data (un)marshalling, method dispatching and invocation. If WebDAV had a data model, it would be an almost trivial task to create a web interface definition, auto-generate the communication components and publish it as an web service ! Who can doubt that if WebDAV was starting today, it would be defined as a SOAP-based service ? Mikhail __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From w3c-dist-auth-request@w3.org Fri May 25 17:30:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25450 for ; Fri, 25 May 2001 17:30:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA28495; Fri, 25 May 2001 17:25:40 -0400 (EDT) Resent-Date: Fri, 25 May 2001 17:25:40 -0400 (EDT) Resent-Message-Id: <200105252125.RAA28495@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA28471 for ; Fri, 25 May 2001 17:25:31 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA15133 for ; Fri, 25 May 2001 17:25:32 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id OAA08521; Fri, 25 May 2001 14:25:32 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" , Date: Fri, 25 May 2001 14:23:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4964 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Can't resist... > WebDAV is ugly precisely because the HTTP and XML are horribly entangled. > It's defined as a protocol, but the stack is not layered. You could make the same claim about HTTP, that it horribly entangles RFC-822 headers in with the request line of the message, without any firm layering. The simple fact is WebDAV defines a set of methods. These methods take parameters. Some parameters are encoded in headers, others in XML. People who have written DAV implementations don't have a problem with this. > It really implies a data model, yet that data model is not rigourously > defined. This is pretty typical of IETF standards, which are concerned with on-the-wire encoding, and are less interested in the underlying data model. The result is an implied, bot not normative data model. Thus, for example, even though DAV implies a data model of a resource payload plus properties, it is possible to implement this is a number of ways (Unix files + property database, NT filesystem files, database tables, as objects only comprised of attributes where a single distinguished attribute holds the payload). > SOAP evolved from XML-RPC, which was largely invented to perform site > and content management at Userland, so the original domain and > requirements are similar to WebDAV. You're confusing a marshalling and basic transport mechanism (SOAP/XML-RPC) with a semantic-rich protocol. XML-RPC and SOAP have almost no semantics whatsoever. The marshalling decisions are not the ones we spent most of our time on -- it was deciding things like "how does a locked hierarchy interact with move" and "what are the semantics of move/copy on live properties". These are tricky, subtle issues which require a lot of time to sort out in a consensus-driven standards group that is open to input from all comers, and uses a transparent process. For example, I'll note that people in W3C working groups feel no compulsion to answer random questions from newbies questioning 4 year old design decisions. Think about it. > In much less than those 5 years, SOAP has evolved > from XML-RPC, been adopted by major corporations (Microsoft, IBM, etc.), > is reasonaly standardized and on its way through the W3C, > become the basis of all web services architectures, > acquired a complete layered stack (including WSDL and UDDI), > and is likely to be the basis of all future web-delivered functionality ! Actually, I would trace the beginning of SOAP to the failed HTTP-NG effort at the W3C, which was another attempt to define a "service-oriented" infrastructure for the Web. It is no cooincidence that Henrik Nielsen was heavy involved in HTTP-NG, then went to Microsoft, and became very heavily involved in SOAP definition. Furthermore, SOAP is not nearly as far along as WebDAV in terms of adoption. Right now, people are using WebDAV in real-world settings to get their work done. There has not yet been widespread adoption of SOAP. I have no doubt that, given the marketing push by Microsoft and IBM, this will happen. But, it's not there yet, and it will take some time yet before SOAP is at the same level of standardization and adoption as WebDAV. > In the history of computing, it has often been the case that a > general purpose solution, bound to a specific application domain, > has delivered a more versatile, powerful, and ultimately longer-lived > solution, than a bespoke specialized language or protocol. So this is why Internet-based services took off using infrastructures such as RPC, ILU, and IIOP, which were also language independent marshalling formats, right? I think it is incorrect to draw any technical lessons from the adoption of SOAP. What makes SOAP different from RPC/IIOP is that Microsoft and IBM both agree on this one. That is, it is the non-technical issue of sponsorship of the standard that far outweighs any technical properties of the solution. Yes, the use of HTTP POST and XML for marshalling undoubtedly helped Microsoft and IBM agree to use SOAP, especially given the mindshare of XML in the 1999-2000 timeframe (I'll note that the same SOAP proposal would have flopped in, say 1995-96, when XML was still tainted by the stigma of SGML). > SOAP-based web service architectures rely on a design-driven process > of data modelling/schemas, selecting an interface to publish, > followed by auto-generation of components for service discovery, > messaging, data (un)marshalling, method dispatching and invocation. Except for service discovery, this is *exactly* what you did using CORBA and RPC. You created a data model, described interfaces, compiled those interfaces into marshalling and unmarshalling stubs, with method dispatching handled automatically. So, why didn't these frameworks take off for Internet use? Claiming that they don't go through firewalls is a red herring -- if a company wants to host a service, or use a service, and have a strong business need to do so, they'll make sure packets can get through. > If WebDAV had a data model, it would be an almost trivial task to > create a web interface definition, auto-generate the communication > components and publish it as an web service ! Again, the marshalling issues were not the heart of the complexity of the WebDAV protocol, and are not the heart of the complexity of WebDAV implementations. > Who can doubt that if WebDAV was starting today, > it would be defined as a SOAP-based service ? Me. I'm going to be very glad that, when administrators tell their firewalls to not admit POST (so someone in the company doesn't set up a rogue Web service and introduce a security hole), WebDAV will not be affected. - Jim From w3c-dist-auth-request@w3.org Fri May 25 18:04:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26046 for ; Fri, 25 May 2001 18:04:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA00507; Fri, 25 May 2001 18:01:37 -0400 (EDT) Resent-Date: Fri, 25 May 2001 18:01:37 -0400 (EDT) Resent-Message-Id: <200105252201.SAA00507@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA00383 for ; Fri, 25 May 2001 18:01:29 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA18151 for ; Fri, 25 May 2001 18:01:30 -0400 Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Fri, 25 May 2001 23:01:20 +0100 Received: from pldab (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 153PcI-0002G4-00; Fri, 25 May 2001 22:59:30 +0100 Date: Fri, 25 May 2001 22:59:30 +0100 (BST) From: Dan Brickley To: Jim Whitehead cc: WebDAV WG , mikhailfranco In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4965 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Fri, 25 May 2001, Jim Whitehead wrote: > For example, I'll note that people in W3C working groups feel no compulsion > to answer random questions from newbies questioning 4 year old design > decisions. Think about it. [Thinks about it... Tries to get annoyed... fails...] Thanks for the thoughtful sideswipe Jim! I might add that people in W3C working groups always decide things in secret unminuted meetings, are the happless pawns of industry tyrants, and plot to undermine the plucky freedom loving IETF groups at every opportunity. There, the secret's out. "people in W3C working groups" vary, as do the working habits of those groups. Only some of us are evil. Some of us are also people in IETF WGs... All I know is that when I try to answer questions from newbies asking about 4-year old design decisions (eg. RDF), it's not through "compulsion" but through common sense and (mailbox overload permitting) common politeness. And when I fail to manage the same, more likely its not because I'm on a W3C group, but because I'm human... While I could pass the time bickering amiably about W3C and IETF, it might nore interesting to try to get something more productive done. How about we revisit the old "how do WebDAV and RDF work together" faq? I've been hearing some nice things about Delta-V lately, maybe we could take that as practical application where RDF and WebDAV could be shown working together? As a minimum, I'd like to try to get a student project or two looking at building some prototypes. What do you reckon? Dan -- industry pawn http://purl.org/net/danbri/ From w3c-dist-auth-request@w3.org Fri May 25 18:12:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26194 for ; Fri, 25 May 2001 18:12:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA01111; Fri, 25 May 2001 18:10:48 -0400 (EDT) Resent-Date: Fri, 25 May 2001 18:10:48 -0400 (EDT) Resent-Message-Id: <200105252210.SAA01111@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA01063 for ; Fri, 25 May 2001 18:10:38 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA18955 for ; Fri, 25 May 2001 18:10:39 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id PAA17240; Fri, 25 May 2001 15:10:36 -0700 (PDT) From: "Jim Whitehead" To: "Dan Brickley" Cc: "WebDAV WG" , "mikhailfranco" Date: Fri, 25 May 2001 15:08:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4966 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit *wiping egg from face* The only purpose of my comment was a minor swipe at a well-known difference between IETF and W3C process (openness of membership, and voting vs. rough consensus). Given that it is well known, and that discussion of W3C vs IETF process is off-topic for this list, I shouldn't have even said anything in my post. I will freely admit that there is large overlap between W3C and IETF working groups, and that they are composed of very sharp, dedicated technical people working on gnarly, tough problems to produce high quality technical specifications. I will also freely admit that there are times when the W3C process achieves better results than the IETF process, HTML being an excellent example. > While I could pass the time bickering amiably about W3C and IETF, it > might nore interesting to try to get something more productive done. Agreed. I don't know what got into me today. - Jim From w3c-dist-auth-request@w3.org Fri May 25 18:25:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26396 for ; Fri, 25 May 2001 18:25:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA02052; Fri, 25 May 2001 18:24:18 -0400 (EDT) Resent-Date: Fri, 25 May 2001 18:24:18 -0400 (EDT) Resent-Message-Id: <200105252224.SAA02052@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA02032 for ; Fri, 25 May 2001 18:24:13 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA20150 for ; Fri, 25 May 2001 18:24:15 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id PAA19773 for ; Fri, 25 May 2001 15:24:16 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Fri, 25 May 2001 15:22:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: Returned mail: Remote protocol error Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4967 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I suppose the ultimate irony is that, in addition to sticking my foot in my mouth, it appears mikhailfranco@netscape.net won't actually receive my response (see below). TGIF. - Jim -----Original Message----- From: Mail Delivery Subsystem [mailto:MAILER-DAEMON@cats.ucsc.edu] Sent: Friday, May 25, 2001 3:13 PM To: ejw@cse.ucsc.edu Subject: Returned mail: Remote protocol error The original message was received at Fri, 25 May 2001 15:10:36 -0700 (PDT) from dhcp-63-177.cse.ucsc.edu [128.114.63.177] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- 554 ... Remote protocol error From w3c-dist-auth-request@w3.org Fri May 25 18:27:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26408 for ; Fri, 25 May 2001 18:27:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA02101; Fri, 25 May 2001 18:24:52 -0400 (EDT) Resent-Date: Fri, 25 May 2001 18:24:52 -0400 (EDT) Resent-Message-Id: <200105252224.SAA02101@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA02077 for ; Fri, 25 May 2001 18:24:46 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA20162 for ; Fri, 25 May 2001 18:24:46 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id PAA19879; Fri, 25 May 2001 15:24:45 -0700 (PDT) From: "Jim Whitehead" To: "Dan Brickley" Cc: "WebDAV WG" Date: Fri, 25 May 2001 15:22:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RDF and DAV properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4968 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > How > about we revisit the old "how do WebDAV and RDF work together" faq? Sure. One area of overlap is use of WebDAV Properties to store Dublin Core metadata. I went to the Dublin Core site this morning to try and determine the current status of the RDF representation of Dublin Core, and wasn't able to find a document describing a standard representation of DC in RDF. Does such a document exist? I found one working document -- can I do anything to help get that moved along (review a document, write an email, etc.)? Beyond that, it seems to me that use of RDF in DAV properties requires providing some guidance on packaging issues. Some issues include: * If I have a chunk of RDF, should I store it in one property, or in multiple properties? What are the tradeoffs? * How would XML-RPC via the DASL SEARCH method interact with RDF in DAV properties? * When should a chunk of RDF be its own resource, and when should it be stored as properties? > As a minimum, I'd like to try to get a student project > or two looking at building some prototypes. What do you reckon? Sure, this could be interesting. Many of the relationships between resources in DeltaV could be represented, in an implementation, using RDF. It would be interesting to see if an apps. framework like Redland could be used as an implementation engine for a DeltaV server. - Jim From w3c-dist-auth-request@w3.org Fri May 25 18:47:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26635 for ; Fri, 25 May 2001 18:47:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA02788; Fri, 25 May 2001 18:45:17 -0400 (EDT) Resent-Date: Fri, 25 May 2001 18:45:17 -0400 (EDT) Resent-Message-Id: <200105252245.SAA02788@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA02768 for ; Fri, 25 May 2001 18:45:10 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA21601 for ; Fri, 25 May 2001 18:45:10 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id PAA23533; Fri, 25 May 2001 15:45:09 -0700 (PDT) From: "Jim Whitehead" To: "Jim Whitehead" , "Dan Brickley" Cc: "WebDAV WG" Date: Fri, 25 May 2001 15:43:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: RDF and DAV properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4969 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > As a minimum, I'd like to try to get a student project > > or two looking at building some prototypes. What do you reckon? Another idea is to tweak the RDF photo metadata project code, described at: http://www.w3.org/TR/photo-rdf/ To use DAV properties. At present, it returns the RDF metadata using HTTP content negotiation -- ask for text/rdf or text/* and you get RDF, otherwise you get the image. Seems like it wouldn't be that difficult to add code to have Jigsaw to output this metadata information in a DAV property... - Jim From w3c-dist-auth-request@w3.org Fri May 25 20:37:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27978 for ; Fri, 25 May 2001 20:37:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA05802; Fri, 25 May 2001 20:31:36 -0400 (EDT) Resent-Date: Fri, 25 May 2001 20:31:36 -0400 (EDT) Resent-Message-Id: <200105260031.UAA05802@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA05782 for ; Fri, 25 May 2001 20:31:30 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA29097 for ; Fri, 25 May 2001 20:31:30 -0400 Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Sat, 26 May 2001 01:31:24 +0100 Received: from pldab (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 153RxQ-0002tk-00; Sat, 26 May 2001 01:29:28 +0100 Date: Sat, 26 May 2001 01:29:28 +0100 (BST) From: Dan Brickley To: Jim Whitehead cc: Dan Brickley , WebDAV WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: RDF and DAV properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4970 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Fri, 25 May 2001, Jim Whitehead wrote: > > > How > > about we revisit the old "how do WebDAV and RDF work together" faq? > > Sure. > > One area of overlap is use of WebDAV Properties to store Dublin Core > metadata. I went to the Dublin Core site this morning to try and determine > the current status of the RDF representation of Dublin Core, and wasn't able > to find a document describing a standard representation of DC in RDF. Does > such a document exist? I found one working document > -- can I > do anything to help get that moved along (review a document, write an email, > etc.)? Nudging my conscience in this fashion is as good a mechanism as any :) The DC/RDF work did indeed languish for a while. Recently we've been getting this back on track, with a new draft that makes better use of RDF's in-built facilties. The Website (particularly the dc-architecture pages, my responsibility) doesn't do the job it should in reflecting our current thinking. Anyhow, the current draft is looking good, imho. I've recently started a push for implementation testing, and would be glad to involve WebDAV folks in the review process. It's hard to know what would count as success/exit criteria, so feedback from this WG would be valued. See my msg from Weds for link to the latest draft. I intend to rectify the dc-architecture Web page situation asap. http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0105&L=dc-architecture&F=&S=&P=1852 (hmm... .exe in a url, classy...) > > Beyond that, it seems to me that use of RDF in DAV properties requires > providing some guidance on packaging issues. Some issues include: > > * If I have a chunk of RDF, should I store it in one property, or in > multiple properties? What are the tradeoffs? Yes, that's the trouble with big squiggly graph structures; they're great on the data-merging front, but when it comes to partitioning the graph into bite-sized chunks, the chunking strategy often seems somewhat arbitrary. I doubt we'll come up with one crisp answer that works for everyone. In the simple unqualified DC front, there's often a mapping onto single properties. For such purposes, my colleague Dave Beckett has worked on a simple DC-in-XML format that parses as XML, yet has a more predictable syntactic representation than arbitrary XML. This might prove of interest in the WebDAV world... http://dublincore.org/documents/dcmes-xml/ > * How would XML-RPC via the DASL SEARCH method interact with RDF in DAV > properties? I've not followed any discussion about XML-RPC-meets-DASL, though the idea (or with SOAP) sounds plausible. In RDF-land, we're starting to think about ways in which RDF query might have commonalities with XML Query, despite the difference in data models, database structure, query optimisations etc. I need to learn more about DASL before attempting to have a sensible answer on this. > * When should a chunk of RDF be its own resource, and when should it be > stored as properties? Related to the one-property vs many properties issue. One might ask the same question for XML docs on a webserver. Again, I don't know how we'd tell a good answer from a bad one. Pre RDF-meets-WebDAV, RDF docs are just new resources. If we could show some way of projecting them into the WebDAV attribute/value model, then the stored as properties approach (perhaps lossily, eg. just extracting DC) might make sense too. > > As a minimum, I'd like to try to get a student project > > or two looking at building some prototypes. What do you reckon? > > Sure, this could be interesting. Many of the relationships between > resources in DeltaV could be represented, in an implementation, using RDF. > It would be interesting to see if an apps. framework like Redland could be > used as an implementation engine for a DeltaV server. Cool! I'd like to see that attempted... Is there any test data we could play with? One problem we've had previously is little flurries of interest in this topic, with little follow through (we're all busy...). Getting the problem described adequately might be a step towards enticing someone to have a serious crack at solving it. I have a personal interest in document versioning, and the representation of workflow and transformation metadata as events, descriptions, with agent, date, time etc associated with those events. But not enough time to play with implementations :( It'd be really nice to have some Delta-V data for RDFists to take a look at though... Dan From w3c-dist-auth-request@w3.org Fri May 25 20:44:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28042 for ; Fri, 25 May 2001 20:44:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA06187; Fri, 25 May 2001 20:39:41 -0400 (EDT) Resent-Date: Fri, 25 May 2001 20:39:41 -0400 (EDT) Resent-Message-Id: <200105260039.UAA06187@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA06167 for ; Fri, 25 May 2001 20:39:35 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA29823 for ; Fri, 25 May 2001 20:39:36 -0400 Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Sat, 26 May 2001 01:39:26 +0100 Received: from pldab (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 153S6n-0002vW-00; Sat, 26 May 2001 01:39:09 +0100 Date: Sat, 26 May 2001 01:39:09 +0100 (BST) From: Dan Brickley To: Jim Whitehead cc: WebDAV WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: RDF and DAV properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4971 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Fri, 25 May 2001, Jim Whitehead wrote: > > > As a minimum, I'd like to try to get a student project > > > or two looking at building some prototypes. What do you reckon? > > Another idea is to tweak the RDF photo metadata project code, described at: > > http://www.w3.org/TR/photo-rdf/ > > To use DAV properties. At present, it returns the RDF metadata using HTTP > content negotiation -- ask for text/rdf or text/* and you get RDF, otherwise > you get the image. Seems like it wouldn't be that difficult to add code to > have Jigsaw to output this metadata information in a DAV property... Good idea! There's been a little discussion of this on the sinister and secretive W3C www-annotation list(*), http://lists.w3.org/Archives/Public/www-annotation/2001JanJun/ Since Yves is involved in RDFPic, and Libby works with me at ILRT, this might prove fun. I bought a digital camera recently so I'm all in favour of better ways of interacting with such content. And I happen to be sat on top of a wealth of interesting if unsettling image data + metadata (http://www.brisbio.ac.uk/) so there's certainly testbed content available, again perhaps student project material? Dan (*) signup: send a secret handshake.. To: www-calendar-request@w3.org Subject: subscribe From w3c-dist-auth-request@w3.org Sat May 26 14:28:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20552 for ; Sat, 26 May 2001 14:28:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05305; Sat, 26 May 2001 14:23:25 -0400 (EDT) Resent-Date: Sat, 26 May 2001 14:23:25 -0400 (EDT) Resent-Message-Id: <200105261823.OAA05305@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA05278 for ; Sat, 26 May 2001 14:23:18 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA29466 for ; Sat, 26 May 2001 14:23:19 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA345256; Sat, 26 May 2001 14:20:03 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id OAA108280; Sat, 26 May 2001 14:16:16 -0400 Importance: Normal To: "Eric Sedlar" Cc: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sat, 26 May 2001 14:09:58 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 05/26/2001 02:21:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: Locking namespaces vs. resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4972 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > I assume people tend to lock resources because they want to work on them > > and modify them. I can't imagine one wanting to allow folks the resource > > they are working on unless... (1) moving it doesn't prevent them > > from being > > able to "check their modifications in". Or (2) they know there is no one > > that will move it. How common are these? Are there other cases? > Geoff cited a number of cases where an administrative type of person might > want to move whole directory trees while a user is editing a file. On UNIX, > this wouldn't be a problem, since the client would have an open file > descriptor, and the data would still get saved. In WebDAV, the client would > have to process the 302 and use the new URL. That cites a case why people (an administrator) would want to move resource, not my point about why people would want to allow a resource that they have locked to be moved by someone else. I'm sure there are other cases where people would want to move resources and they might happen to be locked by someone else, but my point was that it doesn't seem likely that anyone would want to allow someone else to move the resource they have locked because it probably would prevent them from putting their change on the server. For this reason, if they were given a choice, I assume they'd say they'd want to lock the resource, so giving them an option doesn't seem like an effective approach. But it might be and I offered two situations where I think they might be willing to let their locked resource move, but those *seem* unlikely. > > I think there is an alternative algorithm that can be used whereby locking > > marks the bindings between the locked resource and the root resource > > ... > > a binding should be O(1). In other words, not expensive if this algorithm > > can be used. Is there a problem doing this? It doesn't sound expensive. > > Is it? > O(log(n)) can still be expensive as n grows, and some people want a very > large n on their website. I was somewhat in error. The "n" I cited for O(log(n)) the number of collections in the namespace, not the resources in the name space of that site. That obviously likely to be much smaller. In fact I just did an informal survey of 1200 websites on the web. It looks like the average depth of a resource is about 3 directories deep. At the max I saw a handful of resources at 6 levels deep. A couple sites made heavy use of resources 5 collections deep. << It's not like it's horrible, though, either. Keeping track of open locks that must be moved is much easier, however, since my guess is that the number of open locks will be less than log(n) on most systems. So, allowing LOCKED files to move is still less of a performance burden. >> Yup. I'd expect it to be less also. Just not much less. It seems like making locks also protect the namespace is the way to go. Have I missed something? J. From w3c-dist-auth-request@w3.org Sun May 27 10:46:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10322 for ; Sun, 27 May 2001 10:46:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA08896; Sun, 27 May 2001 10:40:42 -0400 (EDT) Resent-Date: Sun, 27 May 2001 10:40:42 -0400 (EDT) Resent-Message-Id: <200105271440.KAA08896@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA08876 for ; Sun, 27 May 2001 10:40:36 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA13693 for ; Sun, 27 May 2001 10:40:35 -0400 Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f4REZBD11768; Sun, 27 May 2001 07:35:11 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by gmgw02.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f4REe0j12073; Sun, 27 May 2001 07:40:00 -0700 (PDT) From: "Eric Sedlar" To: "Jason Crawford" Cc: "WebDAV WG" Date: Sun, 27 May 2001 07:32:49 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Importance: Normal Subject: RE: Issue: Locking namespaces vs. resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4973 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm perfectly happy if we clearly specify that the appropriate part of the namespace must be share LOCK'ed along with the resource. I do think that this needs to be cleared up in the spec. Jim? > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Saturday, May 26, 2001 11:10 AM > To: Eric Sedlar > Cc: WebDAV WG > Subject: RE: Issue: Locking namespaces vs. resources > > > > > > > I assume people tend to lock resources because they want to work on > them > > > and modify them. I can't imagine one wanting to allow folks the > resource > > > they are working on unless... (1) moving it doesn't prevent them > > > from being > > > able to "check their modifications in". Or (2) they know there is no > one > > > that will move it. How common are these? Are there other cases? > > > > Geoff cited a number of cases where an administrative type of person > might > > want to move whole directory trees while a user is editing a file. On > UNIX, > > this wouldn't be a problem, since the client would have an open file > > descriptor, and the data would still get saved. In WebDAV, the client > would > > have to process the 302 and use the new URL. > > That cites a case why people (an administrator) would want to move > resource, > not my point about why people would want to allow a resource that > they have > locked to be moved by someone else. I'm sure there are other cases where > people would want to move resources and they might happen to be locked by > someone else, but my point was that it doesn't seem likely > that anyone would want to allow someone else to move the resource > they have > locked because it probably would prevent them from putting their change on > the > server. For this reason, if they were given a choice, I assume they'd say > they'd > want to lock the resource, so giving them an option doesn't seem like an > effective > approach. But it might be and I offered two situations where I think they > might be > willing to let their locked resource move, but those *seem* unlikely. > > > > > I think there is an alternative algorithm that can be used whereby > locking > > > marks the bindings between the locked resource and the root resource > > > ... > > > a binding should be O(1). In other words, not expensive if this > algorithm > > > can be used. Is there a problem doing this? It doesn't sound > expensive. > > > Is it? > > O(log(n)) can still be expensive as n grows, and some people want a very > > large n on their website. > I was somewhat in error. The "n" I cited for O(log(n)) the number of > collections > in the namespace, not the resources in the name space of that site. That > obviously likely to be much smaller. In fact I just did an > informal survey > of 1200 websites on the web. It looks like the average depth of > a resource > is about 3 directories deep. At the max I saw a handful of resources at > 6 levels deep. A couple sites made heavy use of resources 5 collections > deep. > > << > It's not like it's horrible, though, either. > Keeping track of open locks that must be moved is much easier, however, > since my guess is that the number of open locks will be less than log(n) > on most systems. So, allowing LOCKED files to move is still less of a > performance burden. > >> > Yup. I'd expect it to be less also. Just not much less. > > It seems like making locks also protect the namespace is the way to go. > Have I missed something? > > J. > > > From w3c-dist-auth-request@w3.org Tue May 29 12:58:39 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06415 for ; Tue, 29 May 2001 12:58:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA11012; Tue, 29 May 2001 12:50:59 -0400 (EDT) Resent-Date: Tue, 29 May 2001 12:50:59 -0400 (EDT) Resent-Message-Id: <200105291650.MAA11012@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA10988 for ; Tue, 29 May 2001 12:50:49 -0400 (EDT) Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA08640 for ; Tue, 29 May 2001 12:50:49 -0400 From: mikhailfranco@netscape.net Received: from mikhailfranco@netscape.net by imo-d05.mx.aol.com (mail_out_v30.22.) id 3.e9.1745426 (16221); Tue, 29 May 2001 12:49:40 -0400 (EDT) Received: from netscape.com (aimmail10.aim.aol.com [205.188.144.202]) by air-in01.mx.aol.com (v77_r1.37) with ESMTP; Tue, 29 May 2001 12:49:40 -0400 Date: Tue, 29 May 2001 12:49:40 -0400 To: ejw@cse.ucsc.edu Cc: w3c-dist-auth@w3.org Mime-Version: 1.0 Message-ID: <00075098.1F6D4AA2.B102B1A8@netscape.net> References: X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: RE: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1  without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4974 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: "Jim Whitehead" wrote: > > > WebDAV is ugly precisely because the HTTP and XML are > > horribly entangled. It's defined as a protocol, > > but the stack is not layered. .. > > The simple fact is WebDAV defines a set of methods. These methods take > parameters. Some parameters are encoded in headers, others in XML. People > who have written DAV implementations don't have a problem with this. There seems to be a level-mismatch involved in changing the transport layer in order to implement high-level services, especially when it's a stateless transport layer with extremely stateful high-level functionality. This leads to awkward practical problems, such as: having to change the source code of the web server to let through new methods and status codes; having to rewrite http client libraries in order to send the extra headers and methods (e.g. java.net cannot be used for WebDAV). And these are not one-off changes, since every time a new WebDAV extension comes out, the methods, extra headers, and status codes all change. Of course, the second rewrite is implemented as a configurable set of properties, perhaps as it should have been from the start :) Perhaps the biggest benefit of layering is it enables reuse, i.e. other people are developing the other pieces: from standards, through to implementations, products and open source projects. Less work should be a powerful motivation to achieve orthogonality. > > It really implies a data model, yet that data model is not rigorously > > defined. > This is pretty typical of IETF standards, which are concerned with > on-the-wire encoding, and are less interested in the underlying > data model. The result is an implied, but not normative data model. > The marshalling decisions are not the ones we spent most of our > time on -- it was deciding things like "how does a locked hierarchy > interact with move" and "what are the semantics of move/copy on > live properties". These are tricky, subtle issues which require a lot of > time to sort out. I agree the model and semantics are harder than the transport, but all the more pity that at the end of a long process of discussing the real details of the model, you do not actually have a normative model in black and white, to hand to someone who wants to model in UML, RDF or ER. The work has been done, but the clarity is obscured by recasting the answers as a protocol. It also makes the discussions, and the final standard, very obtuse, because you get circumlocutions such as: "method postcondition: the object (which we do not really have), has a state (of which we dare not speak its name) of a certain (but unspoken) type, and the final value of this pseudo-state on this pseudo-object, should probably be X (but we can't insist)." Of course, XML has almost been broken trying to make the transition from serialization format to model-centric system (infoset, schema, query). I would argue this is more to do with the explosion of XML politics, rather than any deep technial problems, but it's hard to be sure. Perhaps the best summary of the clash of cultures between the pointy-bracket syntax-driven doc-heads and the curly-brace class-conscious object-geeks, is Ron Bourret's witty "myths": http://www.xml.com/pub/a/2000/03/08/namespaces/index.html > > In the history of computing, it has often been the case that a > > general purpose solution, bound to a specific application domain, > > has delivered a more versatile, powerful, and ultimately longer-lived > > solution, than a bespoke specialized language or protocol. > .. > I think it is incorrect to draw any technical lessons from > the adoption of SOAP. What makes SOAP different from RPC/IIOP is that > Microsoft and IBM both agree on this one. That is, it is the > non-technical issue of sponsorship of the standard that far > outweighs any technical properties of the solution. I agree that politics are more important than technical properties. But there is another important pratical aspect, and that is the general 'developability' of the technology: is it flexible ? is it easy to start developing solutions using standard tools ? does it evolve smoothly to encompass new requirements ? does it compose orthogonally with other layers and components ? etc. > > SOAP-based web service architectures rely on a design-driven process > > of data modelling/schemas, selecting an interface to publish, > > followed by auto-generation of components for service discovery, > > messaging, data (un)marshalling, method dispatching and invocation. .. > > If WebDAV had a data model, it would be an almost trivial task to > > create a web interface definition, auto-generate the communication > > components and publish it as an web service ! There's another pathway which might be more appropriate, and that is to specify WebDAV methods as WSDL interfaces, then use various class generators to spit out the comms components. This has the merit of being a closer match to the protocol, does not require a complete data model, is language independent, and should be able to bind to most existing data model implementations (given a flexible enough WSDL mapper-compiler). Here are a couple of references for (quick hack) DAV-ish web services: http://www.xmethods.net/xfs/ http://www.soapware.org/xmlStorageSystem And thanks for answering a newbie's frustrations ! Mikhail __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/