From w3c-dist-auth-request@w3.org Mon Aug 2 14:30:12 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25239 for ; Mon, 2 Aug 2004 14:30:12 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 6397CA1868; Mon, 2 Aug 2004 14:30:12 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9A73CA0C44 for ; Mon, 2 Aug 2004 14:30:09 -0400 (EDT) Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BrhZZ-0002MI-BX for w3c-dist-auth@w3.org; Mon, 02 Aug 2004 14:30:09 -0400 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Aug 2004 11:29:34 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: WebDAV From: Brian Korver Date: Mon, 2 Aug 2004 11:29:32 -0700 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 02 Aug 2004 18:29:34.0158 (UTC) FILETIME=[A8A2D6E0:01C478BE] Subject: Re: displayname and uniqueness X-Archived-At: http://www.w3.org/mid/E615E64E-E4B1-11D8-AA5A-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8742 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20040802183012.6397CA1868@frink.w3.org> Resent-Date: Mon, 2 Aug 2004 14:30:12 -0400 (EDT) Content-Transfer-Encoding: quoted-printable On Jul 30, 2004, at 4:27 AM, Geoffrey M Clemm wrote: > Brian wrote on 07/29/2004 08:11:22 PM: > > > 2518 doesn't address whether the displaynames on > > resources within a given collection must be unique. > > I presume there is no uniqueness constraint, > > That is correct. > > > but besides stating that, > > Since we cannot enumerate all constraints that do not hold, > we would only do so if this has turned out to be a source > of non-interoperability. =A0Is this the case? I'm not sure I understand what you mean. What other of constraints do you think would need to be enumerated? > > > should the spec give some > > guidance to clients on what to do when there are > > duplicates? =A0What would that guidance be? > > I'm not sure what kind of guidance you have in mind here. > Could you provide an example? I was hoping you'd be able to answer that. I suppose it could be, for instance, something as simple as "use the final element of the URL for disambiguation". > > Cheers, > Geoff > > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Mon Aug 2 18:39:50 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11529 for ; Mon, 2 Aug 2004 18:39:50 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id D74D7A1A70; Mon, 2 Aug 2004 18:39:50 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 92017A1A5F for ; Mon, 2 Aug 2004 18:39:47 -0400 (EDT) Received: from dsl081-100-205.den1.dsl.speakeasy.net ([64.81.100.205] helo=giles.cursive.net) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BrlT3-0008BV-TT for w3c-dist-auth@w3c.org; Mon, 02 Aug 2004 18:39:42 -0400 Received: from [130.129.133.207] ([130.129.133.207]) by giles.cursive.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Aug 2004 16:39:10 -0600 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Webdav WG From: Joe Hildebrand Date: Mon, 2 Aug 2004 15:39:07 -0700 X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 02 Aug 2004 22:39:10.0293 (UTC) FILETIME=[871BB050:01C478E1] Subject: High-level agenda for IETF-60 X-Archived-At: http://www.w3.org/mid/C38DA5F4-E4D4-11D8-85F8-000A959A17A6@cursive.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8743 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20040802223950.D74D7A1A70@frink.w3.org> Resent-Date: Mon, 2 Aug 2004 18:39:50 -0400 (EDT) Content-Transfer-Encoding: 7bit Lisa and I apologize for not getting this in earlier. WebDAV Agenda - Find scribe - Agenda Bash - Review of outstanding drafts - RFC2518bis - Bindings - Redirect - Non-WG drafts - PATCH - Quota I don't expect this to take the whole two hours. As part of the discussion, I expect us to cover how we expect to move forward expeditiously on all of the outstanding drafts. -- Joe Hildebrand Denver, CO, USA From w3c-dist-auth-request@w3.org Mon Aug 2 23:52:20 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27381 for ; Mon, 2 Aug 2004 23:52:19 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 98A31A0534; Mon, 2 Aug 2004 23:52:19 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 55C3DA08CF for ; Mon, 2 Aug 2004 23:52:13 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BrqKy-0003L7-Nz for w3c-dist-auth@w3.org; Mon, 02 Aug 2004 23:51:40 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i733pAOZ098266 for ; Mon, 2 Aug 2004 23:51:10 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i733qLVG124368 for ; Mon, 2 Aug 2004 23:52:21 -0400 In-Reply-To: To: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 2 Aug 2004 23:51:08 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 08/02/2004 23:51:09, Serialize complete at 08/02/2004 23:51:09 Content-Type: multipart/alternative; boundary="=_alternative 0015298B85256EE5_=" Subject: Re: displayname and uniqueness X-Archived-At: http://www.w3.org/mid/OF8CB3044F.31BF69AB-ON85256EE5.0014A1A2-85256EE5.0015298E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8744 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20040803035219.98A31A0534@frink.w3.org> Resent-Date: Mon, 2 Aug 2004 23:52:19 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 0015298B85256EE5_= Content-Type: text/plain; charset="US-ASCII" Brian wrote on 08/02/2004 02:29:32 PM: > > On Jul 30, 2004, at 4:27 AM, Geoffrey M Clemm wrote: > > Brian wrote on 07/29/2004 08:11:22 PM: > > > > > 2518 doesn't address whether the displaynames on > > > resources within a given collection must be unique. > > > I presume there is no uniqueness constraint, > > > > That is correct. > > > > > but besides stating that, > > > > Since we cannot enumerate all constraints that do not hold, > > we would only do so if this has turned out to be a source > > of non-interoperability. Is this the case? > > I'm not sure I understand what you mean. What other > of constraints do you think would need to be > enumerated? My point was just that this is one of many possible constraints that do not hold, and therefore we would need some motivation to say something about this constraint (such as that it was a source on non-interoperability). > > > should the spec give some > > > guidance to clients on what to do when there are > > > duplicates? What would that guidance be? > > > > I'm not sure what kind of guidance you have in mind here. > > Could you provide an example? > > I was hoping you'd be able to answer that. I suppose > it could be, for instance, something as simple as > "use the final element of the URL for disambiguation". I don't see that the specification can make that kind of a recommendation. It is true that every member of a single collection has a distinct final URI segment, but whether that is a useful way of disambiguating two resources for a given user is application/resource dependent. So I guess my response would be "no, the spec shouldn't give guidance to the clients on what to do when two members of a collection have the same displayname". Cheers, Geoff --=_alternative 0015298B85256EE5_= Content-Type: text/html; charset="US-ASCII"
Brian wrote on 08/02/2004 02:29:32 PM:

>
> On Jul 30, 2004, at 4:27 AM, Geoffrey M Clemm wrote:
> > Brian wrote on 07/29/2004 08:11:22 PM:
> >
> >  > 2518 doesn't address whether the displaynames on
> >  > resources within a given collection must be unique.
> >  > I presume there is no uniqueness constraint,
> >
> > That is correct.
> >
> > > but besides stating that,
> >
> > Since we cannot enumerate all constraints that do not hold,
> > we would only do so if this has turned out to be a source
> > of non-interoperability.  Is this the case?
>
> I'm not sure I understand what you mean.  What other
> of constraints do you think would need to be
> enumerated?

My point was just that this is one of many possible constraints
that do not hold, and therefore we would need some motivation
to say something about this constraint (such as that it was
a source on non-interoperability).

> > > should the spec give some
> >  > guidance to clients on what to do when there are
> >  > duplicates?  What would that guidance be?
> >
> > I'm not sure what kind of guidance you have in mind here.
> > Could you provide an example?
>
> I was hoping you'd be able to answer that.  I suppose
> it could be, for instance, something as simple as
> "use the final element of the URL for disambiguation".
I don't see that the specification can make that kind of
a recommendation.  It is true that every member of a single
collection has a distinct final URI segment, but whether that
is a useful way of disambiguating two resources for a given
user is application/resource dependent.

So I guess my response would be "no, the spec shouldn't give
guidance to the clients on what to do when two members of a
collection have the same displayname".

Cheers,
Geoff

--=_alternative 0015298B85256EE5_=-- From w3c-dist-auth-request@w3.org Thu Aug 5 16:56:01 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14006 for ; Thu, 5 Aug 2004 16:56:00 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 13D03A103B; Thu, 5 Aug 2004 16:56:02 -0400 (EDT) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9AA25A103B for ; Thu, 5 Aug 2004 16:55:57 -0400 (EDT) Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BspHG-0003Yo-4H for w3c-dist-auth@w3c.org; Thu, 05 Aug 2004 16:55:54 -0400 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.ossinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QF26JJ6M; Thu, 5 Aug 2004 14:53:10 -0600 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "'Webdav WG'" From: Joe Hildebrand Date: Thu, 5 Aug 2004 13:54:51 -0700 X-Mailer: Apple Mail (2.618) Subject: Slides for WG meeting this afternoon X-Archived-At: http://www.w3.org/mid/B1EC1FF6-E721-11D8-BADA-000A959A17A6@jabber.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8745 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20040805205602.13D03A103B@frink.w3.org> Resent-Date: Thu, 5 Aug 2004 16:56:02 -0400 (EDT) Content-Transfer-Encoding: 7bit http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg- ietf60.pdf or http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg- ietf60.ppt -- Joe Hildebrand Denver, CO, USA From w3c-dist-auth-request@w3.org Mon Aug 9 15:24:26 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01439 for ; Mon, 9 Aug 2004 15:24:26 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BuFkR-0001xP-7N; Mon, 09 Aug 2004 19:23:55 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BuFkQ-0001wq-Se for w3c-dist-auth@listhub.w3.org; Mon, 09 Aug 2004 19:23:54 +0000 Received: from natnoddy.rzone.de ([81.169.145.166]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BuFkQ-0004SR-IT for w3c-dist-auth@w3c.org; Mon, 09 Aug 2004 15:23:54 -0400 Received: from x.oberon.ethz.ch (G7aef.g.pppool.de [80.185.122.239]) by post.webmailer.de (8.12.10/8.12.10) with SMTP id i79JNpQn016770; Mon, 9 Aug 2004 21:23:52 +0200 (MEST) Date: Mon, 9 Aug 2004 21:23:51 +0200 (MEST) Message-Id: <200408091923.i79JNpQn016770@post.webmailer.de> From: edgar@edgarschwarz.de X-Mailer: Oberon Mail (ejz) on Aos 20.02.2004 To: w3c-dist-auth@w3c.org Cc: edgar@edgarschwarz.de Subject: Removing a property X-Archived-At: http://www.w3.org/mid/200408091923.i79JNpQn016770@post.webmailer.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8746 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 09 Aug 2004 19:23:55 +0000 Hi, I imagine setting an arbitrary property on a resource. What if I later decide I don't want this property anymore ? Can I remove it and how or am I stuck with setting it to some NULL value ? Cheers, Edgar -- edgar@edgarschwarz.de, Running Bluebottle www.edgarschwarz.de Make it as simple as possible, but not simpler ! Albert Einstein www.edgar-schwarz.de/cgi-bin/moin/ www.edgar-schwarz.de/cgi-bin/moin/SwOberon From w3c-dist-auth-request@w3.org Wed Aug 11 08:47:33 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00416 for ; Wed, 11 Aug 2004 08:47:32 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BusV2-0007jM-OA; Wed, 11 Aug 2004 12:46:36 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BusV2-0007iI-B4 for w3c-dist-auth@listhub.w3.org; Wed, 11 Aug 2004 12:46:36 +0000 Received: from ispmxmta06-srv.alltel.net ([166.102.165.167]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BusV2-00059I-2U for w3c-dist-auth@w3.org; Wed, 11 Aug 2004 08:46:36 -0400 Received: from D18SYX41 ([162.39.175.114]) by ispmxmta06-srv.alltel.net with SMTP id <20040811124605.SZED10030.ispmxmta06-srv.alltel.net@D18SYX41> for ; Wed, 11 Aug 2004 07:46:05 -0500 Reply-To: From: "Greg Lindstrom" To: Date: Wed, 11 Aug 2004 07:46:03 -0500 Message-ID: <004e01c47fa1$2a32c8d0$054b12ac@D18SYX41> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Subject: webDAV and Python X-Archived-At: http://www.w3.org/mid/004e01c47fa1$2a32c8d0$054b12ac@D18SYX41 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8747 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 11 Aug 2004 12:46:36 +0000 Content-Transfer-Encoding: 7bit Greetings- I would like to use Python and webDAV to transfer and process files. Can anyone point me in the right direction to get started? Any examples of how to get/put files from a webDAV server to my local machine using Python software? Thanks for your help, --greg Greg Lindstrom (501) 975-4859 NovaSys Health greg.lindstrom@novasyshealth.com "We are the music makers, and we are the dreamers of dreams" W.W. From w3c-dist-auth-request@w3.org Wed Aug 11 11:15:52 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11894 for ; Wed, 11 Aug 2004 11:15:52 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Buuop-0005XP-MK; Wed, 11 Aug 2004 15:15:11 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1Buuop-0005WC-8q for w3c-dist-auth@listhub.w3.org; Wed, 11 Aug 2004 15:15:11 +0000 Received: from server8a.software-ag.de ([193.26.193.47]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1Buuoo-0006j6-Pd for w3c-dist-auth@w3c.org; Wed, 11 Aug 2004 11:15:11 -0400 Received: from DAEMSG03.eur.ad.sag by server8a.software-ag.de; (8.11.6/8.9.3) id i7BFEZe25202; Wed, 11 Aug 2004 17:14:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Aug 2004 17:15:36 +0200 Message-ID: <0AE50E462665EB4898CACAC8DA169822416713@DAEMSG03.eur.ad.sag> Thread-Topic: Removing a property Thread-Index: AcR+Rwg/r/vbK6JqSuqIsbPXN18EhwBXpk2g From: To: Subject: RE: Removing a property X-Archived-At: http://www.w3.org/mid/0AE50E462665EB4898CACAC8DA169822416713@DAEMSG03.eur.ad.sag Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8748 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 11 Aug 2004 15:15:11 +0000 Content-Transfer-Encoding: quoted-printable How about sending the following PROPPATCH to remove BUM:myprop? - Peter. =20 > -----Original Message----- > From: w3c-dist-auth-request@w3.org=20 > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of=20 > edgar@edgarschwarz.de > Sent: Montag, 9. August 2004 21:24 > To: w3c-dist-auth@w3c.org > Cc: edgar@edgarschwarz.de > Subject: Removing a property >=20 >=20 > Hi, > I imagine setting an arbitrary property on a resource. > What if I later decide I don't want this property anymore ? > Can I remove it and how or am I stuck with setting it to some=20 > NULL value ? >=20 > Cheers, Edgar >=20 >=20 > --=20 > edgar@edgarschwarz.de, Running Bluebottle =20 > www.edgarschwarz.de > Make it as simple as possible, but not simpler ! =20 > Albert Einstein www.edgar-schwarz.de/cgi-bin/moin/=20 > www.edgar-schwarz.de/cgi-bin/moin/SwOberon >=20 >=20 >=20 From w3c-dist-auth-request@w3.org Wed Aug 11 17:29:38 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19711 for ; Wed, 11 Aug 2004 17:29:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Bv0eT-0004FP-8T; Wed, 11 Aug 2004 21:28:53 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BuzU3-0003uQ-Sh for w3c-dist-auth@listhub.w3.org; Wed, 11 Aug 2004 20:14:03 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BuzMZ-00055d-Df for w3c-dist-auth@w3c.org; Wed, 11 Aug 2004 16:06:19 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7BK6Fpp007235 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 11 Aug 2004 13:06:18 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Webdav WG From: Lisa Dusseault Date: Wed, 11 Aug 2004 13:06:10 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: New issue from meeting X-Archived-At: http://www.w3.org/mid/E3354191-EBD1-11D8-8EB5-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8749 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 11 Aug 2004 21:28:53 +0000 Content-Transfer-Encoding: 7bit At the meeting last week, Ted asked us to make sure we're clear which BNF format is used in WebDAV. RFC2518 says: Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in section 2.1 of [RFC2068]. Since this augmented BNF uses the basic production rules provided in section 2.2 of [RFC2068], these rules apply to this document as well. Is that text sufficient for RFC2518bis as well? If it is not, please suggest what more is needed. Lisa From w3c-dist-auth-request@w3.org Wed Aug 11 18:24:41 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26483 for ; Wed, 11 Aug 2004 18:24:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Bv1Vt-0001yg-L8; Wed, 11 Aug 2004 22:24:05 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1Bv1Vt-0001yB-2e for w3c-dist-auth@listhub.w3.org; Wed, 11 Aug 2004 22:24:05 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1Bv1Vs-00071L-PW for w3c-dist-auth@w3c.org; Wed, 11 Aug 2004 18:24:05 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7BMNxpp019427 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 11 Aug 2004 15:24:03 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <2088EAFA-EBE5-11D8-8EB5-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Webdav WG From: Lisa Dusseault Date: Wed, 11 Aug 2004 15:23:53 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: Announcing CalDAV development mailing list X-Archived-At: http://www.w3.org/mid/2088EAFA-EBE5-11D8-8EB5-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8750 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 11 Aug 2004 22:24:05 +0000 Content-Transfer-Encoding: 7bit I've gotten more than just nibbles on CalDAV (Calendar Access based on WebDAV), particularly in the IETF hallway discussions last week, so we've started a mailing list to discuss. http://lists.osafoundation.org/mailman/listinfo/ietf-caldav There's also a parallel effort to take the iCalendar format to Draft Standard by simplifying it -- essentially taking out non-interoperable or unimplemented features. http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Open lists, participation welcome. Lisa From w3c-dist-auth-request@w3.org Thu Aug 12 07:44:55 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25044 for ; Thu, 12 Aug 2004 07:44:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BvDze-0007Co-5l; Thu, 12 Aug 2004 11:43:38 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BvDzd-0007C8-O1 for w3c-dist-auth@listhub.w3.org; Thu, 12 Aug 2004 11:43:37 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by dr-nick.w3.org with smtp (Exim 4.32) id 1BvDzd-00047w-DM for w3c-dist-auth@w3c.org; Thu, 12 Aug 2004 07:43:37 -0400 Received: (qmail 16181 invoked by uid 65534); 12 Aug 2004 11:43:05 -0000 Received: from p50825B7D.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.91.125) by mail.gmx.net (mp018) with SMTP; 12 Aug 2004 13:43:05 +0200 X-Authenticated: #1915285 Message-ID: <411B57C7.6060007@gmx.de> Date: Thu, 12 Aug 2004 13:43:03 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Webdav WG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: New issue from meeting X-Archived-At: http://www.w3.org/mid/411B57C7.6060007@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8751 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 12 Aug 2004 11:43:38 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > At the meeting last week, Ted asked us to make sure we're clear which > BNF format is used in WebDAV. RFC2518 says: > > Since this document describes a set of extensions to the HTTP/1.1 > protocol, the augmented BNF used herein to describe protocol elements > is exactly the same as described in section 2.1 of [RFC2068]. Since > this augmented BNF uses the basic production rules provided in > section 2.2 of [RFC2068], these rules apply to this document as well. > > Is that text sufficient for RFC2518bis as well? If it is not, please > suggest what more is needed. Except for the fact that we want to refer to RFC2616 instead, I don't see any reason why this would need to be changed. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Aug 12 16:04:23 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28965 for ; Thu, 12 Aug 2004 16:04:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BvLnT-0003fQ-R8; Thu, 12 Aug 2004 20:03:35 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BvLnT-0003ep-EI for w3c-dist-auth@listhub.w3.org; Thu, 12 Aug 2004 20:03:35 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BvLnT-0007Fd-6A for w3c-dist-auth@w3c.org; Thu, 12 Aug 2004 16:03:35 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7CK3Spp025485 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 12 Aug 2004 13:03:33 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Webdav WG From: Lisa Dusseault Date: Thu, 12 Aug 2004 13:03:21 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: Previously resolved issues: COMPLIANCE_RESOURCE, MKCOL_AND_302, IMPLIED_LWS, DEEP_LOCK_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/A943C466-EC9A-11D8-8EB5-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8752 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 12 Aug 2004 20:03:35 +0000 Content-Transfer-Encoding: 7bit In the WebDAV WG meeting, we reviewed the open issues from , and found some which we believed to be closed. 12 - COMPLIANCE_RESOURCE: This was resolved in RFC2518bis in draft -02 or earlier (section 16, DAV Compliance Classes) 29 - MKCOL_AND_302: This was resolved in -02 or earlier (new section 11, "Use of HTTP status codes") 30 - IMPLIED_LWS: This was resolved in -03 by declaring that the HTTP whitespace rules apply. 37 - DEEP_LOCK_ERROR_STATUS: This was fixed in -06 by changing the text to match the example. If anybody feels these aren't resolved -- particularly if you raised that particular issue (Mark Anderson, ?, Jim Davis, Kevin Wiggen) -- let me know. Otherwise, I propose that we resolve these as "inBis" in the issue list. Lisa From w3c-dist-auth-request@w3.org Thu Aug 12 16:38:55 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05454 for ; Thu, 12 Aug 2004 16:38:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BvMLA-0006Az-CW; Thu, 12 Aug 2004 20:38:24 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BvML8-0006A4-I1 for w3c-dist-auth@listhub.w3.org; Thu, 12 Aug 2004 20:38:22 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BvML8-0005oP-8j for w3c-dist-auth@w3c.org; Thu, 12 Aug 2004 16:38:22 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7CKcEpp026937 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 12 Aug 2004 13:38:20 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <83394DF0-EC9F-11D8-8EB5-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Webdav WG From: Lisa Dusseault Date: Thu, 12 Aug 2004 13:38:05 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: Already resolved: EXTEND_UNDEFINED, LOCK_BODY_SHOULD_BE_MUST, PUT_ON_COLLECTION, LOCK_REFRESH_BODY X-Archived-At: http://www.w3.org/mid/83394DF0-EC9F-11D8-8EB5-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8753 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 12 Aug 2004 20:38:24 +0000 Content-Transfer-Encoding: 7bit More issues thought to be resolved, from the WG meeting 49 EXTEND_UNDEFINED - this was defined in rfc2518bis -02 if not earlier, so it should be resolved "InBis" 52 LOCK_BODY_SHOULD_BE_MUST - this was Overtaken By Events (OBE), so it should be resolved Closed or OBE. Explanation: recent discussion on the list concluded that a LOCK request with a body was a request for a new lock, and a LOCK request without a body was a request for a lock refresh. Obviously, it's not a MUST that a LOCK request has a body. 50 PUT_ON_COLLECTION - this should be resolved "rejected" or closed, because RFC2518 bis specifically was intended to be silent on what happens with PUT on collections. It's not an interoperability problem in practice (or at least, hasn't been reported) so there's not a strong reason to come up with something here. 60 LOCK_REFRESH_BODY - This is resolved by the text that made LOCK_BODY_SHOULD_BE_MUST into an OBE issue, in -06. (To be clear, I'm wearing my editor hat when I say that I think these are resolved. I'll leave any arbitration to Joe who can keep his chair hat on.) Lisa From w3c-dist-auth-request@w3.org Thu Aug 12 16:57:59 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07209 for ; Thu, 12 Aug 2004 16:57:59 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BvMdh-00041D-IC; Thu, 12 Aug 2004 20:57:33 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BvMdh-00040W-19 for w3c-dist-auth@listhub.w3.org; Thu, 12 Aug 2004 20:57:33 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BvMdg-0001ZO-AY for w3c-dist-auth@w3c.org; Thu, 12 Aug 2004 16:57:32 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7CKvNpp027902 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 12 Aug 2004 13:57:30 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <30AE3680-ECA2-11D8-8EB5-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Webdav WG From: Lisa Dusseault Date: Thu, 12 Aug 2004 13:57:15 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: Resolved Issues: RESOURCETYPE_EXTENSION, OPTIONS_RESPONSE_VARIES_FOR_RESOURCES, UNLOCK_WHAT_URL, MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL X-Archived-At: http://www.w3.org/mid/30AE3680-ECA2-11D8-8EB5-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8754 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 12 Aug 2004 20:57:33 +0000 Content-Transfer-Encoding: 7bit - 61 RESOURCETYPE_EXTENSION: There is now extensive text about how can be extended, and what that means, in the definition of resourcetype, as well as an example. - 64 OPTIONS_RESPONSE_VARIES_FOR_RESOURCES: We thought this should be clear enough without changing RFC2518bis further, particularly now that extensions to WebDAV exist and show all the different methods. So we could attempt to resolve this Closed. - 65 UNLOCK_WHAT_URL: I believe this should be resolved by the precondition defined in draft -06. - 66 MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL: I think the list consensus was that the server should accept a tagged list with any URL within the scope of the lock for which the token was provided. I also *believe* this is now clear (as of -06), but this is an issue where I'd particularly like people to reread and see if it's now clearer. Lisa From w3c-dist-auth-request@w3.org Thu Aug 12 19:48:14 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18054 for ; Thu, 12 Aug 2004 19:48:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BvPIE-0007wc-RM; Thu, 12 Aug 2004 23:47:34 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BvNRD-0007Px-9l for w3c-dist-auth@listhub.w3.org; Thu, 12 Aug 2004 21:48:43 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BvNKr-0001nw-0S for w3c-dist-auth@w3c.org; Thu, 12 Aug 2004 17:42:09 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7CLfvpp030671 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 12 Aug 2004 14:42:06 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <6A2B8FFA-ECA8-11D8-8EB5-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Webdav WG From: Lisa Dusseault Date: Thu, 12 Aug 2004 14:41:48 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: Resolved issues: UNLOCK_NEEDS_IF_HEADER, UNLOCK_WITHOUT_GOOD_TOKEN, LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER, IF_HEADER_CHECKS_AFTER_OTHER_CHECKS X-Archived-At: http://www.w3.org/mid/6A2B8FFA-ECA8-11D8-8EB5-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8755 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 12 Aug 2004 23:47:34 +0000 Content-Transfer-Encoding: 7bit - 67 UNLOCK_NEEDS_IF_HEADER: We haven't seen a clamor to move from using Lock-Token to using If header in UNLOCK requests. What we have now seems interoperable, so I propose we resolve this as Closed (rejected) unless people speak up. - 68 UNLOCK_WITHOUT_GOOD_TOKEN: This should now be resolved in -06. - 70 LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER: I believe this is clarified in -06 if not earlier. - 71 IF_HEADER_CHECKS_AFTER_OTHER_CHECKS: We discussed in the meeting that we could simply reject this proposal -- instead, leave it up to servers what order to do checks depending on what's fastest or easiest in that server implementation. Is the list (people who weren't there) OK with that? Lisa From w3c-dist-auth-request@w3.org Sun Aug 15 22:49:17 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16256 for ; Sun, 15 Aug 2004 22:49:16 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BwXXT-0007X8-DF; Mon, 16 Aug 2004 02:47:59 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BwXXS-0007Vz-SV for w3c-dist-auth@listhub.w3.org; Mon, 16 Aug 2004 02:47:58 +0000 Received: from homer.w3.org ([18.29.0.30]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BwXXS-0001j6-PU for w3c-dist-auth@w3.org; Sun, 15 Aug 2004 22:47:58 -0400 Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 532EE4F101 for ; Sun, 15 Aug 2004 22:47:55 -0400 (EDT) Message-Id: <4.2.0.58.J.20040816113241.05f8a360@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 16 Aug 2004 11:40:44 +0900 To: w3c-dist-auth@w3.org From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: new mailing list: public-ietf-collation@w3.org X-Archived-At: http://www.w3.org/mid/4.2.0.58.J.20040816113241.05f8a360@localhost Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8756 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 16 Aug 2004 02:47:59 +0000 Dear Webdav experts, After discussion with Chris Newman, author of the Internet Draft http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-02.txt, we have created a new mailing list, public-ietf-collation@w3.org, for discussion (and hopefully completion) of this work on identifiers for collations. This mailing list replaces an earlier one hosted at a different place. If you want to contribute or are interested in this work, please subscribe by sending mail to public-ietf-collation-REQUEST@w3.org (capitalization irrelevant) with "subscribe" (without the quotes) in the subject. The archives of this mailing list can be found at http://lists.w3.org/Archives/Public/public-ietf-collation/, and are publicly accessible. I expect discussion to begin no earlier than Monday, August 23, to allow everybody interested to subscribe. Regards, Martin. From w3c-dist-auth-request@w3.org Mon Aug 16 16:45:57 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07974 for ; Mon, 16 Aug 2004 16:45:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BwoLN-0002qQ-QY; Mon, 16 Aug 2004 20:44:37 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BwoLN-0002pv-8H for w3c-dist-auth@listhub.w3.org; Mon, 16 Aug 2004 20:44:37 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by dr-nick.w3.org with esmtp (Exim 4.32) id 1BwoLL-0006Vo-Q9 for w3c-dist-auth@w3c.org; Mon, 16 Aug 2004 16:44:37 -0400 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Aug 2004 14:41:28 -0600 Message-ID: <8D96EDA0AC04D31197B400A0C96C14800E2C646D@corp.webb.net> From: Joe Hildebrand To: agenda@ietf.org, w3c-dist-auth@w3c.org Date: Mon, 16 Aug 2004 14:41:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: Notes from IETF-60 WebDAV WG Meeting X-Archived-At: http://www.w3.org/mid/8D96EDA0AC04D31197B400A0C96C14800E2C646D@corp.webb.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8757 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 16 Aug 2004 20:44:37 +0000 Slides are here: http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-ietf60 .pdf or http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-ietf60 .ppt NOTES: Introducing Joe Hildebrand as co-chair Agenda bashing Review of outstanding drafts Reivew of RFC2518bis Last updated July 04 (version -06), recent changes mostly clarify lock behavior. Pass through beginning of issue list: http://www.webdav.org/wg/rfcdev/issues.htm - 12 COMPLIANCE_RESOURCE: Agreed to add a brief description to the text describing why we discuss compliance on a per-resource basis. Try to remove references to server compliance.This affects as bind as well and we may need to think about that some more. - 14 DEFINE_PRINCIPAL: The term "principal" is never defined in the WebDAV specification, or the HTTP or Digest specifications. It should be defined. It is defined in the ACL RFC -- copy and paste to RFC 2518. - 29 MKCOL_AND_302: The specification is ambiguous on the handling of 302 by MKCOL. It should explicitly state that MKCOL is redirected by a 302. We discussed whether all methods should be redirected by a 302, not just MKCOL. Lisa added a section to RFC2518bis that covers MKCOL as well as other methods, so possibly this should be closed. - 30 IMPLIED_LWS: The specification should explicitly note that the HTTP implied linear whitespace rule also applies to productions in the WebDAV specification. This is in 'bis' already. - 31 PUT_AND_INTERMEDIATE_COLLECTIONS: HTTP/1.1 allows PUT to create intermediate collections during PUT operation. WebDAV explicitly forbids this. This may cause problems with non-DAV-aware HTTP/1.1 authoring clients which depend on this behavior, even though the behavior is not guaranteed by HTTP/1.1 PUT. Although we've never seen HTTP clients try to PUT files on WebDAV servers, we agreed it could be useful to have a HTTP backwards-compatibility section in WebDAV. - 32 INTEROP_DELETE_AND_MULTISTATUS: An HTTP/1.1 authoring tool which issues a DELETE to a WebDAV server might receive a 207 MultiStatus response, which it would not understand. Following rules in the HTTP specification, it would then treat the 207 as a 200 (OK), and incorrectly assume the operation succeeded. Same as previous issue. - 33 OVERWRITE_DELETE_ALL_TOO_STRONG: A COPY or a MOVE with Overwrite set to True will perform a DELETE with Depth infinity at the destination of the operation. However, in the same situation, most OS's will perform a merge, rather than a DELETE. It is feared the DELETE is counter to user's expectations. Note that many OSes will warn before delete. We also realize this is not implemented as specified in some implementations, and should find out if the implementation community is split. Roy pointed out that a resource may be something other than a file or directory, that's why the rules can't simply be the same as a file system -- there was no disagreement. There were a couple suggestions how to handle this: - could have 3 states: true, false, merge (Joe) - If the server can't figure out how to do it, then return instructions as to how you do things (Brian Korver) - A client can always use "overwrite=false" and handle their own merging. (possibly Roy) Lisa pointed out that none of these approaches would actually make things more interoperable except possibly the last -- new mechanisms might not be implemented for this corner case. The other issue with this issue is that DeltaV explicitly prescribes something different on COPY to a versioned resource. Does this mean it's inconsistent with webdav? Lisa said maybe according to a strict definition, but at least it works better (otherwise a non-versioned client could cause a versioned file to go away). Larry asks if a client will see different behavior because a DeltaV server handles the COPY -- but we think that the differences will not be detectable to a non-DeltaV client, because DeltaV only redefines COPY to versioned resources, not to collections. So, do we have to change any text in this spec because of this? Lisa suggests we could change the text to put fewer constraints on futuure specs but otherwise explain to implementors that they should follow the spec wording for normal WebDAV resources. - 34 WHEN_TO_MULTISTATUS_FOR_DELETE_1: If a DELETE is issued to a collection, and it fails on all resources contained by the collection, and on the collection itself, a server should report just a single 4xx status code. But, instead the definition of DELETE indicates it should return a multistatus since an error occurred on a resource other than the Request-URI. The language needs to be tweaked so a multistatus is not required in this case. Lisa thinks this is already the case in recent versions of RFC2518bis. - 35 WHEN_TO_MULTISTATUS_FOR_DELETE_2: If a DELETE is issued to a collection, and it succeeds on all resources except the Request-URI, then it is OK for the server to report a single failure code. A multistatus response should be returned instead, and the language of DELETE should be tweaked so this is the case. Lisa thought this issue was a little confused. - 36 DATE_FORMAT_GETLASTMODIFIED: RFC 2518 specifies that the DAV:getlastmodified property must have the format specified by the HTTP-date production in RFC 2068. However, HTTP-date allows three date formats, rfc1123-date, rfc850-date, and asctime-date. Since RFC 2068 requires clients to accept all three time formats, this creates some ambiguity for whether WebDAV clients should also accept all three. The WebDAV specification should be updated to clarify that only the rfc1123-date production should be used in DAV:getlastmodified. No disagreement. - 37 DEEP_LOCK_ERROR_STATUS: Section 8.10.4 states that if a lock cannot be granted to all resources in a hierarchy, a 409 status response must be issued. Yet, the example in section 8.10.10 which demonstrates this uses a 207. Already fixed in RFC2518bis. - 38 OVERWRITE_DELETE_ERROR_STATUS: If a COPY or MOVE is submitted on a collection with Overwrite=T, if an error occurs during the delete processing associated with the Overwrite header, causing the entire operation to fail, what status should be returned? In the discussion, it seemed that using the 207 response with individual response codes for each resource was the correct approach, and Lisa needs to confirm that the spec is clear on this. - 40 LOCK_ISSUES: skipping for now - 42 MULTISTATUS_FROM_MKCOL: If MKCOL is submitted with an entity body, as permitted by RFC 2518, to create a collection and populate it, then it would make sense to return a 207 Multistatus for errors. This possibility should be made more clear in the specification. This was seen as just a clarification, seems reasonable (Joe) - 44 REPORT_OTHER_RESOURCE_LOCKED: In some cases, such as when the parent collection of a resource is locked, a 423 (Locked) status code is returned even though the resource identified by the Request-URI is not locked. This can be confusing, since it is not possible for a client to easily discover which resource is causing the locked status code to be returned. An improved status report would indicate the resource causing the lock message. Lisa reported that the list consensus is to add bodies to error codes to provide more information to the client, and this is in -06. - 47 COPY_INTO_YOURSELF_CLARIFY: RFC 2518 doesn't explicitly specify how to handle the case where a COPY with Depth infinity has a destination that is within the source hierarchy. For example, a COPY of Depth infinity of /A/ into /A/B/. One resolution is to state that the copy must behave as if the resources are first copied to a temporary location, then moved from the temporary location into the destination. - 49 EXTEND_UNDEFINED: The definition of the DAV header in section 9.1 uses a production called "extend", which is undefined in either this, or the HTTP/1.1 spec. Side discussion ensued on remembering to run the *BNF checker before submitting. The checkers use 2234, so we might want to use that. Definitely check RFC Editor errata. - 50 PUT_ON_COLLECTION: Currently, the language in section 8.7.2 does not state that a PUT is permitted on a collection. On the flip side, it doesn't state that this is forbidden either. It's just silent. The spec. should explicitly state that PUT is (or is not) permitted on a collection. The intention of RFC2518 was to leave this silent, and there was no objection in the room to continuing to be silent about PUT on collections. This issue should be resolved as closed (rejected) unless the mailing list overturns this. - 51 LEVEL_OR_CLASS: When describing compliance, the terms "level" and "class" are both used in the specification. Section 9.1 uses the term "level", while Section 15 uses the term "class". The specification should pick one and be consistent. -- which it already is. - 52 LOCK_BODY_SHOULD_BE_MUST: Section 8.10.1 states that a LOCK method request SHOULD have an XML request body. This SHOULD should instead be MUST. It was explained that recent list discussion concluded that a LOCK request that has a body is a request for a new lock, while a LOCK request without a body is a request to refresh a lock. Thus, this issue can be resolved as overtake by events. - 54 IF_AND_AUTH: The fact that use of authentication credentials with submission of lock tokens is required should be strengthened in the document. Lisa said that sometimes as author it's hard to know if you've succeeded in "clarifying" something Joe said we shall ask for verification that the clarification clarified the matter. - 55 DISPLAYNAME: There is confusion over the definition and use of the displayname property that has led to varying implementations. The default value of displayname should be specified. The behavior of displayname when there are multiple URLs for the resource needs to be clarified. this definitely needs to be taken to the list. - 56 DEPTH_LOCK_AND_IF: The specification is currently silent on how to use the If header for submitting a locktoken when performing a DELETE in a Depth infinity locked collection. Should the If header have both the collection URL and the Request-URI, or just the Request-URI? An example of this is needed. Lisa responded that 2518bis does have some clearer text on this so far, but more work might be needed. - 57 LOCK_SEMANTICS: At present, the WebDAV specification is not excruciatingly explicit that writing to a locked resource requires the combination of the lock token, plus an authentication principal. At one point, the spec. discusses an "authorized" principal, but "authorized" is never explicitly defined. Lisa believes as author that this is probably clearer now. - 59 PROPFIND_INFINITY: If a client quickly submits multiple PROPFIND, Depth: infinity requests to the top of a collection tree containing many resources, it effectively forms a denial of service (DoS) attack. Though this is noted at a high level in Section 17.2 in Security Considerations, the specific risks of a large PROPFIND should be noted there. Additionally, the specification should note whether a server is allowed to have a configuration option to disable Depth: inifinity PROPFINDs. It has been recommended that 403 (Forbidden) be returned if a server does not support Depth: infinity PROPFIND. Integer values other than 0 and 1 in PROPFIND requests were also proposed. Lisa suggested that we could make it clear that 503 could be used (from HTTP) in many situations. - 60 LOCK_REFRESH_BODY: duplicate of LOCK_BODY_SHOULD_BE_MUST - 61 RESOURCETYPE_EXTENSION: Both versioning and access control have a need to have multiple values within the DAV:resourcetype property. The specification needs to explicitly state that these multiple values are allowable, and that clients should expect this. At least one example should demonstrate that. - 63 LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY: Is the complexity of the IF header appropriate for the simple task of verifying that a client knowingly owns a lock? The IF header seems to serve a different purpose. One of those purposes is for the server to verify that you have the lock token (and that you know the root of it?). Another is for the client to check some preconditions before doing an action. Another seems to be to specify what lock to refresh in a lock refresh request. This seems to create ambiguity in our definition of the semantics of the IF: header. There was general agreement that it is too complex but that's the way the protocol is, presumably because it's not bad enough to want to break backward compatibility. - 64 OPTIONS_RESPONSE_VARIES_FOR_RESOURCES: Should the response for an OPTIONS request be expected to vary from resource to resource? What should we proscribe? What about an example for file, directories and null resources? We agreed that options vary from resource to resource, but believe that this is clear now that extensions to WebDAV exist and show how to use OPTIONS better. - 65 UNLOCK_WHAT_URL: What do you return if the unlock request specifies a URL on which the lock does not reside? What if it's on a URL that is locked by the lock, but it's not the resource where the lock is rooted? Agreed that we seem to have preconditions for this now. - 66 MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL: Right now the server uses the IF: header to verify that a client knows what locks it has that are affected by an operation before it allows the operation. Must the client provide the root URL of a lock, any URL for a pertainent loc, or some specific URL in the IF: header. Lisa thinks this is clarified - 67 UNLOCK_NEEDS_IF_HEADER: Shouldn't we be using an IF header to do an UNLOCK seeing as you need to prove you are holding a lock before you can remove it? (This might be contingent on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY). Agreed that this was probably too late to change at this stage. - 68 UNLOCK_WITHOUT_GOOD_TOKEN -- should have preconditions for these, LD to check - 69 URL_ENCODING_ISSUES: We have to resolve some issues involving encoding methods for URI's. The discussion is very involved. -- HTTP URI issue - 70 LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER: The LOCK renewal request should not us an IF header to specify what lock is being renewed. This limits the use of the IF header. Lisa thinks now well specified. - 71 IF_HEADER_CHECKS_AFTER_OTHER_CHECKS: Should we document if the IF header is evaluated before methods specific checks of afterwards. The IF header is said to be modeled after the IF-MATCH header and the documentation for that says that method specific checks should come first. It's not clear if it's feasible to make all method specific checks before checking the IF header. It's also probably easier to implement IF header checks at a common layer of code that is called before the method specific code in many implementations. BINDINGS Current issues list: http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html; The issue of whether bindings needs to explain how locks and bindings work together isn't listed there. What do we do with bindings? Options... 1. last call as-is 2. add more explicit text as requested 3. delay until rfc2518bis is completed, then refer to bis for interactions 4. extract locking out of rfc2518bis, refer to new locking draft for interactions Roy suggested to address only the real interoperability problems. Ted thought the draft needs clarification on some possible scenarios. Ted suggested that an explicit call to the mailing list seems necessary regarding whether we need clarifying text on the point mentioned (text already provided by LD on list). We noted there is precedent for splitting up a required feature out of a specification to a separate document: URLs were defined in HTTP in 2068, but out of HTTP in 2616 (2617 defined URLs). Larry said he didn't see how breaking the locking content into another draft will help. Joe said that if people think the bis draft us unclear, they should explain how. REDIRECT This was last updated to version -08 April 04. Open issues still exist. Julian proposes to defer work on this until after bindings is done. Brief discussion of whether we really need both redirect and bindings -- probably yes. PATCH This is a non WG doc that's ready for submission as a standard -- it's gotten significant review by HTTP WG, and significant support in WebDAV ( implementors are out there waiting). Lisa applied for MIME registration for application/gdiff. We asked if we want to endorce this as reviewed by WEBDAV WG, or leave them be as individual drafts? We do want to put the question to list: do you plan to support this? QUOTA draft-ietf-webdav-quota-03 -- is a WG item -- we will do WGLC call on this shortly MILESTONES AND CHARTER CHECK: Joe will discuss updated dates with authors. We may need volunteer authors if dates aren't met. -- Joe Hildebrand From w3c-dist-auth-request@w3.org Wed Aug 18 18:10:30 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25211 for ; Wed, 18 Aug 2004 18:10:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BxYcC-0004Eb-V3; Wed, 18 Aug 2004 22:09:04 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BxYcB-0004DP-RZ for w3c-dist-auth@listhub.w3.org; Wed, 18 Aug 2004 22:09:03 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.34) id 1BxYcB-0005qo-HC for w3c-dist-auth@w3c.org; Wed, 18 Aug 2004 18:09:03 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7IM8wpp005798 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 18 Aug 2004 15:09:01 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: HTTP working group , Webdav WG From: Lisa Dusseault Date: Wed, 18 Aug 2004 15:08:52 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: PATCH proposal X-Archived-At: http://www.w3.org/mid/303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8758 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 18 Aug 2004 22:09:04 +0000 Content-Transfer-Encoding: 7bit Just before the IETF I submitted a 5th revision of PATCH, containing only minor changes: http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-04.txt Does this have any outstanding issues I'm not aware of? I feel this is now quite stable and has received wide input, and is acceptable (even if not ideal) to a fairly large # of people. A number of groups have indicated they'd like to implement it (I'd like to gather more such indications -- if you intend to implement PATCH, let me know). I'd like to submit it for approval as a Proposed Standard. Lisa From w3c-dist-auth-request@w3.org Thu Aug 19 14:32:23 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22401 for ; Thu, 19 Aug 2004 14:32:22 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Bxrgr-0002B5-2U; Thu, 19 Aug 2004 18:31:09 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1Bxrgq-0002AV-KV for w3c-dist-auth@listhub.w3.org; Thu, 19 Aug 2004 18:31:08 +0000 Received: from natsmtp00.rzone.de ([81.169.145.165]) by dr-nick.w3.org with esmtp (Exim 4.34) id 1Bxrgq-0005xq-AW for w3c-dist-auth@w3c.org; Thu, 19 Aug 2004 14:31:08 -0400 Received: from x.oberon.ethz.ch (G672a.g.pppool.de [80.185.103.42]) by post.webmailer.de (8.12.10/8.12.10) with SMTP id i7JIV5vd006301; Thu, 19 Aug 2004 20:31:06 +0200 (MEST) Date: Thu, 19 Aug 2004 20:31:05 +0200 (MEST) Message-Id: <200408191831.i7JIV5vd006301@post.webmailer.de> From: edgar@edgarschwarz.de X-Mailer: Oberon Mail (ejz) on Aos 20.02.2004 To: w3c-dist-auth@w3c.org Cc: edgar@edgarschwarz.de Subject: Re: PATCH proposal X-Archived-At: http://www.w3.org/mid/200408191831.i7JIV5vd006301@post.webmailer.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8759 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 19 Aug 2004 18:31:09 +0000 Hi Lisa Lisa Dusseault wrote: > Just before the IETF I submitted a 5th revision of PATCH, containing > only minor changes: > http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-04.txt > Does this have any outstanding issues I'm not aware of? I only now got knowledge ot this thing. But after a preliminary quick reading I think it's ok. I remember asking about sending diffs to a DeltaV server once in a while on the DeltaV mailing list in the past. So I'm happy that there is a METHOD now. > I feel this is > now quite stable and has received wide input, and is acceptable (even > if not ideal) to a fairly large # of people. A number of groups have > indicated they'd like to implement it (I'd like to gather more such > indications -- if you intend to implement PATCH, let me know). I will implement it. Probably using my servers diff format at first. Cheers, Edgar -- edgar@edgarschwarz.de, Running Bluebottle www.edgarschwarz.de Make it as simple as possible, but not simpler ! Albert Einstein www.edgar-schwarz.de/cgi-bin/moin/ www.edgar-schwarz.de/cgi-bin/moin/SwOberon From w3c-dist-auth-request@w3.org Fri Aug 20 09:26:39 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12075 for ; Fri, 20 Aug 2004 09:26:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1By9Ov-0001Kp-EN; Fri, 20 Aug 2004 13:25:49 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1By9Ou-0001K6-5y for w3c-dist-auth@listhub.w3.org; Fri, 20 Aug 2004 13:25:48 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by dr-nick.w3.org with smtp (Exim 4.34) id 1By9Ot-0002Jw-Qt for w3c-dist-auth@w3c.org; Fri, 20 Aug 2004 09:25:48 -0400 Received: (qmail 21280 invoked by uid 65534); 20 Aug 2004 13:25:16 -0000 Received: from p50824C99.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.76.153) by mail.gmx.net (mp024) with SMTP; 20 Aug 2004 15:25:16 +0200 X-Authenticated: #1915285 Message-ID: <4125FBBB.1020205@gmx.de> Date: Fri, 20 Aug 2004 15:25:15 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: HTTP working group , Webdav WG References: <303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org> In-Reply-To: <303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: PATCH proposal X-Archived-At: http://www.w3.org/mid/4125FBBB.1020205@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8760 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 20 Aug 2004 13:25:49 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Just before the IETF I submitted a 5th revision of PATCH, containing > only minor changes: > > http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-04.txt > > Does this have any outstanding issues I'm not aware of? I feel this is Well, many of those I reported against version -03. I just updated my issues list and sent the list to the HTTP mailing list. > now quite stable and has received wide input, and is acceptable (even if > not ideal) to a fairly large # of people. A number of groups have > indicated they'd like to implement it (I'd like to gather more such > indications -- if you intend to implement PATCH, let me know). I'd like We intend to implement PATCH if any relevant clients (such as MacOS X or Xythos) start implementing it... > to submit it for approval as a Proposed Standard. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Aug 20 10:15:03 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15372 for ; Fri, 20 Aug 2004 10:15:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1ByAA0-0000jC-LQ; Fri, 20 Aug 2004 14:14:28 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1ByAA0-0000ih-38 for w3c-dist-auth@listhub.w3.org; Fri, 20 Aug 2004 14:14:28 +0000 Received: from mail.gmx.net ([213.165.64.20]) by dr-nick.w3.org with smtp (Exim 4.34) id 1ByA9z-0000Hg-LD for w3c-dist-auth@w3c.org; Fri, 20 Aug 2004 10:14:28 -0400 Received: (qmail 25575 invoked by uid 65534); 20 Aug 2004 14:13:56 -0000 Received: from p50824C99.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.76.153) by mail.gmx.net (mp016) with SMTP; 20 Aug 2004 16:13:56 +0200 X-Authenticated: #1915285 Message-ID: <41260721.2040707@gmx.de> Date: Fri, 20 Aug 2004 16:13:53 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: agenda@ietf.org, w3c-dist-auth@w3c.org References: <8D96EDA0AC04D31197B400A0C96C14800E2C646D@corp.webb.net> In-Reply-To: <8D96EDA0AC04D31197B400A0C96C14800E2C646D@corp.webb.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Notes from IETF-60 WebDAV WG Meeting X-Archived-At: http://www.w3.org/mid/41260721.2040707@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8761 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 20 Aug 2004 14:14:28 +0000 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: thanks for the summary. Some comments in-line. > - 12 COMPLIANCE_RESOURCE: Agreed to add a brief description to the text > describing why we discuss compliance on a per-resource basis. Try to remove > references to server compliance.This affects as bind as well and we may need > to think about that some more. I agree with the first part, but I'm not sure what the last sentence intends to say. Could you please clarify? > - 29 MKCOL_AND_302: The specification is ambiguous on the handling of > 302 by MKCOL. It should explicitly state that MKCOL is redirected by a 302. > We discussed whether all methods should be redirected by a 302, not just > MKCOL. Lisa added a section to RFC2518bis that covers MKCOL as well as > other methods, so possibly this should be closed. I'm not sure what the issue actually is. Any HTTP method can be redirected by a 3xx server response. > - 33 OVERWRITE_DELETE_ALL_TOO_STRONG: A COPY or a MOVE with Overwrite set > to True will perform a DELETE with Depth infinity at the destination of the > operation. However, in the same situation, most OS's will perform a merge, > rather than a DELETE. It is feared the DELETE is counter to user's > expectations. Note that many OSes will warn before delete. We also realize > this is not implemented as specified in some implementations, and should > find out if the implementation community is split. Roy pointed out that a > resource may be something other than a file or directory, that's why the > rules can't simply be the same as a file system -- there was no > disagreement. > > There were a couple suggestions how to handle this: > - could have 3 states: true, false, merge (Joe) > - If the server can't figure out how to do it, then return instructions as > to how you do things (Brian Korver) > - A client can always use "overwrite=false" and handle their own merging. > (possibly Roy) Lisa pointed out that none of these approaches would actually > make things more interoperable except possibly the last -- new mechanisms > might not be implemented for this corner case. > > The other issue with this issue is that DeltaV explicitly prescribes > something different on COPY to a versioned resource. Does this mean it's > inconsistent with webdav? Lisa said maybe according to a strict definition, > but at least it works better (otherwise a non-versioned client could cause a > versioned file to go away). Larry asks if a client will see different > behavior because a DeltaV server handles the COPY -- but we think that the > differences will not be detectable to a non-DeltaV client, because DeltaV > only redefines COPY to versioned resources, not to collections. I don't think I agree here. RFC3253 doesn't make any distinction here. > So, do we have to change any text in this spec because of this? Lisa > suggests we could change the text to put fewer constraints on futuure specs > but otherwise explain to implementors that they should follow the spec > wording for normal WebDAV resources. I think we should find out what servers do implement; and then update the spec accordingly. That may mean re-aligning it with RFC3253. > - 35 WHEN_TO_MULTISTATUS_FOR_DELETE_2: If a DELETE is issued to a > collection, and it succeeds on all resources except the Request-URI, then it > is OK for the server to report a single failure code. A multistatus response > should be returned instead, and the language of DELETE should be tweaked so > this is the case. Lisa thought this issue was a little confused. I think what this is asking for is not to return a 4xx status unless the whole request was rejected (and not partly successful). That seems to make sense, but it may not be what's implemented. > - 42 MULTISTATUS_FROM_MKCOL: If MKCOL is submitted with an entity body, as > permitted by RFC 2518, to create a collection and populate it, then it would > make sense to return a 207 Multistatus for errors. This possibility should > be made more clear in the specification. This was seen as just a > clarification, seems reasonable (Joe) I don't think we should say anything about that unless we're prepared to define that request body format. > - 50 PUT_ON_COLLECTION: Currently, the language in section 8.7.2 does not > state that a PUT is permitted on a collection. On the flip side, it doesn't > state that this is forbidden either. It's just silent. The spec. should > explicitly state that PUT is (or is not) permitted on a collection. The > intention of RFC2518 was to leave this silent, and there was no objection in > the room to continuing to be silent about PUT on collections. This issue > should be resolved as closed (rejected) unless the mailing list overturns > this. It doesn't need to say anything about it. > - 55 DISPLAYNAME: There is confusion over the definition and use of the > displayname property that has led to varying implementations. The default > value of displayname should be specified. The behavior of displayname when > there are multiple URLs for the resource needs to be clarified. this > definitely needs to be taken to the list. Correct. There already was a proposal to deprecate displayname because of the existing broken implementations and to define something new. > - 59 PROPFIND_INFINITY: If a client quickly submits multiple PROPFIND, > Depth: infinity requests to the top of a collection tree containing many > resources, it effectively forms a denial of service (DoS) attack. > Though this is noted at a high level in Section 17.2 in Security > Considerations, the specific risks of a large PROPFIND should be noted > there. Additionally, the specification should note whether a server is > allowed to have a configuration option to disable Depth: inifinity > PROPFINDs. It has been recommended that 403 (Forbidden) be returned if a > server does not support Depth: infinity PROPFIND. Integer values other than > 0 and 1 in PROPFIND requests were also proposed. Lisa suggested that we > could make it clear that 503 could be used (from > HTTP) in many situations. What does the definition of 503 has to do with that case? I think we should simply state that servers may reject the request and define a precondition name. > - 71 IF_HEADER_CHECKS_AFTER_OTHER_CHECKS: Should we document if the IF > header is evaluated before methods specific checks of afterwards. The IF > header is said to be modeled after the IF-MATCH header and the documentation > for that says that method specific checks should come first. It's not clear > if it's feasible to make all method specific checks before checking the IF > header. It's also probably easier to implement IF header checks at a common > layer of code that is called before the method specific code in many > implementations. Unless we find out that existing implementations happen to do this the same way, I don't think we can do anything about it today. > BINDINGS > > > Current issues list: > http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html; > The issue of whether bindings needs to explain how locks and bindings work > together isn't listed there. So what *is* that issue? The authors of BIND feel that RFC2518 (+ possibly GULP as generic clarification of WebDAV locking) clearly say how locks and binds interact. > What do we do with bindings? Options... > 1. last call as-is > 2. add more explicit text as requested > 3. delay until rfc2518bis is completed, then refer to bis for > interactions > 4. extract locking out of rfc2518bis, refer to new locking draft for > interactions > > Roy suggested to address only the real interoperability problems. Ted > thought the draft needs clarification on some possible scenarios. Ted > suggested that an explicit call to the mailing list seems necessary > regarding whether we need clarifying text on the point mentioned (text > already provided by LD on list). I haven't seen any new mails regarding this topic in the last few weeks. > We noted there is precedent for splitting up a required feature out of a > specification to a separate document: URLs were defined in HTTP in 2068, but > out of HTTP in 2616 (2617 defined URLs). Larry said he didn't see how > breaking the locking content into another draft will help. Joe said that if > people think the bis draft us unclear, they should explain how. Agreed. Basically, we do have a *very* short summary of locking semantics () which seems to reflect the consensus of the working group, and is compatible with both RFC2518 and BIND. We "just" need to make sure that what it says can be found in RFC2518bis (or whatever will be the future place for WebDAV locking). > REDIRECT > > This was last updated to version -08 April 04. Open issues still exist. > Julian proposes to defer work on this until after bindings is done. Brief > discussion of whether we really need both redirect and bindings -- probably > yes. Yes. It's different from BIND, and it adresses authoring of a popular HTTP construct. > PATCH > > This is a non WG doc that's ready for submission as a standard -- it's > gotten significant review by HTTP WG, and significant support in WebDAV ( > implementors are out there waiting). Lisa applied for MIME registration for > application/gdiff. (see comments on the ietf HTTP mailing list). > We asked if we want to endorce this as reviewed by WEBDAV WG, or leave them > be as individual drafts? We do want to put the question to list: > do you plan to support this? I'm reluctant putting new things (as previously QUOTA, btw) on our agenda unless there are signs that we do make progress with what has been on our agenda for years now. > QUOTA > > draft-ietf-webdav-quota-03 -- is a WG item -- we will do WGLC call on > this shortly There was a controversy on the mailing list back when -02 was posted. As in draft -03 there wasn't any list of changes, it's hard to say what has changed since. > MILESTONES AND CHARTER CHECK: > > Joe will discuss updated dates with authors. We may need volunteer > authors if dates aren't met. To make progress we need also: - proper issue tracking - good visibility of progress (what changed and why?) - the willingness to actually stick to our agenda The agenda states that we should have last-called BIND a few months ago. We should either do that *or* find out what's left to do so we can. Best regards, Julian Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Aug 20 11:11:27 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19705 for ; Fri, 20 Aug 2004 11:11:26 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1ByB2X-0005Mm-SS; Fri, 20 Aug 2004 15:10:49 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1By9Ms-0008LD-IX for w3c-dist-auth@listhub.w3.org; Fri, 20 Aug 2004 13:23:42 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by dr-nick.w3.org with smtp (Exim 4.34) id 1By9FU-0000jz-A0 for w3c-dist-auth@w3c.org; Fri, 20 Aug 2004 09:16:04 -0400 Received: (qmail 7788 invoked by uid 65534); 20 Aug 2004 13:15:32 -0000 Received: from p50824C99.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.76.153) by mail.gmx.net (mp017) with SMTP; 20 Aug 2004 15:15:32 +0200 X-Authenticated: #1915285 Message-ID: <4125F972.1020802@gmx.de> Date: Fri, 20 Aug 2004 15:15:30 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: HTTP working group , Webdav WG References: <303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org> In-Reply-To: <303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: PATCH proposal X-Archived-At: http://www.w3.org/mid/4125F972.1020802@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8762 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 20 Aug 2004 15:10:49 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Just before the IETF I submitted a 5th revision of PATCH, containing > only minor changes: > > http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-04.txt > > Does this have any outstanding issues I'm not aware of? I feel this is > now quite stable and has received wide input, and is acceptable (even if > not ideal) to a fairly large # of people. A number of groups have > indicated they'd like to implement it (I'd like to gather more such > indications -- if you intend to implement PATCH, let me know). I'd like > to submit it for approval as a Proposed Standard. OK, here are my updated comments. I think they should be addressed before this can go to a last-call: C-03-02, Section 2 "This specification only defines usage of the platform-portable gdiff [9] format identified as 'application/gdiff'." As far as I can tell, there is no registration for "application/gdiff". Options: 1) do the registration in this RFC (appendix) 2) have a separate RFC for the gdiff format, including a registration 3) workaround the issue by saying that in the absence of a MIME type, the gdiff format is assumed 4) ...? (Personal preference: #1) -04 update: I hear that Lisa is trying to get the MIME type registered. I don't think this will work as long as the documentation only resides in a W3C note. If PATCH is really to become an IETF standards-track document at some point of time, normative parts of it (like the GDIFF documentation) need to live in an acceptable place; I don't think a vendor note to the W3C is suitable; for instance, what do we know about IP issues with it? C-03-04, Section 3.1 "In the model defined in RFC3230 [5], the patch document is modelled as an instance being sent to the server...." It's unclear whether we are reusing RFC3250 or not. As far as I can tell, this spec is independant of RCF3250, so I'm not sure what this paragraph is trying to define. C-03-07, Sectionb 3.2.1 "The server SHOULD provide a MD5 hash of the resource entity after the delta was applied. This allows the client to verify the success of the operation. The PATCH method MUST cause the ETag to change if the resulting entity is not identical to the original. If the server supports strong ETags, the server MUST return a strong ETag for use in future client operations. The server SHOULD return the Last-Modified header in any case, but the server MUST return the Last-Modified header if ETags aren't supported." I don't like the interdependencies here. Why not simply say, in addition to the response headers that would be generated for a PUT request on that resource, the server SHOULD also provide Content-MD5. Speaking of which; it would be nice if this spec could define a standard WebDAV property holding the content MD5, sich as DAV:getcontentmd5. C-03-08, Section 3.2.2 2) Make this optional for servers that do not care about WebDAV. 3) Put the condition names into a different namespace, unless the WebDAV WG agrees to adopt these names (for instance use, urn:ietf:rfc:xxxx). 3) Stick to RFC3253's terminology (the names identify conditions, not errors, thus s/DAV:delta-format-unsupported/p:delta-format-supported/ s/DAV:delta-format-forbidden-on-resource/p:delta-format-allowed-on-resource/ s/DAV:delta-format-badly-formatted/p:delta-documented-well-formatted/ s/DAV:delta-empty-resource/p:delta-format-applies-to-empty/ S/DAV:patch-result-invalid/p:patch-result-valid/ C-03-09, Section 3.3 "OPTIONS * is not used to advertise support for PATCH because the delta formats supported are likely to change from one resource to another. A server MAY include the Accept-Patch header in response to OPTIONS *, and its value MAY be the union of known supported delta formats." I think that if this paragraph is removed, the spec still says the same thing. It doesn't add anything that doesn't already follow from RFC2616. E-03-02 "This standard defines the new method PATCH to alter a single existing resource, in place, by applying a delta or diff file." 1) It's not a standard. It may become one later. 2) The text uses the terms "delta", "diff file" and later "patch document". I think it would be wise to formally define *one* term for it once, and use that one consistently throughout. E-03-03, References URL for [9] is missing. E-04-01, Abstract I think the RFC Editor prefers abstracts that do not contain links into the references section (in particular if they're numbered and do not have symbolic names). E-04-02, References The references need to be split into normative and informative. As far as I can tell, only RFC2046 (MIME), RFC2616 (HTTP) and the GDIFF spec should be normative. Speaking of which, the reference to VCDIFF should be removed. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 23 15:22:47 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03796 for ; Mon, 23 Aug 2004 15:22:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BzKO9-0006i9-VW; Mon, 23 Aug 2004 19:21:53 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BzKO9-0006h8-Ej for w3c-dist-auth@listhub.w3.org; Mon, 23 Aug 2004 19:21:53 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.34) id 1BzKO9-000675-3W for w3c-dist-auth@w3c.org; Mon, 23 Aug 2004 15:21:53 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7NJLXpp010497 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 Aug 2004 12:21:36 -0700 In-Reply-To: <4125F972.1020802@gmx.de> References: <303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org> <4125F972.1020802@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E8E2C1C-F539-11D8-918F-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: HTTP working group , Webdav WG From: Lisa Dusseault Date: Mon, 23 Aug 2004 12:21:22 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (dr-nick.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: PATCH proposal X-Archived-At: http://www.w3.org/mid/9E8E2C1C-F539-11D8-918F-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8763 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 23 Aug 2004 19:21:53 +0000 Content-Transfer-Encoding: 7bit > > here are my updated comments. I think they should be addressed before > this can go to a last-call: I have made a few changes based on this latest round of comments, but I feel they are minor enough to be submitted in the Author's 48 hours -- e.g. replacing the word "standard" with "specification" or "draft" where standard is inaccurate, removing the unused reference. Some of these comments are the same comments as before, and I had already attempted to address most of these. Details follow inline. > > C-03-02, Section 2 > > "This specification only defines usage of the platform-portable gdiff > [9] format identified as 'application/gdiff'." > > As far as I can tell, there is no registration for > "application/gdiff". Options: > > 1) do the registration in this RFC (appendix) > 2) have a separate RFC for the gdiff format, including a registration > 3) workaround the issue by saying that in the absence of a MIME type, > the gdiff > format is assumed > 4) ...? > > (Personal preference: #1) > > -04 update: I hear that Lisa is trying to get the MIME type > registered. I > don't think this will work as long as the documentation only resides > in a > W3C note. If PATCH is really to become an IETF standards-track document > at some point of time, normative parts of it (like the GDIFF > documentation) > need to live in an acceptable place; I don't think a vendor note to > the W3C > is suitable; for instance, what do we know about IP issues with it? If the IANA says that a W3C Note is not acceptable, then I'd certainly act on that. But we don't need to resolve all IP issues precisely because GDIFF is not proposed as an IETF standard or specified in a standards-track IETF document. > > > C-03-04, Section 3.1 > > "In the model defined in RFC3230 [5], the patch document is modelled > as an instance being sent to the server...." > > It's unclear whether we are reusing RFC3250 or not. As far as I can > tell, > this spec is independant of RCF3250, so I'm not sure what this > paragraph > is trying to define. As I've said, this paragraph defines how a client can be compliant with both PATCH and RFC3230. If it's not specified whether the PATCH document is itself an instance or an instance manipulation, clients and servers could have difficulty interoperating if they implemented both PATCH and RFC3230. > > > C-03-07, Sectionb 3.2.1 > > "The server SHOULD provide a MD5 hash of the resource entity after the > delta was applied. This allows the client to verify the success of > the operation. The PATCH method MUST cause the ETag to change if the > resulting entity is not identical to the original. If the server > supports strong ETags, the server MUST return a strong ETag for use > in future client operations. The server SHOULD return the > Last-Modified header in any case, but the server MUST return the > Last-Modified header if ETags aren't supported." > > I don't like the interdependencies here. Why not simply say, in > addition > to the response headers that would be generated for a PUT request on > that > resource, the server SHOULD also provide Content-MD5. > > Speaking of which; it would be nice if this spec could define a > standard > WebDAV property holding the content MD5, sich as DAV:getcontentmd5. Section 3.2.1 seems clear to me, perhaps you could be more clear what you mean about "don't like the interdependencies here"? The text about returning a strong ETag is important and not redundant or interdependent with the text about the MD5 hash. Defining new WebDAV properties is out of scope; PATCH does not depend on WebDAV. I would welcome specification of such a property elsewhere. > > > C-03-08, Section 3.2.2 > > 2) Make this optional for servers that do not care about WebDAV. This section has nothing to do with support for WebDAV on either side. HTTP clients supporting PATCH can use error messages in the body just as well as WebDAV clients do. I do not agree with making it optional at any rate; it's easy for the server, optional for the client, and promotes interoperability. > > 3) Put the condition names into a different namespace, unless the > WebDAV WG > agrees to adopt these names (for instance use, urn:ietf:rfc:xxxx). The WebDAV WG has many chances to review this draft and object to the use of the DAV: namespace. I interpret silence as consent to adopt these names. > > 3) Stick to RFC3253's terminology (the names identify conditions, not > errors, thus > > s/DAV:delta-format-unsupported/p:delta-format-supported/ > s/DAV:delta-format-forbidden-on-resource/p:delta-format-allowed-on- > resource/ > s/DAV:delta-format-badly-formatted/p:delta-documented-well-formatted/ > s/DAV:delta-empty-resource/p:delta-format-applies-to-empty/ > S/DAV:patch-result-invalid/p:patch-result-valid/ As you know from this and other specs, I am sticking to the HTTP approach, describing the error rather than the condition that would be a lack of an error. Describing the error is far more natural (in many protocols, not just HTTP) and promotes readability of the spec and of the error responses when they're encountered by programmers or analysts. > > > C-03-09, Section 3.3 > > "OPTIONS * is not used to advertise support for PATCH because the > delta formats supported are likely to change from one resource to > another. A server MAY include the Accept-Patch header in response to > OPTIONS *, and its value MAY be the union of known supported delta > formats." > > I think that if this paragraph is removed, the spec still says the same > thing. It doesn't add anything that doesn't already follow from > RFC2616. > What "follows from RFC2616" differs for many people. I added this paragraph because there was lots of confusion and discussion about the appropriateness of OPTIONS *. A reader of this spec shouldn't need to read the entire mailing lists to understand how OPTIONS * might work in this situation. Besides, this helps servers that do support OPTIONS * do so in a consistent manner -- showing the union of supported delta formats, rather than some other value in the Accept-Patch header. > > E-03-02 > > "This standard defines the new method PATCH to alter a single existing > resource, in place, by applying a delta or diff file." > > 1) It's not a standard. It may become one later. OK; I've fixed this in my local copy and will submit in Auth 48 unless there is an earlier opportunity. > > 2) The text uses the terms "delta", "diff file" and later "patch > document". > I think it would be wise to formally define *one* term for it once, and > use that one consistently throughout. OK; I've become more consistent in my local copy and will submit in Auth 48 unless there is an earlier opportunity. > > > E-03-03, References > > URL for [9] is missing. URLs aren't strictly required, so until I can figure out how to include it (help appreciated here) it's going to continue to be missing. I think this can be added in Auth48 unless there is an earlier opportunity. > > > E-04-01, Abstract > > I think the RFC Editor prefers abstracts that do not contain links into > the references section (in particular if they're numbered and do not > have symbolic names). I'd be happy to change that in Auth 48; I wasn't aware of this preference. Presumably the RFC Editor will also make me aware of this. > > > E-04-02, References > > The references need to be split into normative and informative. As far > as > I can tell, only RFC2046 (MIME), RFC2616 (HTTP) and the GDIFF spec > should > be normative. Speaking of which, the reference to VCDIFF should be > removed. I've removed VCDIFF, thanks. I'm actually not sure with the XML format how to split references into normative and informative, but I'd be happy to do so. > > > Best regards, Julian > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Mon Aug 23 16:02:42 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06498 for ; Mon, 23 Aug 2004 16:02:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BzL11-0007Kj-5i; Mon, 23 Aug 2004 20:02:03 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BzL10-0007K5-M3 for w3c-dist-auth@listhub.w3.org; Mon, 23 Aug 2004 20:02:02 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by dr-nick.w3.org with smtp (Exim 4.34) id 1BzL10-00077V-3a for w3c-dist-auth@w3c.org; Mon, 23 Aug 2004 16:02:02 -0400 Received: (qmail 13519 invoked by uid 65534); 23 Aug 2004 20:01:24 -0000 Received: from pD9FF0875.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.8.117) by mail.gmx.net (mp018) with SMTP; 23 Aug 2004 22:01:24 +0200 X-Authenticated: #1915285 Message-ID: <412A4D0D.1020300@gmx.de> Date: Mon, 23 Aug 2004 22:01:17 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: HTTP working group , Webdav WG References: <303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org> <4125F972.1020802@gmx.de> <9E8E2C1C-F539-11D8-918F-000A95B2BB72@osafoundation.org> In-Reply-To: <9E8E2C1C-F539-11D8-918F-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (dr-nick.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: PATCH proposal X-Archived-At: http://www.w3.org/mid/412A4D0D.1020300@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8764 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 23 Aug 2004 20:02:03 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >> here are my updated comments. I think they should be addressed before >> this can go to a last-call: > > > I have made a few changes based on this latest round of comments, but I > feel they are minor enough to be submitted in the Author's 48 hours -- > e.g. replacing the word "standard" with "specification" or "draft" > where standard is inaccurate, removing the unused reference. Some of > these comments are the same comments as before, and I had already > attempted to address most of these. Details follow inline. Lisa, I think this draft should go through a mailing list last-call; and it should also not be submitted until open issues are resolved. Doing it after submission simply creates a lot of additional work in the publication process. >> C-03-02, Section 2 >> >> "This specification only defines usage of the platform-portable gdiff >> [9] format identified as 'application/gdiff'." >> >> As far as I can tell, there is no registration for >> "application/gdiff". Options: >> >> 1) do the registration in this RFC (appendix) >> 2) have a separate RFC for the gdiff format, including a registration >> 3) workaround the issue by saying that in the absence of a MIME type, >> the gdiff >> format is assumed >> 4) ...? >> >> (Personal preference: #1) >> >> -04 update: I hear that Lisa is trying to get the MIME type >> registered. I >> don't think this will work as long as the documentation only resides >> in a >> W3C note. If PATCH is really to become an IETF standards-track document >> at some point of time, normative parts of it (like the GDIFF >> documentation) >> need to live in an acceptable place; I don't think a vendor note to >> the W3C >> is suitable; for instance, what do we know about IP issues with it? > > > If the IANA says that a W3C Note is not acceptable, then I'd certainly > act on that. But we don't need to resolve all IP issues precisely > because GDIFF is not proposed as an IETF standard or specified in a > standards-track IETF document. Well, if PATCH requires support for GDIFF, it's part of the PATCH spec (by normative reference). >> C-03-04, Section 3.1 >> >> "In the model defined in RFC3230 [5], the patch document is modelled >> as an instance being sent to the server...." >> >> It's unclear whether we are reusing RFC3250 or not. As far as I can >> tell, >> this spec is independant of RCF3250, so I'm not sure what this paragraph >> is trying to define. > > > As I've said, this paragraph defines how a client can be compliant with > both PATCH and RFC3230. If it's not specified whether the PATCH > document is itself an instance or an instance manipulation, clients and > servers could have difficulty interoperating if they implemented both > PATCH and RFC3230. I appreciate if this is clarified; maybe the paragraph needs to be expanded and/or moved into a separate section (interdependencies with other specs)? >> C-03-07, Sectionb 3.2.1 >> >> "The server SHOULD provide a MD5 hash of the resource entity after the >> delta was applied. This allows the client to verify the success of >> the operation. The PATCH method MUST cause the ETag to change if the >> resulting entity is not identical to the original. If the server >> supports strong ETags, the server MUST return a strong ETag for use >> in future client operations. The server SHOULD return the >> Last-Modified header in any case, but the server MUST return the >> Last-Modified header if ETags aren't supported." >> >> I don't like the interdependencies here. Why not simply say, in addition >> to the response headers that would be generated for a PUT request on >> that >> resource, the server SHOULD also provide Content-MD5. >> >> Speaking of which; it would be nice if this spec could define a standard >> WebDAV property holding the content MD5, sich as DAV:getcontentmd5. > > > Section 3.2.1 seems clear to me, perhaps you could be more clear what > you mean about "don't like the interdependencies here"? The text about > returning a strong ETag is important and not redundant or > interdependent with the text about the MD5 hash. I feel the current wording is problematic in that it is a cascade of conditional statements. Whatever makes this simpler and basically provides the same would be preferrable; thus my proposal. > Defining new WebDAV properties is out of scope; PATCH does not depend > on WebDAV. I would welcome specification of such a property elsewhere. > >> C-03-08, Section 3.2.2 >> >> 2) Make this optional for servers that do not care about WebDAV. > > > This section has nothing to do with support for WebDAV on either side. > HTTP clients supporting PATCH can use error messages in the body just > as well as WebDAV clients do. I do not agree with making it optional > at any rate; it's easy for the server, optional for the client, and > promotes interoperability. As developer of WebDAV servers, I don't have any problem with that. However, I feel that there are people out there who'd prefer to have zero dependencies on WebDAV or related specs; and IMHO we should respect that. >> 3) Put the condition names into a different namespace, unless the >> WebDAV WG >> agrees to adopt these names (for instance use, urn:ietf:rfc:xxxx). > > > The WebDAV WG has many chances to review this draft and object to the > use of the DAV: namespace. I interpret silence as consent to adopt > these names. With all due respect: I'm a member of the WebDAV WG and I have objected to this. This is *not* 'silence'! If you want to use the DAV: namespace, send an *explicit* request to the mailing list and try to get consensur in favor of it. >> 3) Stick to RFC3253's terminology (the names identify conditions, not >> errors, thus >> >> s/DAV:delta-format-unsupported/p:delta-format-supported/ >> s/DAV:delta-format-forbidden-on-resource/p:delta-format-allowed-on- >> resource/ >> s/DAV:delta-format-badly-formatted/p:delta-documented-well-formatted/ >> s/DAV:delta-empty-resource/p:delta-format-applies-to-empty/ >> S/DAV:patch-result-invalid/p:patch-result-valid/ > > > As you know from this and other specs, I am sticking to the HTTP > approach, describing the error rather than the condition that would be > a lack of an error. Describing the error is far more natural (in many > protocols, not just HTTP) and promotes readability of the spec and of > the error responses when they're encountered by programmers or analysts. Once you pick an existing protocol element - stick with it's semantics. I'm not saying that identifying errors instead of conditions by itself is bad; but it's inconsistent with what RFC3253 (from which you borrow) defines. If you don't like the semantics of a protocol element, by all means do NOT reuse it with silently changed semantics. >> C-03-09, Section 3.3 >> >> "OPTIONS * is not used to advertise support for PATCH because the >> delta formats supported are likely to change from one resource to >> another. A server MAY include the Accept-Patch header in response to >> OPTIONS *, and its value MAY be the union of known supported delta >> formats." >> >> I think that if this paragraph is removed, the spec still says the same >> thing. It doesn't add anything that doesn't already follow from RFC2616. >> > > What "follows from RFC2616" differs for many people. I added this (shouldn't) > paragraph because there was lots of confusion and discussion about the > appropriateness of OPTIONS *. A reader of this spec shouldn't need to > read the entire mailing lists to understand how OPTIONS * might work in > this situation. Besides, this helps servers that do support OPTIONS * > do so in a consistent manner -- showing the union of supported delta > formats, rather than some other value in the Accept-Patch header. I still think this is a mistake. Following your line of argument, any HTTP-related spec would need to explain how it doesn't affect the semantics of "OPTIONS *". >> E-03-03, References >> >> URL for [9] is missing. > > > URLs aren't strictly required, so until I can figure out how to include > it (help appreciated here) it's going to continue to be missing. I > think this can be added in Auth48 unless there is an earlier opportunity. 381c380 < --- > >> E-04-01, Abstract >> >> I think the RFC Editor prefers abstracts that do not contain links into >> the references section (in particular if they're numbered and do not >> have symbolic names). > > > I'd be happy to change that in Auth 48; I wasn't aware of this > preference. Presumably the RFC Editor will also make me aware of this. Well, now you are. Abstracts are copied as is into other documents; and references (in particular numbered) then do not work anymore. >> E-04-02, References >> >> The references need to be split into normative and informative. As >> far as >> I can tell, only RFC2046 (MIME), RFC2616 (HTTP) and the GDIFF spec >> should >> be normative. Speaking of which, the reference to VCDIFF should be >> removed. > > > I've removed VCDIFF, thanks. I'm actually not sure with the XML format > how to split references into normative and informative, but I'd be > happy to do so. See , "Helpful Hints". Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 23 17:49:17 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18660 for ; Mon, 23 Aug 2004 17:49:17 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BzMgE-0000v1-MZ; Mon, 23 Aug 2004 21:48:42 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BzMgD-0000uF-M2 for w3c-dist-auth@listhub.w3.org; Mon, 23 Aug 2004 21:48:41 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by dr-nick.w3.org with esmtp (Exim 4.34) id 1BzMgD-00019N-Ad for w3c-dist-auth@w3c.org; Mon, 23 Aug 2004 17:48:41 -0400 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7NLmUpp019611 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 Aug 2004 14:48:31 -0700 In-Reply-To: <412A4D0D.1020300@gmx.de> References: <303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org> <4125F972.1020802@gmx.de> <9E8E2C1C-F539-11D8-918F-000A95B2BB72@osafoundation.org> <412A4D0D.1020300@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <281EAC1C-F54E-11D8-912D-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: HTTP working group , Webdav WG From: Lisa Dusseault Date: Mon, 23 Aug 2004 14:48:23 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (dr-nick.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: PATCH proposal X-Archived-At: http://www.w3.org/mid/281EAC1C-F54E-11D8-912D-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8765 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 23 Aug 2004 21:48:42 +0000 Content-Transfer-Encoding: 7bit > I think this draft should go through a mailing list last-call; and it > should also not be submitted until open issues are resolved. Doing it > after submission simply creates a lot of additional work in the > publication process. I believe that it *is* going through a mailing list last-call, as much as an independent submission that is not being adopted by a WG ever goes through a WG mailing list last call. It will also go through IETF mailing list call, as a matter of course. Anyway, as far as making changes after submission, since you suggested a reasonable reorg (a new section on interdependencies with other standards), and since I realized that security considerations were missing, the changes based on your comments are now definitely going to require another draft version. I will be publishing draft -05 shortly if I don't get any more comments, now that PATCH has gone through several drafts without any material changes, perhaps -05 will be the draft to be submitted for RFC. > >>> C-03-04, Section 3.1 >>> >>> "In the model defined in RFC3230 [5], the patch document is modelled >>> as an instance being sent to the server...." >>> >>> It's unclear whether we are reusing RFC3250 or not. As far as I can >>> tell, >>> this spec is independant of RCF3250, so I'm not sure what this >>> paragraph >>> is trying to define. >> As I've said, this paragraph defines how a client can be compliant >> with both PATCH and RFC3230. If it's not specified whether the >> PATCH document is itself an instance or an instance manipulation, >> clients and servers could have difficulty interoperating if they >> implemented both PATCH and RFC3230. > > I appreciate if this is clarified; maybe the paragraph needs to be > expanded and/or moved into a separate section (interdependencies with > other specs)? I can do that; thanks for the specific suggestion. > >>> C-03-07, Sectionb 3.2.1 >>> >>> "The server SHOULD provide a MD5 hash of the resource entity after >>> the >>> delta was applied. This allows the client to verify the success of >>> the operation. The PATCH method MUST cause the ETag to change if the >>> resulting entity is not identical to the original. If the server >>> supports strong ETags, the server MUST return a strong ETag for use >>> in future client operations. The server SHOULD return the >>> Last-Modified header in any case, but the server MUST return the >>> Last-Modified header if ETags aren't supported." >>> >>> I don't like the interdependencies here. Why not simply say, in >>> addition >>> to the response headers that would be generated for a PUT request on >>> that >>> resource, the server SHOULD also provide Content-MD5. >>> >>> Speaking of which; it would be nice if this spec could define a >>> standard >>> WebDAV property holding the content MD5, sich as DAV:getcontentmd5. >> Section 3.2.1 seems clear to me, perhaps you could be more clear what >> you mean about "don't like the interdependencies here"? The text >> about returning a strong ETag is important and not redundant or >> interdependent with the text about the MD5 hash. > > I feel the current wording is problematic in that it is a cascade of > conditional statements. Whatever makes this simpler and basically > provides the same would be preferrable; thus my proposal. OK, I can make it more clear that the ETag sentences do not depend on the MD5 usage. I think the main problem is that I forgot to put between the first and second sentence. And I can simplify the requirements for Last-Modified: The server SHOULD provide a MD5 hash of the resource entity after the patch was applied. This allows the client to verify the success of the operation. As with PUT, the PATCH method MUST change the resource's ETag if the resulting entity is not identical to the original. If the server supports strong ETags, the server MUST return a strong ETag for use in future client operations. The server MUST return the Last-Modified header if it does not support strong ETags. > >> Defining new WebDAV properties is out of scope; PATCH does not depend >> on WebDAV. I would welcome specification of such a property >> elsewhere. > > >>> C-03-08, Section 3.2.2 >>> >>> 2) Make this optional for servers that do not care about WebDAV. >> This section has nothing to do with support for WebDAV on either >> side. HTTP clients supporting PATCH can use error messages in the >> body just as well as WebDAV clients do. I do not agree with making >> it optional at any rate; it's easy for the server, optional for the >> client, and promotes interoperability. > > As developer of WebDAV servers, I don't have any problem with that. > However, I feel that there are people out there who'd prefer to have > zero dependencies on WebDAV or related specs; and IMHO we should > respect that. IMHO we are respecting that. This doesn't require a server to implement any WebDAV features or even read the DeltaV spec. > >>> 3) Put the condition names into a different namespace, unless the >>> WebDAV WG >>> agrees to adopt these names (for instance use, urn:ietf:rfc:xxxx). >> The WebDAV WG has many chances to review this draft and object to the >> use of the DAV: namespace. I interpret silence as consent to adopt >> these names. > > With all due respect: I'm a member of the WebDAV WG and I have > objected to this. This is *not* 'silence'! If you want to use the DAV: > namespace, send an *explicit* request to the mailing list and try to > get consensur in favor of it. I misunderstood. Do you think it is wrong to use the "DAV:" namespace? If you think it is wrong, please say so. I thought you said that the WG should agree to the use of the namespace, which is what we're doing. This is an explicit discussion on the mailing list about whether that's OK. I personally think it's OK but will replace the namespace if I get a bunch of objections. > >>> 3) Stick to RFC3253's terminology (the names identify conditions, >>> not errors, thus >>> >>> s/DAV:delta-format-unsupported/p:delta-format-supported/ >>> s/DAV:delta-format-forbidden-on-resource/p:delta-format-allowed-on- >>> resource/ >>> s/DAV:delta-format-badly-formatted/p:delta-documented-well-formatted/ >>> s/DAV:delta-empty-resource/p:delta-format-applies-to-empty/ >>> S/DAV:patch-result-invalid/p:patch-result-valid/ >> As you know from this and other specs, I am sticking to the HTTP >> approach, describing the error rather than the condition that would >> be a lack of an error. Describing the error is far more natural (in >> many protocols, not just HTTP) and promotes readability of the spec >> and of the error responses when they're encountered by programmers >> or analysts. > > Once you pick an existing protocol element - stick with it's > semantics. I'm not saying that identifying errors instead of > conditions by itself is bad; but it's inconsistent with what RFC3253 > (from which you borrow) defines. If you don't like the semantics of a > protocol element, by all means do NOT reuse it with silently changed > semantics. They're just string constants so there is no silently changed semantics. The interpretation is different but they're machine-readable codes. At this point, I think we disagree on a naming convention and can agree to disagree on the tradeoffs between consistency and readability. I didn't think it was so important that I was willing to hold up DeltaV so that DeltaV would do it my way. > >>> C-03-09, Section 3.3 >>> >>> "OPTIONS * is not used to advertise support for PATCH because the >>> delta formats supported are likely to change from one resource to >>> another. A server MAY include the Accept-Patch header in response to >>> OPTIONS *, and its value MAY be the union of known supported delta >>> formats." >>> >>> I think that if this paragraph is removed, the spec still says the >>> same >>> thing. It doesn't add anything that doesn't already follow from >>> RFC2616. >>> >> What "follows from RFC2616" differs for many people. I added this > > (shouldn't) Huh? Are you saying that RFC2616 implications shouldn't differ for many people? Does that mean: "RFC2616 is so clear that everybody reading it draws the same conclusions even about how extensions to RFC2616 might work" or "RFC2616 should be (but isn't) so clear that everybody reading it draws the same conclusions even about how extensions to RFC2616 might work" Or something else? And what does this imply for PATCH? > >> paragraph because there was lots of confusion and discussion about >> the appropriateness of OPTIONS *. A reader of this spec shouldn't >> need to read the entire mailing lists to understand how OPTIONS * >> might work in this situation. Besides, this helps servers that do >> support OPTIONS * do so in a consistent manner -- showing the union >> of supported delta formats, rather than some other value in the >> Accept-Patch header. > > I still think this is a mistake. Following your line of argument, any > HTTP-related spec would need to explain how it doesn't affect the > semantics of "OPTIONS *". Yup. That is, in fact, my line of argument -- any HTTP-related spec that extends the OPTIONS response needs to explain how that extension works for OPTIONS *. > >>> E-03-03, References >>> >>> URL for [9] is missing. >> URLs aren't strictly required, so until I can figure out how to >> include it (help appreciated here) it's going to continue to be >> missing. I think this can be added in Auth48 unless there is an >> earlier opportunity. > > 381c380 > < > --- > > target="http://www.w3.org/TR/NOTE-gdiff-19970901"> Thanks! >>> E-04-02, References >>> >>> The references need to be split into normative and informative. As >>> far as >>> I can tell, only RFC2046 (MIME), RFC2616 (HTTP) and the GDIFF spec >>> should >>> be normative. Speaking of which, the reference to VCDIFF should be >>> removed. >> I've removed VCDIFF, thanks. I'm actually not sure with the XML >> format how to split references into normative and informative, but >> I'd be happy to do so. > > See , "Helpful Hints". For some reason, at some point, I thought my validator was complaining about this, so I took it out in some prior draft. But now it works. Thanks again. Lisa From w3c-dist-auth-request@w3.org Tue Aug 24 04:03:35 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11387 for ; Tue, 24 Aug 2004 04:03:35 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BzWG5-0002qF-03; Tue, 24 Aug 2004 08:02:21 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BzWG4-0002pX-8t for w3c-dist-auth@listhub.w3.org; Tue, 24 Aug 2004 08:02:20 +0000 Received: from dsl081-100-205.den1.dsl.speakeasy.net ([64.81.100.205] helo=giles.cursive.net) by dr-nick.w3.org with esmtp (Exim 4.34) id 1BzWG4-0008JY-0v for w3c-dist-auth@w3c.org; Tue, 24 Aug 2004 04:02:20 -0400 Received: from [10.99.2.1] ([10.99.2.1]) by giles.cursive.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 02:01:48 -0600 In-Reply-To: <281EAC1C-F54E-11D8-912D-000A95B2BB72@osafoundation.org> References: <303F0034-F163-11D8-8827-000A95B2BB72@osafoundation.org> <4125F972.1020802@gmx.de> <9E8E2C1C-F539-11D8-918F-000A95B2BB72@osafoundation.org> <412A4D0D.1020300@gmx.de> <281EAC1C-F54E-11D8-912D-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Julian Reschke , HTTP working group , Webdav WG From: Joe Hildebrand Date: Tue, 24 Aug 2004 02:01:47 -0600 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 24 Aug 2004 08:01:48.0182 (UTC) FILETIME=[9B0D8360:01C489B0] Received-SPF: none (dr-nick.w3.org: domain of hildjj@cursive.net does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: PATCH proposal X-Archived-At: http://www.w3.org/mid/D8B3417B-F5A3-11D8-8BA1-000A959A17A6@cursive.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8766 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 24 Aug 2004 08:02:21 +0000 Content-Transfer-Encoding: 7bit > I misunderstood. Do you think it is wrong to use the "DAV:" > namespace? If you think it is wrong, please say so. I thought you > said that the WG should agree to the use of the namespace, which is > what we're doing. This is an explicit discussion on the mailing list > about whether that's OK. > > I personally think it's OK but will replace the namespace if I get a > bunch of objections. (in personal voice, not chair voice) I think it's probably best to use another namespace. - I don't like DAV: to begin with :) - This isn't a WG doc - Given those two, I wouldn't want to set a precedent for others to go throwing stuff into DAV: We've had the same problem with the jabber: namespaces in the XMPP space. It's taken us a long time to get everyone to use namespace URI's that they actually control in their protocols, but it's been well worth the effort in terms of being able to do many more extensions in parallel. -- Joe Hildebrand Denver, CO, USA From w3c-dist-auth-request@w3.org Tue Aug 24 07:28:11 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26301 for ; Tue, 24 Aug 2004 07:28:10 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1BzZSU-0008EC-MY; Tue, 24 Aug 2004 11:27:22 +0000 Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp (Exim 4.34) id 1BzZSS-0008DG-3i for w3c-dist-auth@listhub.w3.org; Tue, 24 Aug 2004 11:27:20 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by dr-nick.w3.org with esmtp (Exim 4.34) id 1BzZSR-0005FE-Vo for w3c-dist-auth@w3c.org; Tue, 24 Aug 2004 07:27:20 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7OBQInt609192; Tue, 24 Aug 2004 07:26:18 -0400 Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7OBRUmZ150684; Tue, 24 Aug 2004 07:27:30 -0400 In-Reply-To: To: HTTP working group , Webdav WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 24 Aug 2004 07:26:15 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 08/24/2004 07:26:17, Serialize complete at 08/24/2004 07:26:17 Content-Type: multipart/alternative; boundary="=_alternative 003ED4A085256EFA_=" Received-SPF: none (dr-nick.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: PATCH proposal X-Archived-At: http://www.w3.org/mid/OFD7CE5C7B.49FC486C-ON85256EFA.003E8BEF-85256EFA.003ED4A4@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8767 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 24 Aug 2004 11:27:22 +0000 This is a multipart message in MIME format. --=_alternative 003ED4A085256EFA_= Content-Type: text/plain; charset="US-ASCII" I agree with Joe, especially for reason #2 (i.e. this isn't a WG doc). Cheers, Geoff Joe wrote on 08/24/2004 04:01:47 AM: > > I misunderstood. Do you think it is wrong to use the "DAV:" > > namespace? If you think it is wrong, please say so. I thought you > > said that the WG should agree to the use of the namespace, which is > > what we're doing. This is an explicit discussion on the mailing list > > about whether that's OK. > > > > I personally think it's OK but will replace the namespace if I get a > > bunch of objections. > > (in personal voice, not chair voice) > > I think it's probably best to use another namespace. > - I don't like DAV: to begin with :) > - This isn't a WG doc > - Given those two, I wouldn't want to set a precedent for others to go > throwing stuff into DAV: > > We've had the same problem with the jabber: namespaces in the XMPP > space. It's taken us a long time to get everyone to use namespace > URI's that they actually control in their protocols, but it's been well > worth the effort in terms of being able to do many more extensions in > parallel. > > -- > Joe Hildebrand > Denver, CO, USA > > --=_alternative 003ED4A085256EFA_= Content-Type: text/html; charset="US-ASCII"
I agree with Joe, especially for reason #2 (i.e. this isn't a WG doc).

Cheers,
Geoff

Joe wrote on 08/24/2004 04:01:47 AM:
> > I misunderstood.  Do you think it is wrong to use the "DAV:"
> > namespace?  If you think it is wrong, please say so.  I thought you
> > said that the WG should agree to the use of the namespace, which is
> > what we're doing.  This is an explicit discussion on the mailing list
> > about whether that's OK.
> >
> > I personally think it's OK but will replace the namespace if I get a
> > bunch of objections.
>
> (in personal voice, not chair voice)
>
> I think it's probably best to use another namespace.
> - I don't like DAV: to begin with :)
> - This isn't a WG doc
> - Given those two, I wouldn't want to set a precedent for others to go
> throwing stuff into DAV:
>
> We've had the same problem with the jabber: namespaces in the XMPP
> space.  It's taken us a long time to get everyone to use namespace
> URI's that they actually control in their protocols, but it's been well
> worth the effort in terms of being able to do many more extensions in
> parallel.
>
> --
> Joe Hildebrand
> Denver, CO, USA
>
>
--=_alternative 003ED4A085256EFA_=-- From w3c-dist-auth-request@w3.org Sat Aug 28 13:47:54 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01774 for ; Sat, 28 Aug 2004 13:47:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C17HL-0000RN-1e; Sat, 28 Aug 2004 17:46:15 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C17HK-0000Qm-IA for w3c-dist-auth@listhub.w3.org; Sat, 28 Aug 2004 17:46:14 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C17HK-0004af-8o for w3c-dist-auth@w3.org; Sat, 28 Aug 2004 17:46:14 +0000 Received: (qmail 2818 invoked by uid 65534); 28 Aug 2004 17:45:41 -0000 Received: from pD9E514A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.20.162) by mail.gmx.net (mp019) with SMTP; 28 Aug 2004 19:45:41 +0200 X-Authenticated: #1915285 Message-ID: <4130C4C0.7020609@gmx.de> Date: Sat, 28 Aug 2004 19:45:36 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200407192004.QAA19839@ietf.org> In-Reply-To: <200407192004.QAA19839@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/4130C4C0.7020609@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8768 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 28 Aug 2004 17:46:15 +0000 Content-Transfer-Encoding: 7bit Issues with draft-ietf-webdav-quota-03.txt Content 01-C01 Organization I think the draft could greatly benefit by a more clean separation of (a) terminology, (b) protocol (property/error code) definition and (c) examples. Proposal for a outline: 1 Introduction/Notation/Terminology 2 Additional live properties 3 Modification to behaviour of existing methods (error marshalling) 4...n Other standard RFC section A (Appendix) Examples of how servers may implement quota I'm happy to help restructuring the document if this is just a amount-of-work issue. 01-C02 (third property) The issue here seems to be that an additional property is required to make the quota authorable. I honestly haven't understood yet why it's needed. The problem seems to be that as the reported quota may be a "best pick" by the server (there may be multiple quotas in place, but only the most strict will be reported at any point of time). If this is the case this could potentially be fixed by exposing all quotas to the client. At the end of the day, unless we can agree about how this is supposed to work I strongly suggest to leave it out of the base spec and use a vendor-specific property for setting it. 01-C03 quota vs disk space The spec says that servers may expose physical disk limits as quota. a) This is incompatible with NFS from which we're borrowing the semantics (it treats disk limits as a separate property, and so should we) 02-C01 Condition Name Use name of precondition, not failure description: instead of 02-C02 allprop marshalling See also Change to MUST NOT (to reflect current ACL/DeltaV/Ordering approach). As of draft 03, this now says: "None of these properties need be returned in a request though the server may include them. However, these property names MUST be returned in a request for a resource that supports the properties, except in the case of infinite limits which are explained below." So, please, make it consistent with RFC3253, RFC3648 and RFC3744. Also, it's unclear why a server would ever be allowed to hide it upon PROPFIND/DAV:propname. Please clarify. 03-C01 spec organization/semantics Back when draft 02 was published, we had a mailing list discussion about using the term "quota space" to simplify the rest of the spec. Unfortunately, neither was the discussion was finished nor do I see a change in the spec. Editorial: 03-E01 incorrect IPR statement (RFC2026 is outdated) 03-E02 outdated reference to NFS spec (3010 -> 3530) From w3c-dist-auth-request@w3.org Tue Aug 31 11:08:14 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23888 for ; Tue, 31 Aug 2004 11:08:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2ACu-0001SS-Bs; Tue, 31 Aug 2004 15:06:00 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C2ACt-0001Rw-SP for w3c-dist-auth@listhub.w3.org; Tue, 31 Aug 2004 15:05:59 +0000 Received: from intmail.sequoianet.com ([63.97.219.13]) by bart.w3.org with esmtp (Exim 4.34) id 1C2ACt-0001Bx-Md for w3c-dist-auth@w3.org; Tue, 31 Aug 2004 15:05:59 +0000 Received: from seqhqemailbh.seqnt.com ([63.97.219.16]) by intmail.sequoianet.com with InterScan Messaging Security Suite; Tue, 31 Aug 2004 11:16:10 -0400 Received: from lansingemail.seqnt.com ([172.18.2.73]) by seqhqemailbh.seqnt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 Aug 2004 11:05:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Aug 2004 11:03:32 -0400 Message-ID: <0FD9D979B9535D4890AE309799B6D1E59D9FDC@lansingemail.seqnt.com> Thread-Topic: Analyzing WebDAV security Thread-Index: AcSPa+tgN3IobrebTyiTXvS5u6ZeMw== From: "Lachniet, Mark" To: X-OriginalArrivalTime: 31 Aug 2004 15:05:28.0611 (UTC) FILETIME=[F3B36730:01C48F6B] Received-SPF: none (bart.w3.org: domain of mlachniet@sequoianet.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Analyzing WebDAV security X-Archived-At: http://www.w3.org/mid/0FD9D979B9535D4890AE309799B6D1E59D9FDC@lansingemail.seqnt.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8769 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 31 Aug 2004 15:06:00 +0000 Content-Transfer-Encoding: quoted-printable Hello all, Please forgive me if my questions have been covered in other threads, but I have searched the archives and not found what I am looking for. There was one reference at http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0032.html that got somewhat close, but not close enough. I also tried posting to a penetration testing listserve with no results. In my work, I do a lot of security assessments of web sites. Many of them have WebDAV set up, and most of them are moderately well secured. However, I'm not confident that security analysts are really doing a good job of assessing WebDAV, and I want to make sure I'm doing all I can. I'm not really interested in talking about SSL and authentication protocols like Digest, etc. - that's pretty well covered in other places - I am talking just within WebDAV itself. I'm also not interested in well known and publicised flaws that have been fixed by patches. For example, when I come across a web site with WebDAV enabled for the public, I have typically been opening up a session with Cadaver to see if I can get into anything I'm not supposed to. Inevitably, I can log in, 'cd' to directories that I know exist on the server, and that's about it. I cannot usually even see any files, collections, or create directories or write files. I realize this is probably not the best way to test, but alas I am unaware of what else to do. So, I guess my questions are: 1) Is there any kind of formal WebDAV security checklists, software or scripts to check settings? Most scanners (e.g. Nessus) will note the existence of it, but won't do much else that I am aware of. 2) Is there any software to enumerate or brute-force directory space? Perhaps looking for directories you aren't supposed to see? 3) Is there any software to enumerate or brute force authentication credentials easily? 4) What other types of things should I be doing to help my clients be more secure? Thank you in advance for your help and patience. Mark Lachniet From w3c-dist-auth-request@w3.org Tue Aug 31 19:04:09 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10375 for ; Tue, 31 Aug 2004 19:04:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2Hdx-00051X-AQ; Tue, 31 Aug 2004 23:02:25 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C2Hdw-000511-Pj for w3c-dist-auth@listhub.w3.org; Tue, 31 Aug 2004 23:02:24 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by bart.w3.org with esmtp (Exim 4.34) id 1C2Hdw-0008Qp-GP for w3c-dist-auth@w3.org; Tue, 31 Aug 2004 23:02:24 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 Aug 2004 16:01:50 -0700 In-Reply-To: <4130C4C0.7020609@gmx.de> References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Tue, 31 Aug 2004 16:01:52 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 31 Aug 2004 23:01:50.0378 (UTC) FILETIME=[7FC2F0A0:01C48FAE] Received-SPF: none (bart.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/BF64B60C-FBA1-11D8-A93D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8770 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 31 Aug 2004 23:02:25 +0000 Content-Transfer-Encoding: 7bit On Aug 28, 2004, at 10:45 AM, Julian Reschke wrote: > Issues with draft-ietf-webdav-quota-03.txt > > > Content > > 01-C01 Organization > 0425.html> > 0438.html> > > I think the draft could greatly benefit by a more clean separation of > (a) terminology, (b) protocol (property/error code) definition and (c) > examples. > > Proposal for a outline: > > 1 Introduction/Notation/Terminology > 2 Additional live properties > 3 Modification to behaviour of existing methods (error marshalling) > 4...n Other standard RFC section > A (Appendix) Examples of how servers may implement quota > > I'm happy to help restructuring the document if this is just a > amount-of-work issue. The spec is so short that such a restructuring seems to me to be more pedantic make-work than "great benefit", but since the spec is so short, this arguably isn't an amount-of-work issue and should be performed given enough WG interest. > > > 01-C02 (third property) > 0425.html> > 0436.html> > > The issue here seems to be that an additional property is required to > make the quota authorable. I honestly haven't understood yet why it's > needed. The problem seems to be that as the reported quota may be a > "best pick" by the server (there may be multiple quotas in place, but > only the most strict will be reported at any point of time). If this > is the case this could potentially be fixed by exposing all quotas to > the client. > > At the end of the day, unless we can agree about how this is supposed > to work I strongly suggest to leave it out of the base spec and use a > vendor-specific property for setting it. A while back I asked those who objected to the specifics of the authorable quota functionality to propose alternative methods of obtaining that functionality, which no one responded to until your proposal here. That's a reasonable idea if no vendors plan to support authorable quotas in an interoperable manner, which may be true. So let me ask this of the list: if you do (or are possibly planning to) support quotas in your server implementation, will you never be making those quotas authorable and hence have no need for this as an optional feature of the quota spec? I know Xythos would like to do this in an non-proprietary (interoperable) manner. > > > 01-C03 quota vs disk space > 0439.html> > 0460.html> > 0184.html> > 0193.html> > > The spec says that servers may expose physical disk limits as quota. > > a) This is incompatible with NFS from which we're borrowing the > semantics (it treats disk limits as a separate property, and so should > we) When this was discussed in the past (for instance in SC) the general consensus was that clients want a single number to display. If you want to revisit that issue and by proposing another property be added, perhaps a good place to start would be to provide the text to the list for discussion. I think a necessary part of that text should be to discuss how a client should decide which number to display when both properties are returned. However, how many implementations will return both? AFAIK, the two implementations of the quota property (ours and Apple's) will only return one of the properties (or possibly both set to exactly the same thing) since there's no real semantic difference between the two. > > > > 02-C01 Condition Name > > Use name of precondition, not failure description: > instead of Unless anyone objects, I'll make that change. > > > 02-C02 allprop marshalling > > See also > 0175.html> > > Change to MUST NOT (to reflect current ACL/DeltaV/Ordering approach). > > As of draft 03, this now says: > > "None of these properties need be returned in a request > though the server may include them. However, these property names > MUST be returned in a request for a resource that > supports the properties, except in the case of infinite limits which > are explained below." > > So, please, make it consistent with RFC3253, RFC3648 and RFC3744. > Also, it's unclear why a server would ever be allowed to hide it upon > PROPFIND/DAV:propname. Please clarify. Right. I'll change the text to: A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined by this document.... > > > 03-C01 spec organization/semantics > > Back when draft 02 was published, we had a mailing list discussion > about using the term "quota space" to simplify the rest of the spec. > > 0294.html> > > Unfortunately, neither was the discussion was finished nor do I see a > change in the spec. Right, no one explained how to use "quota space" to simplify the spec (especially given we just copy-and-pasted the property description text from the NFS spec) or provided the requested replacement text. > > > > > Editorial: > > 03-E01 incorrect IPR statement (RFC2026 is outdated) > > 03-E02 outdated reference to NFS spec (3010 -> 3530) > > 0197.html> Will do. -brian briank@xythos.com