From w3c-dist-auth-request@w3.org Mon Dec 1 13:21:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21189 for ; Mon, 1 Dec 2003 13:21:07 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 82C4EA050E; Mon, 1 Dec 2003 13:21:21 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B5663A06AB for ; Mon, 1 Dec 2003 13:21:17 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 46576147CE; Mon, 1 Dec 2003 13:21:17 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 94327147CF for ; Mon, 1 Dec 2003 13:21:13 -0500 (EST) Received: from lisalap ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Dec 2003 10:21:12 -0800 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Mon, 1 Dec 2003 10:21:19 -0800 Message-ID: <003e01c3b837$ead7f740$75c990c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 01 Dec 2003 18:21:12.0266 (UTC) FILETIME=[E64772A0:01C3B837] Subject: RE: Bind issues X-Archived-At: http://www.w3.org/mid/003e01c3b837$ead7f740$75c990c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8179 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: <20031201182121.82C4EA050E@frink.w3.org> Resent-Date: Mon, 1 Dec 2003 13:21:21 -0500 (EST) Content-Transfer-Encoding: quoted-printable > Lisa, >=20 > you haven't replied to my mail dated Nov 18 > ( /0207.html>). Hi Julian, many of us just got back from a 4-day weekend due to American Thanksgiving. I haven't had time to reread the bind draft yet as you suggested. > As far as I can tell among the three questions you raised, >=20 > - one is closed (by the introduction of REBIND in addition to MOVE), >=20 > - one is still open (bind loop error marshalling), proposal=20 > for resolution > is at > = > - one will be closed by updating GULP > = (= ) > to clarify when a lock token counts as "submitted". I don't think that adding any text to RFC2518bis will fix the problem in = the bind draft. It's not clear RFC2518bis will finish soon, or if it does,=20 what status it will have, or how bindings will depend on it. Unless the bindings draft waits on RFC2518bis to finish, it needs to stand on its own in this respect. (As I've already said, I think all the language from GULP *is* in=20 RFC2518bis. I may have missed something and I'm happy to have it = pointed out, but due to the dependency issue, whether or not that's complete or agreed upon may not be relevant to bindings status) Lisa From w3c-dist-auth-request@w3.org Mon Dec 1 14:57:14 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24571 for ; Mon, 1 Dec 2003 14:57:14 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 588D1A099E; Mon, 1 Dec 2003 14:56:19 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5AB0DA099E for ; Mon, 1 Dec 2003 14:56:15 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 1152013B94; Mon, 1 Dec 2003 14:56:15 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by dr-nick.w3.org (Postfix) with ESMTP id 9A9EB13B71 for ; Mon, 1 Dec 2003 14:56:14 -0500 (EST) Received: from Tycho (dhcp-60-131.cse.ucsc.edu [128.114.60.131]) by ucsc.edu (8.10.1/8.10.1) with SMTP id hB1JhTj08224 for ; Mon, 1 Dec 2003 11:43:29 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 1 Dec 2003 11:44:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: OPTIONS * X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMEOBKEAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8180 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: <20031201195619.588D1A099E@frink.w3.org> Resent-Date: Mon, 1 Dec 2003 14:56:19 -0500 (EST) Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added "Jim.Gettys@hp.com" to the accept2 filter. - Jim -----Original Message----- From: Jim Gettys [mailto:Jim.Gettys@hp.com] Sent: Wednesday, November 26, 2003 7:51 AM To: Lisa Dusseault Cc: 'Alex Rousskov'; 'Scott Lawrence'; 'Larry Masinter'; 'Webdav WG'; ietf-http-wg@w3.org Subject: [Moderator Action] RE: OPTIONS * Are people happy with Lisa's suggested solution? There has been no comment to date. Essentially, she suggests deleting the words "it does nothing beyond allowing the client to test the capabilities of the server" from the specification. I'd like to get a draft issued. Though I've tried for perfection on my first try, my experience is it is likely that at least one more draft will have to be done before full standard, as, at a minimum, the chances of getting all the changes decreed by IESG process changes right on the first try seems unlikely to me. - Jim On Tue, 2003-11-25 at 20:25, Lisa Dusseault wrote: > For me, the phrase "to test the capabilities of" misled me. I assumed > this meant that any capability added to the server, such as support > for WebDAV methods even in some limited namespaces, must be advertised > in OPTIONS * as a capability. Since this assumption isn't backed > up by implementation reality, the HTTP text could be something like: > > If the Request-URI is an asterisk ("*"), the OPTIONS request is > intended to apply to the server in general rather than to a > specific resource. Since a server's communication options > typically depend on the resource, the "*" request is only > useful as a "ping" or "no-op" type of method. For example, this > can be used to test a proxy for HTTP/1.1 support (or lack thereof). > > Lisa > > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Tuesday, November 25, 2003 1:51 PM > > To: Scott Lawrence > > Cc: Larry Masinter; 'Lisa Dusseault'; 'Webdav WG'; ietf-http-wg@w3.org > > Subject: Re: OPTIONS * > > > > > > On Tue, 25 Nov 2003, Scott Lawrence wrote: > > > > > > If the Request-URI is an asterisk ("*"), the OPTIONS request is > > > > intended to apply to the server in general rather than to a > > > > specific resource. Since a server's communication options > > > > typically depend on the resource, the "*" request is only > > > > useful as a "ping" or "no-op" type of method; it does nothing > > > > beyond allowing the client to test the capabilities of the > > > > server. For example, this can be used to test a proxy for > > > > HTTP/1.1 compliance (or lack thereof). > > > > > > > > So there seems to be some assumption that HTTP/1.1 compliance has > > > > something to do with implementing OPTIONS (otherwise how could it > > > > be used as a test for HTTP/1.1 compliance?). > > > > > > Regardless of whether or not you get an error (or even which one you > > > get), you still get the servers claimed HTTP version in the response > > > line. > > > > > > I'm not sure what more that paragraph needs to say, or > > what's unclear > > > about it. > > > > What confuses people is probably that the text says "to test for > > compliance" rather than saying "to detect HTTP version". Since most > > HTTP/1.1 implementations are not HTTP/1.1 compliant but are using > > HTTP/1.1 version, the two statements are different. > > > > HTH, > > > > Alex. > > > > -- Jim Gettys HP Labs, Cambridge Research Laboratory From w3c-dist-auth-request@w3.org Mon Dec 1 14:57:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24587 for ; Mon, 1 Dec 2003 14:57:15 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id B95EFA092F; Mon, 1 Dec 2003 14:56:27 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id D228EA09DA for ; Mon, 1 Dec 2003 14:56:18 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 8D63F13B9D; Mon, 1 Dec 2003 14:56:18 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by dr-nick.w3.org (Postfix) with ESMTP id 1DF1E13B94 for ; Mon, 1 Dec 2003 14:56:18 -0500 (EST) Received: from Tycho (dhcp-60-131.cse.ucsc.edu [128.114.60.131]) by ucsc.edu (8.10.1/8.10.1) with SMTP id hB1JhUj08229 for ; Mon, 1 Dec 2003 11:43:30 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 1 Dec 2003 11:44:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C3B800.870E06A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: WebDAV and Japanese Language X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIOEOBKEAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8181 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: <20031201195627.B95EFA092F@frink.w3.org> Resent-Date: Mon, 1 Dec 2003 14:56:27 -0500 (EST) This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C3B800.870E06A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added "asegu@zensutra.com" to the accept2 list. - Jim -----Original Message----- From: Ashok Segu [mailto:asegu@zensutra.com] Sent: Tuesday, November 25, 2003 9:09 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV and Japanese Language Hi, We seem to have problem when our customers are accessing our application from a Windows 2000 SP4 system with Japanese Language Pack. After the user is authenticated and is presented with the 1st set of Folders, they are unable to navigate to the second level of folders. They get the following error message: "The documents of this folder are not accessible. The reason may be that folders are deleted or moved." The user is accessing the WebDAV functionality using the File -> Open feature of Internet Explorer (version 5.5 SP2). Are there any known issues? Is a fix or workaround available? Ashok Segu Chief Technology Officer ZenSutra Software Technologies www.zensutra.com tel +91-80-235-0481 | asegu@zensutra.com HM Geneva House, Suite 601, #14 Cunningham Road Bangalore - 560 052, India weaving the knowledge tapestry ------=_NextPart_000_000B_01C3B800.870E06A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam filter. I have added = "asegu@zensutra.com" to the accept2 = list.
 
-=20 Jim
-----Original Message-----
From: Ashok Segu=20 [mailto:asegu@zensutra.com]
Sent: Tuesday, November 25, 2003 = 9:09=20 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action]=20 WebDAV and Japanese Language

Hi,

 

We seem to have problem = when our=20 customers are accessing our application from a Windows 2000 SP4 system = with=20 Japanese Language Pack.  = After the=20 user is authenticated and is presented with the 1st set of Folders, they = are=20 unable to navigate to the second level of folders.  They get the following error = message:=20 “The documents of this folder are not accessible. The reason may = be=20 that folders are deleted or = moved."

 

The user is accessing the = WebDAV=20 functionality using the File -> Open feature of Internet Explorer = (version=20 5.5 SP2).

 

Are there any known = issues?  Is a fix or workaround=20 available?

 

Ashok=20 Segu
Chief=20 Technology Officer

ZenSutra=20 Software Technologies=20
www.zensutra.com

 

tel=20 +91-80-235-0481=20 | asegu@zensutra.com
HM=20 Geneva House, Suite=20 601,=20 #14=20 Cunningham=20 = Road<= FONT=20 face=3D"Century Gothic" size=3D1>
Bangalore<= /st1:place>=20 – 560 052,=20 = India

weaving=20 the knowledge tapestry

 

------=_NextPart_000_000B_01C3B800.870E06A0-- From w3c-dist-auth-request@w3.org Mon Dec 1 15:11:02 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25702 for ; Mon, 1 Dec 2003 15:11:02 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id EC0F9A073B; Mon, 1 Dec 2003 15:11:16 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 68968A073B for ; Mon, 1 Dec 2003 15:11:13 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 0C260136F2; Mon, 1 Dec 2003 15:11:13 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 8262813427 for ; Mon, 1 Dec 2003 15:11:12 -0500 (EST) Received: (qmail 2450 invoked by uid 65534); 1 Dec 2003 20:11:11 -0000 Received: from p508B8086.dip0.t-ipconnect.de (EHLO gmx.de) (80.139.128.134) by mail.gmx.net (mp014) with SMTP; 01 Dec 2003 21:11:11 +0100 X-Authenticated: #1915285 Message-ID: <3FCBA05E.1050208@gmx.de> Date: Mon, 01 Dec 2003 21:11:10 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FW: WebDAV and Japanese Language X-Archived-At: http://www.w3.org/mid/3FCBA05E.1050208@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8182 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: <20031201201116.EC0F9A073B@frink.w3.org> Resent-Date: Mon, 1 Dec 2003 15:11:16 -0500 (EST) Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Are there any known issues? Is a fix or workaround available? Yes. Possibly: http://greenbytes.de/tech/webdav/webfolder-client-list.html#issue-collection-open-non-ASCII-name -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 1 15:33:02 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27759 for ; Mon, 1 Dec 2003 15:33:01 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 49245A073B; Mon, 1 Dec 2003 15:33:14 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DECD1A08ED for ; Mon, 1 Dec 2003 15:33:09 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id C31C6136BF; Mon, 1 Dec 2003 15:33:09 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 532F6136A6 for ; Mon, 1 Dec 2003 15:33:09 -0500 (EST) Received: (qmail 10679 invoked by uid 65534); 1 Dec 2003 20:33:08 -0000 Received: from p508B8086.dip0.t-ipconnect.de (EHLO gmx.de) (80.139.128.134) by mail.gmx.net (mp022) with SMTP; 01 Dec 2003 21:33:08 +0100 X-Authenticated: #1915285 Message-ID: <3FCBA351.5040903@gmx.de> Date: Mon, 01 Dec 2003 21:23:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov Cc: Jim Gettys , Lisa Dusseault , "'Scott Lawrence'" , "'Larry Masinter'" , "'Webdav WG'" , ietf-http-wg@w3.org References: <009301c3b3bc$1cbd7df0$75c990c6@lisalap> <1069861653.5508.17.camel@laptop.gettys.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: OPTIONS * X-Archived-At: http://www.w3.org/mid/3FCBA351.5040903@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8183 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: <20031201203314.49245A073B@frink.w3.org> Resent-Date: Mon, 1 Dec 2003 15:33:14 -0500 (EST) Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > > On Wed, 26 Nov 2003, Jim Gettys wrote: > > >>Are people happy with Lisa's suggested solution? > > > I would replace "test a proxy for HTTP/1.1 support (or lack thereof)" > with a more well-defined "test a proxy for OPTIONS method support (or > lack thereof)". I support Alex' clarification. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 1 15:33:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27809 for ; Mon, 1 Dec 2003 15:33:40 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 829ECA0940; Mon, 1 Dec 2003 15:33:22 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 80C83A0940 for ; Mon, 1 Dec 2003 15:33:13 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 655DC1371E; Mon, 1 Dec 2003 15:33:13 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id F1C64136B8 for ; Mon, 1 Dec 2003 15:33:12 -0500 (EST) Received: (qmail 7542 invoked by uid 65534); 1 Dec 2003 20:33:09 -0000 Received: from p508B8086.dip0.t-ipconnect.de (EHLO gmx.de) (80.139.128.134) by mail.gmx.net (mp016) with SMTP; 01 Dec 2003 21:33:09 +0100 X-Authenticated: #1915285 Message-ID: <3FCBA50A.6020801@gmx.de> Date: Mon, 01 Dec 2003 21:31:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: w3c-dist-auth@w3.org References: <003e01c3b837$ead7f740$75c990c6@lisalap> In-Reply-To: <003e01c3b837$ead7f740$75c990c6@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Bind issues X-Archived-At: http://www.w3.org/mid/3FCBA50A.6020801@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8184 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: <20031201203322.829ECA0940@frink.w3.org> Resent-Date: Mon, 1 Dec 2003 15:33:22 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Hi Julian, many of us just got back from a 4-day weekend due > to American Thanksgiving. I haven't had time to reread the bind > draft yet as you suggested. Ok. >>- one will be closed by updating GULP >>() >>to clarify when a lock token counts as "submitted". > > > I don't think that adding any text to RFC2518bis will fix the problem in the > bind draft. It's not clear RFC2518bis will finish soon, or if it does, > what status it will have, or how bindings will depend on it. Unless the > bindings draft waits on RFC2518bis to finish, it needs to stand on its > own in this respect. Well, I think I can agree with this. However we need to ensure that BIND and RFC2518bis actually say the same thing. So I'm in favor of adding GULP to the BIND spec *if and only if* there's a clearly expressed working group consensus on that this indeed is what RFC2518bis should say as well. Ideally, in identical words. > (As I've already said, I think all the language from GULP *is* in > RFC2518bis. I may have missed something and I'm happy to have it pointed > out, but due to the dependency issue, whether or not that's complete or > agreed upon may not be relevant to bindings status) Well, GULP is the result of many mailing list members trying to come up with the best possible explanation of how locks work in WebDAV (completely independantly of the BIND spec, by the way). It's not only about what is says, but also how it does that. Therefore, I think this should be *the* normative statement, and that it belongs into the base spec. Let's just vote on it, I don't think that any further discussion about this will reveal any new arguments. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 1 16:31:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01345 for ; Mon, 1 Dec 2003 16:31:26 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 7EF30A06CF; Mon, 1 Dec 2003 16:31:34 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 10CF7A06CF for ; Mon, 1 Dec 2003 16:31:26 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id A36B9137FC; Mon, 1 Dec 2003 16:30:13 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 4FEC8137E0 for ; Mon, 1 Dec 2003 16:30:13 -0500 (EST) Received: from lisalap ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Dec 2003 13:30:11 -0800 From: "Lisa Dusseault" To: "'Julian Reschke'" Cc: Date: Mon, 1 Dec 2003 13:30:18 -0800 Message-ID: <007b01c3b852$51971230$75c990c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3FCBA50A.6020801@gmx.de> X-OriginalArrivalTime: 01 Dec 2003 21:30:11.0916 (UTC) FILETIME=[4D3CB8C0:01C3B852] Subject: RE: Bind issues X-Archived-At: http://www.w3.org/mid/007b01c3b852$51971230$75c990c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8185 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: <20031201213134.7EF30A06CF@frink.w3.org> Resent-Date: Mon, 1 Dec 2003 16:31:34 -0500 (EST) Content-Transfer-Encoding: 7bit > > (As I've already said, I think all the language from GULP *is* in > > RFC2518bis. I may have missed something and I'm happy to have it pointed > > out, but due to the dependency issue, whether or not that's complete or > > agreed upon may not be relevant to bindings status) > Well, GULP is the result of many mailing list members trying to come up > with the best possible explanation of how locks work in WebDAV > (completely independantly of the BIND spec, by the way). It's not only > about what is says, but also how it does that. Therefore, I think this > should be *the* normative statement, and that it belongs into the base > spec. Let's just vote on it, I don't think that any further discussion > about this will reveal any new arguments. I don't have a problem with GULP. What I'm trying to do is make sure it fits into the WebDAV specification. Sure, we could bung it in randomly, any section remotely related to locking. Instead, however, I tried to - keep to the structure of the spec - have the spec be linguistically consistent with GULP - have the spec be logically consistent with GULP I'd still like to hear how this could be better, for example whether any subtlety was lost in the way GULP was incorporated. But if you think this is irrelevant and you want to call a vote, Jim can determine consensus. Please indicate where you would like me to put GULP into RFC2518bis. Lisa From w3c-dist-auth-request@w3.org Tue Dec 2 14:16:18 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02953 for ; Tue, 2 Dec 2003 14:16:18 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 35B83A0C55; Tue, 2 Dec 2003 14:16:15 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B0785A0D0F for ; Tue, 2 Dec 2003 14:16:04 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 3713D137ED; Tue, 2 Dec 2003 14:16:04 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id C172A137E3 for ; Tue, 2 Dec 2003 14:16:03 -0500 (EST) Received: (qmail 18723 invoked by uid 65534); 2 Dec 2003 19:16:02 -0000 Received: from p3EE24756.dip.t-dialin.net (EHLO gmx.de) (62.226.71.86) by mail.gmx.net (mp012) with SMTP; 02 Dec 2003 20:16:02 +0100 X-Authenticated: #1915285 Message-ID: <3FCCE4ED.3090403@gmx.de> Date: Tue, 02 Dec 2003 20:15:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: w3c-dist-auth@w3.org References: <007b01c3b852$51971230$75c990c6@lisalap> In-Reply-To: <007b01c3b852$51971230$75c990c6@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Bind issues X-Archived-At: http://www.w3.org/mid/3FCCE4ED.3090403@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8186 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: <20031202191615.35B83A0C55@frink.w3.org> Resent-Date: Tue, 2 Dec 2003 14:16:15 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >>Well, GULP is the result of many mailing list members trying to come up >>with the best possible explanation of how locks work in WebDAV >>(completely independantly of the BIND spec, by the way). It's not only >>about what is says, but also how it does that. Therefore, I think this >>should be *the* normative statement, and that it belongs into the base >>spec. Let's just vote on it, I don't think that any further discussion >>about this will reveal any new arguments. > > > I don't have a problem with GULP. What I'm trying to do is make sure it > fits into the WebDAV specification. Sure, we could bung it in randomly, > any section remotely related to locking. Instead, however, I tried to OTOH, we could put it into section 6, and then try to remove any language that's not needed anymore. Note that I'm not against keeping examples and extended usage discussions, it should be just clear that the few paragraphs of GULP are actually all that's required to fully specify the locking semantics. Having that in one single place instead of spreading it over different sections (Locking intro, LOCK method, If header) IMHO makes things a lot easier to understand. > - keep to the structure of the spec > - have the spec be linguistically consistent with GULP > - have the spec be logically consistent with GULP > > I'd still like to hear how this could be better, for example whether any > subtlety was lost in the way GULP was incorporated. Well, it seems. We have this discussion because you pointed out that BIND spec neglects to specify locking behaviour. If RFC2518bis indeed already says the same thing as GULP, there shouldn't be an issue (because it's supposed to fully explain how locking works when there are multiple URIs for the same resource). > But if you think this is irrelevant and you want to call a vote, Jim can > determine consensus. Please indicate where you would like me to put GULP > into RFC2518bis. I'm happy to make a more detailed proposal, but I'd prefer to make a base decision first. Jim? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 2 14:17:07 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03019 for ; Tue, 2 Dec 2003 14:17:07 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 25F81A0BDE; Tue, 2 Dec 2003 14:16:23 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E2AE5A0D13 for ; Tue, 2 Dec 2003 14:16:05 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 5AD011371A; Tue, 2 Dec 2003 14:16:05 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 9E95A1375C for ; Tue, 2 Dec 2003 14:16:01 -0500 (EST) Received: from lisalap ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2003 11:16:00 -0800 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Webdav WG'" Date: Tue, 2 Dec 2003 11:16:08 -0800 Message-ID: <001301c3b908$bdeb7eb0$75c990c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3FC231B6.8060800@gmx.de> X-OriginalArrivalTime: 02 Dec 2003 19:16:00.0365 (UTC) FILETIME=[B88D49D0:01C3B908] Subject: RE: Resolving RFC2518 issue 55 ("DISPLAYNAME") X-Archived-At: http://www.w3.org/mid/001301c3b908$bdeb7eb0$75c990c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8187 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: <20031202191623.25F81A0BDE@frink.w3.org> Resent-Date: Tue, 2 Dec 2003 14:16:23 -0500 (EST) Content-Transfer-Encoding: 7bit I haven't heard any objection to this, and I think it's a good idea, so I'm going to add it to RFC2518bis as things stand. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Monday, November 24, 2003 8:29 AM > To: 'Webdav WG' > Subject: Resolving RFC2518 issue 55 ("DISPLAYNAME") > > > > Hi, > > looking at , the > discussion > back in 2000 > and the recent mailing list discussion , I'd like to propose: 1) Deprecate DAV:displayname: clearly, we don't have interoperability (some servers treat it as a dead property with or without a default upon resource creation, some servers treat is as live property based on the last path segment). Clients can not rely on the property being present (mod_dav, SAP) or being writable (IIS, Sharemation?, Slide?). 2) As the RFC2518-stated intent was to provide a *description* of the resource (which clearly isn't useful when it's always the same as the last path segment after un-escaping), I'd propose to add a *new* dead property to RFC2518bis called DAV:description which covers this. All existing servers that support dead property (thus all RFC2518-compliant servers) will automatically support this property, thus it can safely added to RFC2518bis. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 2 14:21:38 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03188 for ; Tue, 2 Dec 2003 14:21:38 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id D9CCFA0C76; Tue, 2 Dec 2003 14:21:49 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E1030A0C76 for ; Tue, 2 Dec 2003 14:21:45 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 4DE5413408; Tue, 2 Dec 2003 14:21:43 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id A7D2B13366 for ; Tue, 2 Dec 2003 14:21:39 -0500 (EST) Received: (qmail 29970 invoked by uid 65534); 2 Dec 2003 19:21:32 -0000 Received: from p3EE24756.dip.t-dialin.net (EHLO gmx.de) (62.226.71.86) by mail.gmx.net (mp005) with SMTP; 02 Dec 2003 20:21:32 +0100 X-Authenticated: #1915285 Message-ID: <3FCCE62A.7090902@gmx.de> Date: Tue, 02 Dec 2003 20:21:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: w3c-dist-auth@w3.org References: <003e01c3b837$ead7f740$75c990c6@lisalap> In-Reply-To: <003e01c3b837$ead7f740$75c990c6@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Bind issues X-Archived-At: http://www.w3.org/mid/3FCCE62A.7090902@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8188 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: <20031202192149.D9CCFA0C76@frink.w3.org> Resent-Date: Tue, 2 Dec 2003 14:21:49 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I don't think that adding any text to RFC2518bis will fix the problem in the > bind draft. It's not clear RFC2518bis will finish soon, or if it does, > what status it will have, or how bindings will depend on it. Unless the > bindings draft waits on RFC2518bis to finish, it needs to stand on its > own in this respect. Well, we've talked about that many times before, but anyway... BIND does *not* introduce the concept on bindings (multiple URIs mapped to the same resource). This concept already exists implicitly in RFC2616, RFC2518 and RFC3253. In RFC3253, some operations even implicitly create possibly multiple bindings. So if RFC2518bis doesn't already fully explain how locking and multiple URI mappings interact, it's RFC2518bis that is incomplete. All the BIND spec adds is - a method to explicitly create new bindings - new methods in addition to MOVE/DELETE which are more clearly defined in how they interact with multiple bindings (so avoiding changing the semantics of MOVE/DELETE if a server implementer doesn't want to do that) - error marshalling extensions - discovery of the "other" bindings to a resource, detecting whether to URIs identify the same resource. But again, the BIND draft does *not* introduce the concept itself. It's been here all the time, > (As I've already said, I think all the language from GULP *is* in > RFC2518bis. I may have missed something and I'm happy to have it pointed > out, but due to the dependency issue, whether or not that's complete or > agreed upon may not be relevant to bindings status) Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 2 14:22:55 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03238 for ; Tue, 2 Dec 2003 14:22:54 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id D9DC6A0C59; Tue, 2 Dec 2003 14:23:05 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DE31FA0C59 for ; Tue, 2 Dec 2003 14:23:04 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 6BD721336F; Tue, 2 Dec 2003 14:23:04 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id EEDE41335C for ; Tue, 2 Dec 2003 14:23:03 -0500 (EST) Received: (qmail 871 invoked by uid 65534); 2 Dec 2003 19:22:59 -0000 Received: from p3EE24756.dip.t-dialin.net (EHLO gmx.de) (62.226.71.86) by mail.gmx.net (mp001) with SMTP; 02 Dec 2003 20:22:59 +0100 X-Authenticated: #1915285 Message-ID: <3FCCE682.1030703@gmx.de> Date: Tue, 02 Dec 2003 20:22:42 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: "'Webdav WG'" References: <001301c3b908$bdeb7eb0$75c990c6@lisalap> In-Reply-To: <001301c3b908$bdeb7eb0$75c990c6@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Resolving RFC2518 issue 55 ("DISPLAYNAME") X-Archived-At: http://www.w3.org/mid/3FCCE682.1030703@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8189 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: <20031202192305.D9DC6A0C59@frink.w3.org> Resent-Date: Tue, 2 Dec 2003 14:23:05 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I haven't heard any objection to this, and I think it's a good idea, > so I'm going to add it to RFC2518bis as things stand. Great. Wondering...: should we *require* this property to be writeable, or are there cases where it can be protected? I'd prefer to leave it simple, thus require it to be just a writeable property. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 2 14:58:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05225 for ; Tue, 2 Dec 2003 14:58:08 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 439C5A060B; Tue, 2 Dec 2003 14:57:39 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3BBBAA06FD for ; Tue, 2 Dec 2003 14:57:35 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id EAF4D13772; Tue, 2 Dec 2003 14:57:34 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 9EAE913758 for ; Tue, 2 Dec 2003 14:57:34 -0500 (EST) Received: from lisalap ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2003 11:57:33 -0800 From: "Lisa Dusseault" To: "'Julian Reschke'" Cc: Date: Tue, 2 Dec 2003 11:57:42 -0800 Message-ID: <002f01c3b90e$8bf4c1e0$75c990c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3FCCE62A.7090902@gmx.de> X-OriginalArrivalTime: 02 Dec 2003 19:57:33.0628 (UTC) FILETIME=[86A707C0:01C3B90E] Subject: RE: Bind issues X-Archived-At: http://www.w3.org/mid/002f01c3b90e$8bf4c1e0$75c990c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8190 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: <20031202195739.439C5A060B@frink.w3.org> Resent-Date: Tue, 2 Dec 2003 14:57:39 -0500 (EST) Content-Transfer-Encoding: 7bit > BIND does *not* introduce the concept on bindings (multiple > URIs mapped > to the same resource). This concept already exists implicitly in > RFC2616, RFC2518 and RFC3253. In RFC3253, some operations even > implicitly create possibly multiple bindings. How so? > So if RFC2518bis doesn't already fully explain how locking > and multiple > URI mappings interact, it's RFC2518bis that is incomplete. RFC2518bis implicitly included the concept that files had previous versions (that you just couldn't happen to know about or view). Still, when DeltaV added versions, it was reasonable and right to add requirements on how servers supporting DeltaV had to MOVE and COPY resources with versions. The difference is that before the bindings work, bindings could exist but weren't standardized. One major goal of standardizing a feature ought to be to ensure that it works the same in different implementations. So, if the bindings draft leaves it optional to servers how to apply LOCK to multiple bindings, then it's my opinion that the bindings draft needs to be fixed. Even if we believe that the required behavior is implicit in GULP, I'd like to see it spelled out in the bindings proposal to minimize confusion and implementation differences. Lisa From w3c-dist-auth-request@w3.org Tue Dec 2 15:35:18 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08598 for ; Tue, 2 Dec 2003 15:35:17 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id F1B01A081F; Tue, 2 Dec 2003 15:35:26 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C0ED9A0A27 for ; Tue, 2 Dec 2003 15:35:13 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 01F4413A19; Tue, 2 Dec 2003 15:32:00 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 8EEB913A18 for ; Tue, 2 Dec 2003 15:31:59 -0500 (EST) Received: (qmail 29673 invoked by uid 65534); 2 Dec 2003 20:31:56 -0000 Received: from p3EE24756.dip.t-dialin.net (EHLO gmx.de) (62.226.71.86) by mail.gmx.net (mp023) with SMTP; 02 Dec 2003 21:31:56 +0100 X-Authenticated: #1915285 Message-ID: <3FCCF6AF.7080607@gmx.de> Date: Tue, 02 Dec 2003 21:31:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: w3c-dist-auth@w3.org References: <002f01c3b90e$8bf4c1e0$75c990c6@lisalap> In-Reply-To: <002f01c3b90e$8bf4c1e0$75c990c6@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Bind issues X-Archived-At: http://www.w3.org/mid/3FCCF6AF.7080607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8191 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: <20031202203526.F1B01A081F@frink.w3.org> Resent-Date: Tue, 2 Dec 2003 15:35:26 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >>BIND does *not* introduce the concept on bindings (multiple >>URIs mapped >>to the same resource). This concept already exists implicitly in >>RFC2616, RFC2518 and RFC3253. In RFC3253, some operations even >>implicitly create possibly multiple bindings. > > > How so? RFC2518: section 5.1: "Although implicit in [RFC2068] and [RFC2396], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs." RFC3253: section 14: "Unlike a version-controlled collection, which contains bindings to version-controlled resources and non-version-controlled resources, a working collection contains bindings to version history resources and non-version-controlled resources." >>So if RFC2518bis doesn't already fully explain how locking >>and multiple >>URI mappings interact, it's RFC2518bis that is incomplete. > > > RFC2518bis implicitly included the concept that files had previous > versions (that you just couldn't happen to know about or view). > Still, when DeltaV added versions, it was reasonable and right > to add requirements on how servers supporting DeltaV had to MOVE > and COPY resources with versions. I agree, but I don't understand how that compares to the issue we're discussing.... > The difference is that before the bindings work, bindings could > exist but weren't standardized. One major goal of standardizing > a feature ought to be to ensure that it works the same in different > implementations. Agreed. I think we're just discussing the best way to ensure this. As multiple bindings (multiple internal member URIs...) to the same resource already appear in RFC2518 and RFC3253, I don't see why it must be the BIND spec that clarifies their locking semantics. *If* it's going to do that, we *must* ensure that it's consistent with what RFC2518bis says. In which case, using the identical description is the easiest way to achieve this. > So, if the bindings draft leaves it optional to servers how to > apply LOCK to multiple bindings, then it's my opinion that the No, it doesn't leave it optional. It just (currently) doesn't say something that really should be said somewhere else. > bindings draft needs to be fixed. Even if we believe that the > required behavior is implicit in GULP, I'd like to see it spelled > out in the bindings proposal to minimize confusion and implementation > differences. If there is anything that actually needs to be clarified, I think it's up to you to point to it. Geoff and others have tried to make GULP as precise as possible. If you think that it doesn't do that well enough yet, please tell us where you think it needs to be improved. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 2 15:54:58 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10140 for ; Tue, 2 Dec 2003 15:54:57 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id ECD02A06F2; Tue, 2 Dec 2003 15:55:08 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C6117A0A27 for ; Tue, 2 Dec 2003 15:55:01 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 7BA811335C; Tue, 2 Dec 2003 15:55:01 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by dr-nick.w3.org (Postfix) with ESMTP id 5B8E51334D for ; Tue, 2 Dec 2003 15:55:01 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hB2Kt1h3017630 for ; Tue, 2 Dec 2003 15:55:01 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB2Ksxqt228064 for ; Tue, 2 Dec 2003 15:54:59 -0500 In-Reply-To: <3FCCF6AF.7080607@gmx.de> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 2 Dec 2003 15:55:18 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 12/02/2003 15:55:00, Serialize complete at 12/02/2003 15:55:00 Content-Type: text/plain; charset="US-ASCII" Subject: Re: Bind issues X-Archived-At: http://www.w3.org/mid/OF3D8DC3D2.F4DF54B0-ON85256DF0.00723A22-85256DF0.0072ED79@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8192 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: <20031202205508.ECD02A06F2@frink.w3.org> Resent-Date: Tue, 2 Dec 2003 15:55:08 -0500 (EST) I agree with all of Julian's points. Another example of where multiple bindings are explicitly created by RFC3253 operations are when a version-controlled collection is updated to a different version of a collection. If a member of the specified collection version is a version history for a resource that is already present in the workspace of that collection, the server MUST create a second binding to that resource. (RFC-3253, Section 14.11). Cheers, Geoff Julian wrote on 12/02/2003 03:31:43 PM: > Lisa Dusseault wrote: > > >>BIND does *not* introduce the concept on bindings (multiple > >>URIs mapped > >>to the same resource). This concept already exists implicitly in > >>RFC2616, RFC2518 and RFC3253. In RFC3253, some operations even > >>implicitly create possibly multiple bindings. > > > > > > How so? > > RFC2518: section 5.1: > > "Although implicit in [RFC2068] and [RFC2396], any resource, including > collection resources, MAY be identified by more than one URI. For > example, a resource could be identified by multiple HTTP URLs." > > RFC3253: section 14: > > "Unlike a version-controlled collection, which contains bindings to > version-controlled resources and non-version-controlled resources, a > working collection contains bindings to version history resources and > non-version-controlled resources." > > >>So if RFC2518bis doesn't already fully explain how locking > >>and multiple > >>URI mappings interact, it's RFC2518bis that is incomplete. > > > > > > RFC2518bis implicitly included the concept that files had previous > > versions (that you just couldn't happen to know about or view). > > Still, when DeltaV added versions, it was reasonable and right > > to add requirements on how servers supporting DeltaV had to MOVE > > and COPY resources with versions. > > I agree, but I don't understand how that compares to the issue we're > discussing.... > > > The difference is that before the bindings work, bindings could > > exist but weren't standardized. One major goal of standardizing > > a feature ought to be to ensure that it works the same in different > > implementations. > > Agreed. I think we're just discussing the best way to ensure this. As > multiple bindings (multiple internal member URIs...) to the same > resource already appear in RFC2518 and RFC3253, I don't see why it must > be the BIND spec that clarifies their locking semantics. *If* it's going > to do that, we *must* ensure that it's consistent with what RFC2518bis > says. In which case, using the identical description is the easiest way > to achieve this. > > > So, if the bindings draft leaves it optional to servers how to > > apply LOCK to multiple bindings, then it's my opinion that the > > No, it doesn't leave it optional. It just (currently) doesn't say > something that really should be said somewhere else. > > > bindings draft needs to be fixed. Even if we believe that the > > required behavior is implicit in GULP, I'd like to see it spelled > > out in the bindings proposal to minimize confusion and implementation > > differences. > > If there is anything that actually needs to be clarified, I think it's > up to you to point to it. Geoff and others have tried to make GULP as > precise as possible. If you think that it doesn't do that well enough > yet, please tell us where you think it needs to be improved. > > Julian > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Tue Dec 2 17:36:37 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19213 for ; Tue, 2 Dec 2003 17:36:36 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id C7B60A0742; Tue, 2 Dec 2003 17:36:46 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EC778A0BF1 for ; Tue, 2 Dec 2003 17:36:38 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id A630D13867; Tue, 2 Dec 2003 17:36:16 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (Postfix) with ESMTP id C024F1386D for ; Tue, 2 Dec 2003 17:36:11 -0500 (EST) Received: (mail@localhost) by sunbelt.seagull.net (8.12.10) id hB2MaATc022339 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Tue, 2 Dec 2003 14:36:10 -0800 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.12.10) with ESMTP id hB2Ma4co022298 sender ccjason@us.ibm.com; Tue, 2 Dec 2003 14:36:07 -0800 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 hB2Ma3oJ492512; Tue, 2 Dec 2003 17:36:03 -0500 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB2Ma1qt203834; Tue, 2 Dec 2003 17:36:02 -0500 To: "Lisa Dusseault" Cc: "'Julian Reschke'" , nnw3c-dist-auth___at___w3.org@smallcue.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Tue, 2 Dec 2003 17:35:58 -0500 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.5HF149 | November 14, 2003) at 12/02/2003 17:36:02, Serialize complete at 12/02/2003 17:36:02 Content-Type: multipart/alternative; boundary="=_alternative 007BB82885256DF0_=" Subject: RE: Bind issues X-Archived-At: http://www.w3.org/mid/OF454CBB3D.E5585C19-ON85256DF0.007B8F1A-85256DF0.007C2450@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8193 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: <20031202223646.C7B60A0742@frink.w3.org> Resent-Date: Tue, 2 Dec 2003 17:36:46 -0500 (EST) This is a multipart message in MIME format. --=_alternative 007BB82885256DF0_= Content-Type: text/plain; charset="us-ascii" On Monday, 12/01/2003 at 01:30 PST, "Lisa Dusseault" wrote: > I don't have a problem with GULP. What I'm trying to do is make sure it > fits into the WebDAV specification. Sure, we could bung it in randomly, > any section remotely related to locking. Instead, however, I tried to > > - keep to the structure of the spec > - have the spec be linguistically consistent with GULP > - have the spec be logically consistent with GULP > > I'd still like to hear how this could be better, for example whether any > subtlety was lost in the way GULP was incorporated. > > But if you think this is irrelevant and you want to call a vote, Jim can > determine consensus. Please indicate where you would like me to put GULP > into RFC2518bis. An appendix? --=_alternative 007BB82885256DF0_= Content-Type: text/html; charset="us-ascii"
On Monday, 12/01/2003 at 01:30 PST, "Lisa Dusseault" <lisa@xythos.com> wrote:
> I don't have a problem with GULP.  What I'm trying to do is make sure it
> fits into the WebDAV specification.  Sure, we could bung it in randomly,
> any section remotely related to locking.  Instead, however, I tried to
>
> - keep to the structure of the spec
> - have the spec be linguistically consistent with GULP
> - have the spec be logically consistent with GULP
>
> I'd still like to hear how this could be better, for example whether any
> subtlety was lost in the way GULP was incorporated.
>
> But if you think this is irrelevant and you want to call a vote, Jim can
> determine consensus.  Please indicate where you would like me to put GULP
> into RFC2518bis.

An appendix?
--=_alternative 007BB82885256DF0_=-- From w3c-dist-auth-request@w3.org Wed Dec 3 10:08:38 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18307 for ; Wed, 3 Dec 2003 10:08:38 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id E4A9EA07C5; Wed, 3 Dec 2003 10:08:52 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 70255A065A for ; Wed, 3 Dec 2003 10:08:48 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 171BB13AEC; Wed, 3 Dec 2003 10:08:48 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 82E1A13AFC for ; Wed, 3 Dec 2003 10:08:47 -0500 (EST) Received: (qmail 27969 invoked by uid 65534); 3 Dec 2003 15:08:47 -0000 Received: from mail.greenbytes.de (EHLO gmx.de) (217.5.201.10) by mail.gmx.net (mp021) with SMTP; 03 Dec 2003 16:08:47 +0100 X-Authenticated: #1915285 Message-ID: <3FCDFC7E.3040102@gmx.de> Date: Wed, 03 Dec 2003 16:08:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Webdav WG'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: RFC Editors to WebDAV ordering protocol draft available X-Archived-At: http://www.w3.org/mid/3FCDFC7E.3040102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8194 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: <20031203150852.E4A9EA07C5@frink.w3.org> Resent-Date: Wed, 3 Dec 2003 10:08:52 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, I have updated the "latest" draft at to include the editorial changes made by the RFC-Editor. To potential reviewers: this is absolutely the last opportunity to complain about editorial issues. Note that some of those may be rolled back as they seem to change the intended meaning of the text. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Dec 3 11:46:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22917 for ; Wed, 3 Dec 2003 11:46:49 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id CE4B0A07AC; Wed, 3 Dec 2003 11:46:52 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8720BA07AC for ; Wed, 3 Dec 2003 11:46:48 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 5424013B33; Wed, 3 Dec 2003 11:46:48 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by dr-nick.w3.org (Postfix) with ESMTP id 418BA13B8A for ; Wed, 3 Dec 2003 11:46:48 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hB3Gklh3600210 for ; Wed, 3 Dec 2003 11:46:47 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB3Gkkdm186072 for ; Wed, 3 Dec 2003 11:46:46 -0500 In-Reply-To: <3FCDFC7E.3040102@gmx.de> To: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 3 Dec 2003 11:46:46 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 12/03/2003 11:46:46, Serialize complete at 12/03/2003 11:46:46 Content-Type: text/plain; charset="US-ASCII" Subject: Re: RFC Editors to WebDAV ordering protocol draft available X-Archived-At: http://www.w3.org/mid/OFB0B59503.96B7A4DE-ON85256DF1.005C09CF-85256DF1.005C2C2C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8195 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: <20031203164652.CE4B0A07AC@frink.w3.org> Resent-Date: Wed, 3 Dec 2003 11:46:52 -0500 (EST) The only changes I saw that needed to be rolled back were those in section 9.2. Were there any others? Cheers, Geoff Julian wrote on 12/03/2003 10:08:46 AM: > > Hi, > > I have updated the "latest" draft at > protocol-latest.html> > to include the editorial changes made by the RFC-Editor. > > To potential reviewers: this is absolutely the last opportunity to > complain about editorial issues. > > Note that some of those may be rolled back as they seem to change the > intended meaning of the text. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Dec 3 12:40:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25196 for ; Wed, 3 Dec 2003 12:40:29 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id ED34EA064F; Wed, 3 Dec 2003 12:37:14 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BF4C8A064F for ; Wed, 3 Dec 2003 12:37:09 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 928CE13EA9; Wed, 3 Dec 2003 12:36:54 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 244BC13E59 for ; Wed, 3 Dec 2003 12:36:54 -0500 (EST) Received: (qmail 12434 invoked by uid 65534); 3 Dec 2003 17:36:48 -0000 Received: from mail.greenbytes.de (EHLO gmx.de) (217.5.201.10) by mail.gmx.net (mp012) with SMTP; 03 Dec 2003 18:36:48 +0100 X-Authenticated: #1915285 Message-ID: <3FCE1F27.7050607@gmx.de> Date: Wed, 03 Dec 2003 18:36:39 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm Cc: "'Webdav WG'" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: RFC Editors to WebDAV ordering protocol draft available X-Archived-At: http://www.w3.org/mid/3FCE1F27.7050607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8196 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: <20031203173714.ED34EA064F@frink.w3.org> Resent-Date: Wed, 3 Dec 2003 12:37:14 -0500 (EST) Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > The only changes I saw that needed to be rolled back were > those in section 9.2. Were there any others? > > Cheers, > Geoff Yes, for instance the starting sequence of section 4.1.1: "A DAV:ordering-type (protected) indicates whether the...." If changed from the previous shorter text, it should be something like; "The DAV:ordering-type property indicates whether the...." Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Dec 3 15:35:11 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04536 for ; Wed, 3 Dec 2003 15:35:10 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 726D7A05F4; Wed, 3 Dec 2003 15:35:22 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id CAB3CA05F4 for ; Wed, 3 Dec 2003 15:35:18 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id AC24613560; Wed, 3 Dec 2003 15:35:18 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.iDatix.com (rrcs-se-24-73-205-106.biz.rr.com [24.73.205.106]) by dr-nick.w3.org (Postfix) with ESMTP id 6DA6E134B5 for ; Wed, 3 Dec 2003 15:35:18 -0500 (EST) Content-Class: urn:content-classes:message Date: Wed, 3 Dec 2003 15:35:18 -0500 Message-ID: <13380BDF8AA3964E9F72902D5B103C8705E19C@mail1.idatix.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B9DC.F6F0BB5E" Thread-Topic: WEBDAV and Web Services Interoperability X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcO53PbhiNAQO4JpQX6CYwaJcaBzMg== From: "Steve Lomicka" To: Subject: WEBDAV and Web Services Interoperability X-Archived-At: http://www.w3.org/mid/13380BDF8AA3964E9F72902D5B103C8705E19C@mail1.idatix.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8197 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: <20031203203522.726D7A05F4@frink.w3.org> Resent-Date: Wed, 3 Dec 2003 15:35:22 -0500 (EST) This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B9DC.F6F0BB5E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, =20 Congratulations Ms. Dusseault on your new book. I have a copy and it has saved me hours of spelunking time. I wish I had it two years ago when I first embraced WEBDAV........ =20 We are a small software company in the document management space. We are upgrading our existing server and I have strongly suggested to upper management that we use the WEBDAV protocol as the 'interface' (sorry) to our server. In a previous life, I developed a server that supported the WEBDAV protocol including a small subset of DASL and am aware of the benefits of utilizing WEBDAV. The owner of the company is leaning towards the Web Services camp. His rational for using Web Services is that an integrator using our document repository can "drag and drop" our service into the Microsoft .NET development environment and immediately begin integrating. I have already overcome all of the other business objections to WEBDAV but do not have an answer for this one. We have a data layer that supports our business rules and the plan was/is to expose it first using WEBDAV then expose it via Web Service in order to accommodate both environments. This is a lot of work for a company of our size. Is there a way to expose a WEBDAV server like a Web Service in a development environment? I realize that WEBDAV is a protocol and as such does not support discovery like a Web Service. Since it is a standard, it does reason that the methods in WEBDAV could be mapped to Web Services methods via some automatic conversion, translation etc. Any thoughts? =20 Thanks in advance for any and all information and suggestions. =20 Steve Team Lead www.iDatix.com =20 727-441-8228 ex29 =20 ------_=_NextPart_001_01C3B9DC.F6F0BB5E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Greetings,
 
   =20 Congratulations Ms. Dusseault on your new book.  I have a copy and = it has=20 saved me hours of spelunking time.  I wish I had it two years ago = when I=20 first embraced WEBDAV........
 
    We are a small software company in the = document=20 management space.  We are upgrading our existing server and I have = strongly=20 suggested to upper management that we use the WEBDAV protocol as the = 'interface'=20 (sorry) to our server.  In a previous life, I developed a=20 server that supported the WEBDAV protocol including a small subset = of DASL=20 and am aware of the benefits of utilizing WEBDAV.  The owner of the = company=20 is leaning towards the Web Services camp.  His rational for = using Web=20 Services is that an integrator using our document repository can = "drag and=20 drop" our service into the Microsoft .NET development environment and=20 immediately begin integrating.  I have already overcome all of the = other=20 business objections to WEBDAV but do not have an answer for this = one.  We=20 have a data layer that supports our business rules and the plan was/is = to expose=20 it first using WEBDAV then expose it via Web Service in order to=20 accommodate both environments.  This is a lot of work for a company = of our=20 size.  Is there a way to expose a WEBDAV server like a Web Service = in a=20 development environment?  I realize that WEBDAV is a protocol and = as such=20 does not support discovery like a Web Service.  Since it is a = standard, it=20 does reason that the methods in WEBDAV could be mapped to Web Services = methods=20 via some automatic conversion, translation etc.  Any=20 thoughts?
 
    Thanks in advance for any = and all=20 information and suggestions.
  =
Steve
Team Lead
727-441-8228 ex29
 
=00 ------_=_NextPart_001_01C3B9DC.F6F0BB5E-- From w3c-dist-auth-request@w3.org Wed Dec 3 17:32:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12992 for ; Wed, 3 Dec 2003 17:32:20 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 07339A082D; Wed, 3 Dec 2003 17:32:13 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 14E41A082D for ; Wed, 3 Dec 2003 17:32:09 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 0892513869; Wed, 3 Dec 2003 17:32:08 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 6D4C5137F2 for ; Wed, 3 Dec 2003 17:32:07 -0500 (EST) Received: from lisalap ([198.144.201.117]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Dec 2003 14:32:04 -0800 From: "Lisa Dusseault" To: "'Steve Lomicka'" , Date: Wed, 3 Dec 2003 14:32:14 -0800 Message-ID: <00f001c3b9ed$4d7f1e30$75c990c6@lisalap> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01C3B9AA.3F5BDE30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <13380BDF8AA3964E9F72902D5B103C8705E19C@mail1.idatix.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 03 Dec 2003 22:32:04.0545 (UTC) FILETIME=[46F67310:01C3B9ED] Subject: RE: WEBDAV and Web Services Interoperability X-Archived-At: http://www.w3.org/mid/00f001c3b9ed$4d7f1e30$75c990c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8198 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: <20031203223213.07339A082D@frink.w3.org> Resent-Date: Wed, 3 Dec 2003 17:32:13 -0500 (EST) This is a multi-part message in MIME format. ------=_NextPart_000_00F1_01C3B9AA.3F5BDE30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Steve, =20 That's a great question. I'm not an expert on how to drop a service = into .NET, but I assume that's a lot like writing an API. Does writing a Web Service really allow you to get a .NET API for free? Or does writing a = Web Service mostly involve writing a .NET API, and then the .NET framework translates those into SOAP magically for you? It sounds like you're = doing something a lot like what Xythos does, only for a .NET environment = instead of a java servlet environment. Xythos' WFS supports WebDAV, but we also support a java API to do custom development. We've architected WFS so = that the WebDAV server uses the same API that customers do. =20 As far as I know, there's no great answer for automatically converting = or translating WebDAV to a Web Service. But I don't see why you'd want to. Having a Web Service instead of a WebDAV server gives you nothing; = there's no client that will automatically work with your server if you support a = Web Service to do document management. =20 Is the goal really to have an API for .NET development, as well as = protocol support? That's not so hard to do with WebDAV, and there would be a lot = of overlap. If you develop an API with both WebDAV and .NET development in mind, then your WebDAV server could use your own API, the same one that customers use to integrate into .NET. That API would be strongly XML oriented, since both WebDAV and .NET use XML to format data. That gives = you an internal layer to your WebDAV server, but layering is always a good = idea for future improvements anyway. =20 =20 I'm sorry that this answer is so confused, but I'd always thought that = the Microsoft "Web Services and .NET magically integrate" messages were = mostly marketing fluff, and I've never bothered to really find out the = substance behind them. Maybe if you can fill in the blanks here we can come up = with a better answer. =20 Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On Behalf Of Steve Lomicka Sent: Wednesday, December 03, 2003 12:35 PM To: w3c-dist-auth@w3.org Subject: WEBDAV and Web Services Interoperability Greetings, =20 Congratulations Ms. Dusseault on your new book. I have a copy and = it has saved me hours of spelunking time. I wish I had it two years ago = when I first embraced WEBDAV........ =20 We are a small software company in the document management space. = We are upgrading our existing server and I have strongly suggested to upper management that we use the WEBDAV protocol as the 'interface' (sorry) to = our server. In a previous life, I developed a server that supported the = WEBDAV protocol including a small subset of DASL and am aware of the benefits = of utilizing WEBDAV. The owner of the company is leaning towards the Web Services camp. His rational for using Web Services is that an = integrator using our document repository can "drag and drop" our service into the Microsoft .NET development environment and immediately begin = integrating. I have already overcome all of the other business objections to WEBDAV but = do not have an answer for this one. We have a data layer that supports our business rules and the plan was/is to expose it first using WEBDAV then expose it via Web Service in order to accommodate both environments. = This is a lot of work for a company of our size. Is there a way to expose a WEBDAV server like a Web Service in a development environment? I = realize that WEBDAV is a protocol and as such does not support discovery like a = Web Service. Since it is a standard, it does reason that the methods in = WEBDAV could be mapped to Web Services methods via some automatic conversion, translation etc. Any thoughts? =20 Thanks in advance for any and all information and suggestions. =20 Steve Team Lead www.iDatix.com 727-441-8228 ex29 =20 ------=_NextPart_000_00F1_01C3B9AA.3F5BDE30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Steve,
 
That's=20 a great question.  I'm not an expert on how to drop a service into = .NET,=20 but I assume that's a lot like writing an API.  Does writing a Web = Service=20 really allow you to get a .NET API for free?   Or does = writing a=20 Web Service mostly involve writing a .NET API, and then the .NET = framework=20 translates those into SOAP magically for you?  It sounds like = you're doing=20 something a lot like what Xythos does, only for a .NET environment = instead of a=20 java servlet environment.  Xythos' WFS supports WebDAV, but we also = support=20 a java API to do custom development.  We've architected WFS so that = the=20 WebDAV server uses the same API that customers do.
 
As far=20 as I know, there's no great answer for automatically converting or = translating=20 WebDAV to a Web Service.  But I don't see why you'd want to.  = Having a=20 Web Service instead of a WebDAV server gives you nothing; there's no = client that=20 will automatically work with your server if you support a Web Service to = do=20 document management.
 
Is the=20 goal really to have an API for .NET development, as well as protocol=20 support?  That's not so hard to do with WebDAV, and there would be = a lot of=20 overlap.  If you develop an API with both WebDAV and .NET = development in=20 mind, then your WebDAV server could use your own API, the same one that=20 customers use to integrate into .NET.  That API would be strongly = XML=20 oriented, since both WebDAV and .NET use XML to format data.  That = gives=20 you an internal layer to your WebDAV server, but layering is always a = good idea=20 for future improvements anyway. 
 
I'm=20 sorry that this answer is so confused, but I'd always thought that the = Microsoft=20 "Web Services and .NET magically integrate" messages were mostly = marketing=20 fluff, and I've never bothered to really find out the substance behind=20 them.  Maybe if you can fill in the blanks here we can come up with = a=20 better answer.
 
Lisa
-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On=20 Behalf Of Steve Lomicka
Sent: Wednesday, December 03, = 2003 12:35=20 PM
To: w3c-dist-auth@w3.org
Subject: WEBDAV and = Web=20 Services Interoperability

Greetings,
 
   =20 Congratulations Ms. Dusseault on your new book.  I have a copy = and it has=20 saved me hours of spelunking time.  I wish I had it two years ago = when I=20 first embraced WEBDAV........
 
    We are a small software company in = the document=20 management space.  We are upgrading our existing server and I = have=20 strongly suggested to upper management that we use the WEBDAV protocol = as the=20 'interface' (sorry) to our server.  In a previous life, = I developed=20 a server that supported the WEBDAV protocol including a small = subset of=20 DASL and am aware of the benefits of utilizing WEBDAV.  The owner = of the=20 company is leaning towards the Web Services camp.  = His rational for=20 using Web Services is that an integrator using our document = repository=20 can "drag and drop" our service into the Microsoft .NET development=20 environment and immediately begin integrating.  I have already = overcome=20 all of the other business objections to WEBDAV but do not have an = answer for=20 this one.  We have a data layer that supports our business rules = and the=20 plan was/is to expose it first using WEBDAV then expose it via = Web=20 Service in order to accommodate both environments.  This is a lot = of work=20 for a company of our size.  Is there a way to expose a WEBDAV = server like=20 a Web Service in a development environment?  I realize that = WEBDAV is a=20 protocol and as such does not support discovery like a Web = Service. =20 Since it is a standard, it does reason that the methods in WEBDAV = could be=20 mapped to Web Services methods via some automatic conversion, = translation=20 etc.  Any thoughts?
 
    Thanks in advance for any and all = information=20 and suggestions.
 =20
Steve
Team Lead
727-441-8228 ex29
 
------=_NextPart_000_00F1_01C3B9AA.3F5BDE30-- From w3c-dist-auth-request@w3.org Sun Dec 7 23:01:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12327 for ; Sun, 7 Dec 2003 23:01:20 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 2D8BAA0989; Sun, 7 Dec 2003 23:01:33 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C5D6AA09DC for ; Sun, 7 Dec 2003 23:01:28 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 6024D13861; Sun, 7 Dec 2003 23:01:28 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (Postfix) with ESMTP id 1E34213853 for ; Sun, 7 Dec 2003 23:01:28 -0500 (EST) 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 hB841NoJ354128 for ; Sun, 7 Dec 2003 23:01:23 -0500 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB841L3a211008 for ; Sun, 7 Dec 2003 23:01:21 -0500 To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Sun, 7 Dec 2003 23:01:17 -0500 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.5HF149 | November 14, 2003) at 12/07/2003 23:01:21, Serialize complete at 12/07/2003 23:01:21 Content-Type: multipart/alternative; boundary="=_alternative 0014AFE285256DF6_=" Subject: RE: Bind issues X-Archived-At: http://www.w3.org/mid/OF63551779.ADED72CF-ON85256DF6.0013FF1B-85256DF6.001618F6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8199 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: <20031208040133.2D8BAA0989@frink.w3.org> Resent-Date: Sun, 7 Dec 2003 23:01:33 -0500 (EST) This is a multipart message in MIME format. --=_alternative 0014AFE285256DF6_= Content-Type: text/plain; charset="us-ascii" On Tuesday, 12/02/2003 at 05:35 EST, Jason Crawford wrote: > On Monday, 12/01/2003 at 01:30 PST, "Lisa Dusseault" wrote: > > I don't have a problem with GULP. What I'm trying to do is make sure it > > fits into the WebDAV specification. Sure, we could bung it in randomly, > > any section remotely related to locking. Instead, however, I tried to > > > > - keep to the structure of the spec > > - have the spec be linguistically consistent with GULP > > - have the spec be logically consistent with GULP > > > > I'd still like to hear how this could be better, for example whether any > > subtlety was lost in the way GULP was incorporated. > > > > But if you think this is irrelevant and you want to call a vote, Jim can > > determine consensus. Please indicate where you would like me to put GULP > > into RFC2518bis. > > An appendix? Sorry that I wasn't clear. I was suggesting that perhaps putting GULP in an appendix would satisfy Lisa's concerns about making sure it fits in the spec. But I'm not sure that even that addresses the concern about 2518bis being slow to press and us not wanting to wait for 2518bis before we can reference that text. Perhaps another option is to create a separate rfc for GULP. I assume it could be published faster that 2518bis and it could be referenced by multiple related documents without suggesting that it bears a special relationship with binding support. J. --=_alternative 0014AFE285256DF6_= Content-Type: text/html; charset="us-ascii"
On Tuesday, 12/02/2003 at 05:35 EST, Jason Crawford wrote:
> On Monday, 12/01/2003 at 01:30 PST, "Lisa Dusseault" <lisa@xythos.com> wrote:
> > I don't have a problem with GULP.  What I'm trying to do is make sure it
> > fits into the WebDAV specification.  Sure, we could bung it in randomly,
> > any section remotely related to locking.  Instead, however, I tried to
> >
> > - keep to the structure of the spec
> > - have the spec be linguistically consistent with GULP
> > - have the spec be logically consistent with GULP
> >
> > I'd still like to hear how this could be better, for example whether any
> > subtlety was lost in the way GULP was incorporated.
> >
> > But if you think this is irrelevant and you want to call a vote, Jim can
> > determine consensus.  Please indicate where you would like me to put GULP
> > into RFC2518bis.
>
> An appendix?

Sorry that I wasn't clear.  I was suggesting that perhaps putting GULP in an appendix would satisfy Lisa's concerns about making sure it fits in the spec.

But I'm not sure that even that addresses the concern about 2518bis being slow to press and us not wanting to wait for 2518bis before we can reference that text.  

Perhaps another option is to create a separate rfc for GULP.   I assume it could be published faster that 2518bis and it could be referenced by multiple related documents without suggesting that it bears a special relationship with binding support.

J.
  --=_alternative 0014AFE285256DF6_=-- From w3c-dist-auth-request@w3.org Sun Dec 7 23:01:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12349 for ; Sun, 7 Dec 2003 23:01:42 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id B8E39A09DB; Sun, 7 Dec 2003 23:01:40 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C52D4A09DB for ; Sun, 7 Dec 2003 23:01:28 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 679C013864; Sun, 7 Dec 2003 23:01:28 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id 1BE131378B for ; Sun, 7 Dec 2003 23:01:28 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hB841ODA730446 for ; Sun, 7 Dec 2003 23:01:24 -0500 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB841M1H121256 for ; Sun, 7 Dec 2003 23:01:23 -0500 To: w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Sun, 7 Dec 2003 23:01:19 -0500 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.5HF149 | November 14, 2003) at 12/07/2003 23:01:23, Serialize complete at 12/07/2003 23:01:23 Content-Type: multipart/alternative; boundary="=_alternative 00156A8485256DF6_=" Subject: RE: Resolving RFC2518 issue 55 ("DISPLAYNAME") X-Archived-At: http://www.w3.org/mid/OF3F4C4DA4.7FC5D2B1-ON85256DF6.001507EF-85256DF6.001619DA@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8200 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: <20031208040140.B8E39A09DB@frink.w3.org> Resent-Date: Sun, 7 Dec 2003 23:01:40 -0500 (EST) This is a multipart message in MIME format. --=_alternative 00156A8485256DF6_= Content-Type: text/plain; charset="us-ascii" That's fine with me. And if we find in a few years that even this dav:description property isn't being used, we might want to consider removing the feature. --=_alternative 00156A8485256DF6_= Content-Type: text/html; charset="us-ascii"
That's fine with me.   And if we find in a few years that even this dav:description property isn't being used, we might want to consider removing the feature.
--=_alternative 00156A8485256DF6_=-- From w3c-dist-auth-request@w3.org Mon Dec 8 04:24:25 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02183 for ; Mon, 8 Dec 2003 04:24:25 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 4577FA0551; Mon, 8 Dec 2003 04:24:40 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id D9325A0551 for ; Mon, 8 Dec 2003 04:24:27 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 6015C138DF; Mon, 8 Dec 2003 04:24:27 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id BB14C13861 for ; Mon, 8 Dec 2003 04:24:26 -0500 (EST) Received: (qmail 12399 invoked by uid 65534); 8 Dec 2003 09:24:20 -0000 Received: from p3EE2477E.dip.t-dialin.net (EHLO gmx.de) (62.226.71.126) by mail.gmx.net (mp002) with SMTP; 08 Dec 2003 10:24:20 +0100 X-Authenticated: #1915285 Message-ID: <3FD4433D.10204@gmx.de> Date: Mon, 08 Dec 2003 10:24:13 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Crawford Cc: w3c-dist-auth@w3c.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Resolving RFC2518 issue 55 ("DISPLAYNAME") X-Archived-At: http://www.w3.org/mid/3FD4433D.10204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8201 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: <20031208092440.4577FA0551@frink.w3.org> Resent-Date: Mon, 8 Dec 2003 04:24:40 -0500 (EST) Content-Transfer-Encoding: 7bit Jason Crawford wrote: > That's fine with me. And if we find in a few years that even this > dav:description property isn't being used, we might want to consider > removing the feature. The good thing is that we don't need to specify anything new. The only thing we do is to say that the property name DAV:description is reserved for the description of the resource, and that it must be authorable. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 8 04:27:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02280 for ; Mon, 8 Dec 2003 04:27:56 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 2663EA0551; Mon, 8 Dec 2003 04:28:11 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B0AF0A06ED for ; Mon, 8 Dec 2003 04:28:01 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 334C61397A; Mon, 8 Dec 2003 04:28:01 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id A982013977 for ; Mon, 8 Dec 2003 04:28:00 -0500 (EST) Received: (qmail 14793 invoked by uid 65534); 8 Dec 2003 09:27:59 -0000 Received: from p3EE2477E.dip.t-dialin.net (EHLO gmx.de) (62.226.71.126) by mail.gmx.net (mp023) with SMTP; 08 Dec 2003 10:27:59 +0100 X-Authenticated: #1915285 Message-ID: <3FD44418.1020806@gmx.de> Date: Mon, 08 Dec 2003 10:27:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Crawford Cc: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Bind issues X-Archived-At: http://www.w3.org/mid/3FD44418.1020806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8202 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: <20031208092811.2663EA0551@frink.w3.org> Resent-Date: Mon, 8 Dec 2003 04:28:11 -0500 (EST) Content-Transfer-Encoding: 7bit Jason Crawford wrote: > Perhaps another option is to create a separate rfc for GULP. I assume > it could be published faster that 2518bis and it could be referenced by > multiple related documents without suggesting that it bears a special > relationship with binding support. I thought about that as well. How about a separate document called "Locking Simplifications to WebDAV" that - contains GULP - contains the locking clarifications from RFC2518bis (refresh, lock-token header, submission of lock tokens) - contains the locking simplifications from RFC2518bis (lock-null) - contains the locking extensions from RFC2518bis as optional features (DAV:rootlock) This would become a Proposed Draft, updating but not obsoleting RFC2518 and RFC3253. If we can agree on scope and procedure, I'm willing to help writing it. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 8 08:34:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08943 for ; Mon, 8 Dec 2003 08:34:53 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 8AFC6A0627; Mon, 8 Dec 2003 08:35:07 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 67B76A0794 for ; Mon, 8 Dec 2003 08:35:00 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 40C251391F; Mon, 8 Dec 2003 08:35:00 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (Postfix) with ESMTP id 04EF9138FD for ; Mon, 8 Dec 2003 08:35:00 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hB8DYx9n473114 for ; Mon, 8 Dec 2003 08:34:59 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB8DYwWK217562 for ; Mon, 8 Dec 2003 08:34:58 -0500 In-Reply-To: <3FD44418.1020806@gmx.de> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 8 Dec 2003 08:34:53 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 12/08/2003 08:34:58, Serialize complete at 12/08/2003 08:34:58 Content-Type: multipart/alternative; boundary="=_alternative 004A968485256DF6_=" Subject: Re: Bind issues X-Archived-At: http://www.w3.org/mid/OFA7D30ADD.63E43401-ON85256DF6.004A75C5-85256DF6.004A968C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8203 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: <20031208133507.8AFC6A0627@frink.w3.org> Resent-Date: Mon, 8 Dec 2003 08:35:07 -0500 (EST) This is a multipart message in MIME format. --=_alternative 004A968485256DF6_= Content-Type: text/plain; charset="US-ASCII" Julian's proposal sounds good to me. I'm willing to help Julian write it. Cheers, Geoff Julian wrote on 12/08/2003 04:27:52 AM: > > Jason Crawford wrote: > > > Perhaps another option is to create a separate rfc for GULP. I assume > > it could be published faster that 2518bis and it could be referenced by > > multiple related documents without suggesting that it bears a special > > relationship with binding support. > > I thought about that as well. How about a separate document called > "Locking Simplifications to WebDAV" that > > - contains GULP > - contains the locking clarifications from RFC2518bis (refresh, > lock-token header, submission of lock tokens) > - contains the locking simplifications from RFC2518bis (lock-null) > - contains the locking extensions from RFC2518bis as optional features > (DAV:rootlock) > > This would become a Proposed Draft, updating but not obsoleting RFC2518 > and RFC3253. > > If we can agree on scope and procedure, I'm willing to help writing it. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 004A968485256DF6_= Content-Type: text/html; charset="US-ASCII"
Julian's proposal sounds good to me.  I'm willing to help Julian
write it.

Cheers,
Geoff

Julian wrote on 12/08/2003 04:27:52 AM:

>
> Jason Crawford wrote:
>
> > Perhaps another option is to create a separate rfc for GULP.   I assume
> > it could be published faster that 2518bis and it could be referenced by
> > multiple related documents without suggesting that it bears a special
> > relationship with binding support.
>
> I thought about that as well. How about a separate document called
> "Locking Simplifications to WebDAV" that
>
> - contains GULP
> - contains the locking clarifications from RFC2518bis (refresh,
> lock-token header, submission of lock tokens)
> - contains the locking simplifications from RFC2518bis (lock-null)
> - contains the locking extensions from RFC2518bis as optional features
> (DAV:rootlock)
>
> This would become a Proposed Draft, updating but not obsoleting RFC2518
> and RFC3253.
>
> If we can agree on scope and procedure, I'm willing to help writing it.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 004A968485256DF6_=-- From w3c-dist-auth-request@w3.org Tue Dec 9 05:52:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21673 for ; Tue, 9 Dec 2003 05:52:06 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 3591DA050E; Tue, 9 Dec 2003 05:52:21 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3CE21A050E for ; Tue, 9 Dec 2003 05:52:16 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id C037D13BD1; Tue, 9 Dec 2003 05:47:58 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 60FEE13A2F for ; Tue, 9 Dec 2003 05:47:58 -0500 (EST) Received: (qmail 2589 invoked by uid 65534); 9 Dec 2003 10:47:57 -0000 Received: from p50824089.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.64.137) by mail.gmx.net (mp009) with SMTP; 09 Dec 2003 11:47:57 +0100 X-Authenticated: #1915285 Message-ID: <3FD5A857.7060704@gmx.de> Date: Tue, 09 Dec 2003 11:47:51 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: BIND issue: 507 status code X-Archived-At: http://www.w3.org/mid/3FD5A857.7060704@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8204 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: <20031209105221.3591DA050E@frink.w3.org> Resent-Date: Tue, 9 Dec 2003 05:52:21 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, I note that section 4 refers to a definition of a 507 status code in Section 7.1, which doesn't exist. Should this text be replaced by a reference to the DAV:cross-server-binding precondition? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 9 06:01:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21858 for ; Tue, 9 Dec 2003 06:01:22 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 43AF8A0A3F; Tue, 9 Dec 2003 06:01:37 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B0145A068C for ; Tue, 9 Dec 2003 06:01:32 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 5DD9B13AE9; Tue, 9 Dec 2003 06:01:32 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id CC69913932 for ; Tue, 9 Dec 2003 06:01:31 -0500 (EST) Received: (qmail 15504 invoked by uid 65534); 9 Dec 2003 11:01:27 -0000 Received: from mail.greenbytes.de (EHLO gmx.de) (217.5.201.10) by mail.gmx.net (mp011) with SMTP; 09 Dec 2003 12:01:27 +0100 X-Authenticated: #1915285 Message-ID: <3FD5AB6F.60205@gmx.de> Date: Tue, 09 Dec 2003 12:01:03 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: BIND issue: references appendix X-Archived-At: http://www.w3.org/mid/3FD5AB6F.60205@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8205 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: <20031209110137.43AF8A0A3F@frink.w3.org> Resent-Date: Tue, 9 Dec 2003 06:01:37 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, checking the references section I note that: 1) we should distinguish between normative and informative references, 2) text referring to RFC2119 is missing (probably should be added to Terminology section) and 3) we have entries for RFC2277, RFC2616 and XML that aren't used in the text. Proposal for resolution: 1) Replace "References" to "Normative References", 2) Add paragraph from to section 1.1 3) Remove references to RFC2277 and RFC2616, add reference to XML in section 1.1. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 11 07:09:04 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26687 for ; Thu, 11 Dec 2003 07:09:04 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 6E2BDA0D43; Thu, 11 Dec 2003 07:09:06 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 91762A0D43 for ; Thu, 11 Dec 2003 07:09:01 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 2C53F1378F; Thu, 11 Dec 2003 07:09:01 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by dr-nick.w3.org (Postfix) with ESMTP id 668AF13FE9; Thu, 11 Dec 2003 07:08:57 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hBBC8sh3788762; Thu, 11 Dec 2003 07:08:54 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBBC8rqQ235690; Thu, 11 Dec 2003 07:08:53 -0500 In-Reply-To: <3FD5AB6F.60205@gmx.de> To: Julian Reschke Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 11 Dec 2003 07:08:49 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 12/11/2003 07:08:53, Serialize complete at 12/11/2003 07:08:53 Content-Type: text/plain; charset="US-ASCII" Subject: Re: BIND issue: references appendix X-Archived-At: http://www.w3.org/mid/OFE20F90C4.38CA6DF5-ON85256DF9.0042AC47-85256DF9.0042B51F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8206 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: <20031211120906.6E2BDA0D43@frink.w3.org> Resent-Date: Thu, 11 Dec 2003 07:09:06 -0500 (EST) I agree with those fixes. Cheers, Geoff Julian wrote on 12/09/2003 06:01:03 AM: > > Hi, > > checking the references section I note that: > > 1) we should distinguish between normative and informative references, > 2) text referring to RFC2119 is missing (probably should be added to > Terminology section) and > 3) we have entries for RFC2277, RFC2616 and XML that aren't used in the > text. > > Proposal for resolution: > > 1) Replace "References" to "Normative References", > > 2) Add paragraph from > html#rfc.section.1.2.p.2> > to section 1.1 > > 3) Remove references to RFC2277 and RFC2616, add reference to XML in > section 1.1. > > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Thu Dec 11 07:20:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27155 for ; Thu, 11 Dec 2003 07:20:53 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 636FEA0829; Thu, 11 Dec 2003 07:20:49 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 23BC5A0D0C for ; Thu, 11 Dec 2003 07:20:27 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 6D74214008; Thu, 11 Dec 2003 07:14:31 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by dr-nick.w3.org (Postfix) with ESMTP id 317BB14028 for ; Thu, 11 Dec 2003 07:14:31 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hBBCEVd6303600 for ; Thu, 11 Dec 2003 07:14:31 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBBCEUn1122550 for ; Thu, 11 Dec 2003 07:14:30 -0500 In-Reply-To: <3FD5A857.7060704@gmx.de> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 11 Dec 2003 07:14:26 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 12/11/2003 07:14:30, Serialize complete at 12/11/2003 07:14:30 Content-Type: text/plain; charset="US-ASCII" Subject: Re: BIND issue: 507 status code X-Archived-At: http://www.w3.org/mid/OFD485E38B.2EB6721F-ON85256DF9.00432940-85256DF9.004338D5@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8207 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: <20031211122049.636FEA0829@frink.w3.org> Resent-Date: Thu, 11 Dec 2003 07:20:49 -0500 (EST) Yes, thanks for catching that! Cheers, Geoff Julian wrote on 12/09/2003 05:47:51 AM: > > Hi, > > I note that section 4 refers to a definition of a 507 status code in > Section 7.1, which doesn't exist. Should this text be replaced by a > reference to the DAV:cross-server-binding precondition? > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Thu Dec 11 07:53:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28332 for ; Thu, 11 Dec 2003 07:53:58 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 2561EA0602; Thu, 11 Dec 2003 07:53:54 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BCFD7A0617 for ; Thu, 11 Dec 2003 07:53:42 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id DE8DC1404F; Thu, 11 Dec 2003 07:48:13 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 6090C1404D for ; Thu, 11 Dec 2003 07:48:13 -0500 (EST) Received: (qmail 23317 invoked by uid 65534); 11 Dec 2003 12:48:07 -0000 Received: from p50824B6F.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.75.111) by mail.gmx.net (mp007) with SMTP; 11 Dec 2003 13:48:07 +0100 X-Authenticated: #1915285 Message-ID: <3FD8677B.5050307@gmx.de> Date: Thu, 11 Dec 2003 13:47:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm Cc: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: BIND issue: 507 status code X-Archived-At: http://www.w3.org/mid/3FD8677B.5050307@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8208 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: <20031211125354.2561EA0602@frink.w3.org> Resent-Date: Thu, 11 Dec 2003 07:53:54 -0500 (EST) Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > Yes, thanks for catching that! > > Cheers, > Geoff OK, a new version is online at Issues list: Unless there are other new open issues brought up, I'll submit this as draft -03. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 11 13:30:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13145 for ; Thu, 11 Dec 2003 13:30:35 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id D6239A0543; Thu, 11 Dec 2003 13:30:35 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 1511FA0558 for ; Thu, 11 Dec 2003 13:30:32 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id EB3C513547; Thu, 11 Dec 2003 13:30:31 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by dr-nick.w3.org (Postfix) with ESMTP id 6C34C13444 for ; Thu, 11 Dec 2003 13:30:31 -0500 (EST) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hBBIUUnc020511 for ; Thu, 11 Dec 2003 10:30:30 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 11 Dec 2003 10:30:28 -0800 Received: from [17.219.197.154] ([17.219.197.154]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id hBBITs0m022546; Thu, 11 Dec 2003 10:29:54 -0800 (PST) In-Reply-To: <1693B4A4-168D-11D8-A8E2-00039384827E@greenbytes.de> References: <35F86684-161D-11D8-B03D-000393751598@xythos.com> <1693B4A4-168D-11D8-A8E2-00039384827E@greenbytes.de> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <189E09D8-2C08-11D8-9607-003065B4EF3A@apple.com> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org, Brian Korver From: Chris Sharp Date: Thu, 11 Dec 2003 10:30:29 -0800 To: Stefan Eissing X-Mailer: Apple Mail (2.606) Subject: Re: Review of draft-ietf-webdav-quota-02.txt X-Archived-At: http://www.w3.org/mid/189E09D8-2C08-11D8-9607-003065B4EF3A@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8209 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: <20031211183035.D6239A0543@frink.w3.org> Resent-Date: Thu, 11 Dec 2003 13:30:35 -0500 (EST) Content-Transfer-Encoding: 7bit Just getting around to understanding this thread. I totally agree, the quota-assigned-bytes seems unnecessary and confusing. On another note, I think there needs to be some clarification the way quota-available-bytes and quota-used-bytes work. Example: Initial State of Repository with a Quota management system: DAV:quota-available-bytes DAV:quota-used-bytes /A 95MB 5MG <--- used for somewhere for something /A/UploadDirectory 10MB 0 A new 5MB resource is created at /A/UploadDirectory/new5MBFile: DAV:quota-available-bytes DAV:quota-used-bytes /A 90MB 10MB /A/UploadDirectory 5MB 5MB Pretty clear, however, if there is no quota differentiation on /A/UploadDirectory, the current draft of the RFC makes quota-used-bytes, which is really inherited from its parent, incongruent with quota-available-bytes on the same resource. A diagram is in order: Initial State of Repository with a Quota management system: (quota system on /A only) DAV:quota-available-bytes DAV:quota-used-bytes /A 95MB 5MG A new 5MB resource is created at /A/UploadDirectory/new5MBFile: DAV:quota-available-bytes DAV:quota-used-bytes /A 90MB 10MB /A/UploadDirectory 90MB 5MB The sum of quota-available-bytes and quota-used-bytes is 95 on /A/UploadDirectory and not 100! Logically, if you get a request for quota-available-bytes on a resource /A/UploadDirectory and the quota is actually enforced on the parent, that you would essentially walk up the tree until you found an appropriate "mount point" based quota requirement. If this is true, the quota-used-bytes should do the same thing. Meaning, quota-used-bytes on /A/UploadDirectory would be the same as quota-used-bytes /A if /A/UploadDirectory did not contain a more specific quota rule. This is also an efficiency win for implementors. If an implementation has to support quota-used-bytes on an arbitrary URL, it is impractical to think that quota-used-bytes could be incrementally adjusted and would necessarily need to be calculated on-the-fly, which does not scale well for most implementations. How NFSv4 handles this situation? Also, under the "Notes" section, "What clients should expect" seems to have a sentence which is not grammatically correct. "This allows the space used by /~milele/public/ to be as large as the quota on /~milele/ allows (depending on the other contents of /~milele/) even if the quota on /~milele/ is changed." Regards, Chris. On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote: > > Brian, > > I put my mind into blank slate mode and read the draft 2 for the first > time. > > I think it is a big improvment from where we started from. One item I > found > confusing though and that is the example for DAV:quota-assigned-bytes > (and the mental model behind the example). > > The draft seems to say that /A and /A/B have separate > DAV:quota-assigned-bytes > properties, however they are in the same "set of collections" when the > value > of DAV:quota-available-bytes/DAV:quota-used-bytes is computed. > > (See definition of "set" in the explanation to DAV:quota-used-bytes - > seems to > be a copy from the NFS spec.) > > In NFS-Quota, the model seems to be simple: each quota applies to a set > of collections/files and each member of this set would report the same > quota properties. > > In WebDAV-quota (draft-2): there is a separate quota for each > collection > (e.g. the assigned-bytes), but available-/used-bytes are the same for > resources in the same set. > > Two Problems come to my mind now: > 1) If a collection of the "set" has the DAV:quota-assigned-bytes not > explicitly set, what value would it report? Say for /A/C, /A/B/D and > /E (all in the same set)? > > 2) If a client wants to increase DAV:quota-available-bytes in a certain > collection, it has to increase the DAV:quota-assigned-bytes. But in > your example: increasing assigned-bytes on /A/B will not have any > effect on the DAV:quota-available-bytes. What is a generic client > supposed > to do then? > > Best Regards, Stefan > > Am 13.11.2003 um 22:06 schrieb Brian Korver: > >> >> On Thursday, November 13, 2003, at 01:14 PM, Julian Reschke wrote: >>> Brian, >>> >>> when I re-raised these issues, I *did* read the current draft. So I >>> think it's up to you to go back to the mailing list discussion and >>> explain why the concerns raised by Stefan and myself aren't valid. >>> >>> Julian >> >> Julian, >> >> I'm planning to do so in today's meeting, but to restate for the >> mailing list, >> Stefan pointed out that if we used quota-limit, then quota-limit >> would not be >> a fixed value (which is the reason we defined things in terms of >> quota-limit >> to begin with). Thus, instead of quota-limit, the new draft uses >> NFS's >> quota-available. This has the semantics that it isn't fixed. >> Problem solved. >> Note, quota-available is consistent with the rest of the the quota >> definitions >> we pulled from NFS, so it's conceptually attractive too. >> >> I still don't know what you find confusing, so I can't comment on >> that yet. >> >> -brian >> briank@xythos.com > From w3c-dist-auth-request@w3.org Thu Dec 11 13:53:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14099 for ; Thu, 11 Dec 2003 13:53:20 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 68F5EA0543; Thu, 11 Dec 2003 13:53:21 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9AC9FA0543 for ; Thu, 11 Dec 2003 13:53:17 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 56584138F4; Thu, 11 Dec 2003 13:53:17 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 698FE13547 for ; Thu, 11 Dec 2003 13:53:13 -0500 (EST) Received: from [192.168.1.151] ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Dec 2003 10:53:12 -0800 In-Reply-To: <189E09D8-2C08-11D8-9607-003065B4EF3A@apple.com> References: <35F86684-161D-11D8-B03D-000393751598@xythos.com> <1693B4A4-168D-11D8-A8E2-00039384827E@greenbytes.de> <189E09D8-2C08-11D8-9607-003065B4EF3A@apple.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <44E15905-2C0B-11D8-8BCD-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: WebDAV From: Brian Korver Date: Thu, 11 Dec 2003 10:53:11 -0800 To: Chris Sharp X-Mailer: Apple Mail (2.606) X-OriginalArrivalTime: 11 Dec 2003 18:53:12.0494 (UTC) FILETIME=[06F47CE0:01C3C018] Subject: Re: Review of draft-ietf-webdav-quota-02.txt X-Archived-At: http://www.w3.org/mid/44E15905-2C0B-11D8-8BCD-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8210 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: <20031211185321.68F5EA0543@frink.w3.org> Resent-Date: Thu, 11 Dec 2003 13:53:21 -0500 (EST) Content-Transfer-Encoding: 7bit On Dec 11, 2003, at 10:30 AM, Chris Sharp wrote: > Just getting around to understanding this thread. I totally agree, the > quota-assigned-bytes seems unnecessary and confusing. It does seem to be confusing to people. Do you have a proposal for an alternative mechanism (or at least wording) that accomplishes the same thing? Specifically, a mechanism set the quota (especially in face of quota systems like the one you give in the example where quota constraints are inherited from the parent)? > > On another note, I think there needs to be some clarification the way > quota-available-bytes and quota-used-bytes work. > > Example: > > Initial State of Repository with a Quota management system: > > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 95MB > 5MG <--- used for somewhere for > something > /A/UploadDirectory 10MB > 0 > > A new 5MB resource is created at /A/UploadDirectory/new5MBFile: > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 90MB > 10MB > /A/UploadDirectory 5MB > 5MB > > Pretty clear, however, if there is no quota differentiation on > /A/UploadDirectory, the current draft of the RFC makes > quota-used-bytes, which is really inherited from its parent, > incongruent with quota-available-bytes on the same resource. That's just one example of a quota system. As the draft points out: Note that this is only one example quota system, and that other quota systems are possible. Do you think the text would benefit from having an example given using a different quota system? I'm starting to think that would be a good idea. The draft does not mandate any particular quota system. IMHO it would be a bad idea to do so. > A diagram is in order: > > Initial State of Repository with a Quota management system: > (quota system on /A only) > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 95MB > 5MG > > A new 5MB resource is created at /A/UploadDirectory/new5MBFile: > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 90MB > 10MB > /A/UploadDirectory 90MB > 5MB > > The sum of quota-available-bytes and quota-used-bytes is 95 on > /A/UploadDirectory and not 100! Logically, if you get a request for > quota-available-bytes on a resource /A/UploadDirectory and the quota > is actually enforced on the parent, that you would essentially walk up > the tree until you found an appropriate "mount point" based quota > requirement. If this is true, the quota-used-bytes should do the same > thing. Meaning, quota-used-bytes on /A/UploadDirectory would be the > same as quota-used-bytes /A if /A/UploadDirectory did not contain a > more specific quota rule. > > This is also an efficiency win for implementors. If an implementation > has to support quota-used-bytes on an arbitrary URL, it is impractical > to think that quota-used-bytes could be incrementally adjusted and > would necessarily need to be calculated on-the-fly, which does not > scale well for most implementations. > > How NFSv4 handles this situation? > > > Also, under the "Notes" section, "What clients should expect" seems to > have a sentence which is not grammatically correct. > "This allows the space used by /~milele/public/ to be as > large as the quota on /~milele/ allows (depending on the other > contents of /~milele/) even if the quota on /~milele/ is changed." > > Regards, > > Chris. > On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote: > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Thu Dec 11 16:30:55 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26305 for ; Thu, 11 Dec 2003 16:30:54 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 0D550A0CF6; Thu, 11 Dec 2003 16:30:55 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id ECCBBA0DA6 for ; Thu, 11 Dec 2003 16:30:20 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id BF05C1411D; Thu, 11 Dec 2003 16:26:28 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by dr-nick.w3.org (Postfix) with ESMTP id 7B284140F4 for ; Thu, 11 Dec 2003 16:26:28 -0500 (EST) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by agminet01.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hBBLQSZv031401 for ; Thu, 11 Dec 2003 13:26:28 -0800 Received: from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id hBBLQRb03518 for ; Thu, 11 Dec 2003 14:26:27 -0700 (MST) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id hBBLQQb03502 for ; Thu, 11 Dec 2003 14:26:26 -0700 (MST) Message-ID: <04fe01c3c02d$6f131a10$c5b42382@us.oracle.com> From: "Stanley Guan" To: Date: Thu, 11 Dec 2003 13:26:26 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04FB_01C3BFEA.60BDCD90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: deadprops -> deadprop X-Archived-At: http://www.w3.org/mid/04fe01c3c02d$6f131a10$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8211 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: <20031211213055.0D550A0CF6@frink.w3.org> Resent-Date: Thu, 11 Dec 2003 16:30:55 -0500 (EST) This is a multi-part message in MIME format. ------=_NextPart_000_04FB_01C3BFEA.60BDCD90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The new XML element name "deadprops" doesn't seem to match the naming style of others: allprop or propname. So, I propose to drop "s" from "deadprops". ------=_NextPart_000_04FB_01C3BFEA.60BDCD90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The new XML element name "deadprops" = doesn't seem=20 to match
the naming style of others:  = allprop=20 or propname.
 
So, I propose to drop "s" from=20 "deadprops".
------=_NextPart_000_04FB_01C3BFEA.60BDCD90-- From w3c-dist-auth-request@w3.org Thu Dec 11 16:49:14 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27349 for ; Thu, 11 Dec 2003 16:49:13 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 31DF2A0D3F; Thu, 11 Dec 2003 16:49:15 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BD11EA0D5D for ; Thu, 11 Dec 2003 16:49:08 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 80450136A4; Thu, 11 Dec 2003 16:49:08 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id DBC9A138DE for ; Thu, 11 Dec 2003 16:49:07 -0500 (EST) Received: (qmail 30337 invoked by uid 65534); 11 Dec 2003 21:49:02 -0000 Received: from p3EE24717.dip.t-dialin.net (EHLO gmx.de) (62.226.71.23) by mail.gmx.net (mp015) with SMTP; 11 Dec 2003 22:49:02 +0100 X-Authenticated: #1915285 Message-ID: <3FD8E63B.1080908@gmx.de> Date: Thu, 11 Dec 2003 22:48:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stanley Guan Cc: w3c-dist-auth@w3.org References: <04fe01c3c02d$6f131a10$c5b42382@us.oracle.com> In-Reply-To: <04fe01c3c02d$6f131a10$c5b42382@us.oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: deadprops -> deadprop X-Archived-At: http://www.w3.org/mid/3FD8E63B.1080908@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8212 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: <20031211214915.31DF2A0D3F@frink.w3.org> Resent-Date: Thu, 11 Dec 2003 16:49:15 -0500 (EST) Content-Transfer-Encoding: 7bit Stanley Guan wrote: > The new XML element name "deadprops" doesn't seem to match > the naming style of others: allprop or propname. > > So, I propose to drop "s" from "deadprops". The name of the property has been agreed upon during the meeting back in January. People have implemented it, and shipping code uses it. Of course this is just an Internet Draft, but there's no reason to break existing and shipping code just for the sake of renaming something. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 12 04:34:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02507 for ; Fri, 12 Dec 2003 04:34:26 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id EAC6BA080C; Fri, 12 Dec 2003 04:34:26 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A8CA3A080C for ; Fri, 12 Dec 2003 04:34:20 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 83652135C8; Fri, 12 Dec 2003 04:34:20 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from greenbytes.de (unknown [217.5.201.10]) by dr-nick.w3.org (Postfix) with ESMTP id 118B5134D1 for ; Fri, 12 Dec 2003 04:34:19 -0500 (EST) Received: from 192.168.1.26 ([192.168.1.26]) (authenticated user se@greenbytes.de) by greenbytes.de (greenbytes.de [217.5.201.11]) (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v6.8.5.R) with ESMTP id 50-md50000000078.tmp for ; Fri, 12 Dec 2003 10:33:09 +0100 In-Reply-To: <189E09D8-2C08-11D8-9607-003065B4EF3A@apple.com> References: <35F86684-161D-11D8-B03D-000393751598@xythos.com> <1693B4A4-168D-11D8-A8E2-00039384827E@greenbytes.de> <189E09D8-2C08-11D8-9607-003065B4EF3A@apple.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0F49B0A0-2C86-11D8-BA59-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org, Brian Korver From: Stefan Eissing Date: Fri, 12 Dec 2003 10:32:10 +0100 To: Chris Sharp X-Mailer: Apple Mail (2.606) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Fri, 12 Dec 2003 10:33:09 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: Review of draft-ietf-webdav-quota-02.txt X-Archived-At: http://www.w3.org/mid/0F49B0A0-2C86-11D8-BA59-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8213 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: <20031212093426.EAC6BA080C@frink.w3.org> Resent-Date: Fri, 12 Dec 2003 04:34:26 -0500 (EST) Content-Transfer-Encoding: 7bit Chris, I agree to your analysis that the current definitions lead to confusion. The way out is to simplify the underlying model. Definition: a "quota space" is a storage area on the server where allocation can be restricted. All collections on a server either belong to a particular quota space or to no quota space at all (in which case storage allocation, if possible, in such collections cannot be controlled by quotas). Corollary1: all collections of a particular quota space report the same values for their DAV:quota* properties. Corollary2: all resources belong to the same quota space as their parent collection(s). Corollary3: all collections which may contain bindings to the same resource do belong to the same quota space. Collections in different quota spaces cannot have bindings to the same resource. With this model, /A and /A/UploadDirectory will either have the same DAV:quota* values or totally unrelated ones, depending if the two collections belong to the same or to different quota spaces. Thus the problem of "it does not sum up" is avoided. Also, server side implementation can be much simpler, as the hiearchies (e.g. bindings) of collections and resources do *not* influence the quota values. //Stefan Am 11.12.2003 um 19:30 schrieb Chris Sharp: > Just getting around to understanding this thread. I totally agree, the > quota-assigned-bytes seems unnecessary and confusing. > > On another note, I think there needs to be some clarification the way > quota-available-bytes and quota-used-bytes work. > > Example: > > Initial State of Repository with a Quota management system: > > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 95MB > 5MG <--- used for somewhere for > something > /A/UploadDirectory 10MB > 0 > > A new 5MB resource is created at /A/UploadDirectory/new5MBFile: > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 90MB > 10MB > /A/UploadDirectory 5MB > 5MB > > Pretty clear, however, if there is no quota differentiation on > /A/UploadDirectory, the current draft of the RFC makes > quota-used-bytes, which is really inherited from its parent, > incongruent with quota-available-bytes on the same resource. A diagram > is in order: > > Initial State of Repository with a Quota management system: > (quota system on /A only) > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 95MB > 5MG > > A new 5MB resource is created at /A/UploadDirectory/new5MBFile: > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 90MB > 10MB > /A/UploadDirectory 90MB > 5MB > > The sum of quota-available-bytes and quota-used-bytes is 95 on > /A/UploadDirectory and not 100! Logically, if you get a request for > quota-available-bytes on a resource /A/UploadDirectory and the quota > is actually enforced on the parent, that you would essentially walk up > the tree until you found an appropriate "mount point" based quota > requirement. If this is true, the quota-used-bytes should do the same > thing. Meaning, quota-used-bytes on /A/UploadDirectory would be the > same as quota-used-bytes /A if /A/UploadDirectory did not contain a > more specific quota rule. > > This is also an efficiency win for implementors. If an implementation > has to support quota-used-bytes on an arbitrary URL, it is impractical > to think that quota-used-bytes could be incrementally adjusted and > would necessarily need to be calculated on-the-fly, which does not > scale well for most implementations. > > How NFSv4 handles this situation? > > > Also, under the "Notes" section, "What clients should expect" seems to > have a sentence which is not grammatically correct. > "This allows the space used by /~milele/public/ to be as > large as the quota on /~milele/ allows (depending on the other > contents of /~milele/) even if the quota on /~milele/ is changed." > > Regards, > > Chris. > On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote: > >> >> Brian, >> >> I put my mind into blank slate mode and read the draft 2 for the >> first time. >> >> I think it is a big improvment from where we started from. One item I >> found >> confusing though and that is the example for DAV:quota-assigned-bytes >> (and the mental model behind the example). >> >> The draft seems to say that /A and /A/B have separate >> DAV:quota-assigned-bytes >> properties, however they are in the same "set of collections" when >> the value >> of DAV:quota-available-bytes/DAV:quota-used-bytes is computed. >> >> (See definition of "set" in the explanation to DAV:quota-used-bytes - >> seems to >> be a copy from the NFS spec.) >> >> In NFS-Quota, the model seems to be simple: each quota applies to a >> set >> of collections/files and each member of this set would report the same >> quota properties. >> >> In WebDAV-quota (draft-2): there is a separate quota for each >> collection >> (e.g. the assigned-bytes), but available-/used-bytes are the same for >> resources in the same set. >> >> Two Problems come to my mind now: >> 1) If a collection of the "set" has the DAV:quota-assigned-bytes not >> explicitly set, what value would it report? Say for /A/C, /A/B/D and >> /E (all in the same set)? >> >> 2) If a client wants to increase DAV:quota-available-bytes in a >> certain >> collection, it has to increase the DAV:quota-assigned-bytes. But in >> your example: increasing assigned-bytes on /A/B will not have any >> effect on the DAV:quota-available-bytes. What is a generic client >> supposed >> to do then? >> >> Best Regards, Stefan >> >> Am 13.11.2003 um 22:06 schrieb Brian Korver: >> >>> >>> On Thursday, November 13, 2003, at 01:14 PM, Julian Reschke wrote: >>>> Brian, >>>> >>>> when I re-raised these issues, I *did* read the current draft. So I >>>> think it's up to you to go back to the mailing list discussion and >>>> explain why the concerns raised by Stefan and myself aren't valid. >>>> >>>> Julian >>> >>> Julian, >>> >>> I'm planning to do so in today's meeting, but to restate for the >>> mailing list, >>> Stefan pointed out that if we used quota-limit, then quota-limit >>> would not be >>> a fixed value (which is the reason we defined things in terms of >>> quota-limit >>> to begin with). Thus, instead of quota-limit, the new draft uses >>> NFS's >>> quota-available. This has the semantics that it isn't fixed. >>> Problem solved. >>> Note, quota-available is consistent with the rest of the the quota >>> definitions >>> we pulled from NFS, so it's conceptually attractive too. >>> >>> I still don't know what you find confusing, so I can't comment on >>> that yet. >>> >>> -brian >>> briank@xythos.com >> From w3c-dist-auth-request@w3.org Fri Dec 12 10:05:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10168 for ; Fri, 12 Dec 2003 10:05:36 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 2C82FA080A; Fri, 12 Dec 2003 10:05:35 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 177B7A080A for ; Fri, 12 Dec 2003 10:05:29 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id B0EBB133F3; Fri, 12 Dec 2003 10:05:28 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by dr-nick.w3.org (Postfix) with ESMTP id 718C7133D0 for ; Fri, 12 Dec 2003 10:05:28 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hBCF5Rh3023162 for ; Fri, 12 Dec 2003 10:05:27 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBCF5Qlh114012 for ; Fri, 12 Dec 2003 10:05:26 -0500 In-Reply-To: <0F49B0A0-2C86-11D8-BA59-00039384827E@greenbytes.de> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 12 Dec 2003 10:05:12 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 12/12/2003 10:06:23, Serialize complete at 12/12/2003 10:06:23 Content-Type: text/plain; charset="US-ASCII" Subject: Re: Review of draft-ietf-webdav-quota-02.txt X-Archived-At: http://www.w3.org/mid/OF55A7AB07.3FAEDF19-ON85256DFA.0052BEEB-85256DFA.0052DB32@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8214 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: <20031212150535.2C82FA080A@frink.w3.org> Resent-Date: Fri, 12 Dec 2003 10:05:35 -0500 (EST) I assume in Corollary2, by "all resources", you mean "all non-collection resources" ? Cheers, Geoff Stefan wrote on 12/12/2003 04:32:10 AM: > > Chris, > > I agree to your analysis that the current definitions lead to > confusion. The way out > is to simplify the underlying model. > > Definition: a "quota space" is a storage area on the server where > allocation can > be restricted. All collections on a server either belong to a > particular quota space > or to no quota space at all (in which case storage allocation, if > possible, in such > collections cannot be controlled by quotas). > > Corollary1: all collections of a particular quota space report the same > values for > their DAV:quota* properties. > > Corollary2: all resources belong to the same quota space as their > parent collection(s). > > Corollary3: all collections which may contain bindings to the same > resource do > belong to the same quota space. Collections in different quota spaces > cannot > have bindings to the same resource. > > With this model, /A and /A/UploadDirectory will either have the same > DAV:quota* > values or totally unrelated ones, depending if the two collections > belong to the > same or to different quota spaces. Thus the problem of "it does not sum > up" is > avoided. Also, server side implementation can be much simpler, as the > hiearchies > (e.g. bindings) of collections and resources do *not* influence the > quota values. > > //Stefan > > Am 11.12.2003 um 19:30 schrieb Chris Sharp: > > > Just getting around to understanding this thread. I totally agree, the > > quota-assigned-bytes seems unnecessary and confusing. > > > > On another note, I think there needs to be some clarification the way > > quota-available-bytes and quota-used-bytes work. > > > > Example: > > > > Initial State of Repository with a Quota management system: > > > > > > DAV:quota-available-bytes DAV:quota-used-bytes > > /A 95MB > > 5MG <--- used for somewhere for > > something > > /A/UploadDirectory 10MB > > 0 > > > > A new 5MB resource is created at /A/UploadDirectory/new5MBFile: > > > > DAV:quota-available-bytes DAV:quota-used-bytes > > /A 90MB > > 10MB > > /A/UploadDirectory 5MB > > 5MB > > > > Pretty clear, however, if there is no quota differentiation on > > /A/UploadDirectory, the current draft of the RFC makes > > quota-used-bytes, which is really inherited from its parent, > > incongruent with quota-available-bytes on the same resource. A diagram > > is in order: > > > > Initial State of Repository with a Quota management system: > > (quota system on /A only) > > > > DAV:quota-available-bytes DAV:quota-used-bytes > > /A 95MB > > 5MG > > > > A new 5MB resource is created at /A/UploadDirectory/new5MBFile: > > > > DAV:quota-available-bytes DAV:quota-used-bytes > > /A 90MB > > 10MB > > /A/UploadDirectory 90MB > > 5MB > > > > The sum of quota-available-bytes and quota-used-bytes is 95 on > > /A/UploadDirectory and not 100! Logically, if you get a request for > > quota-available-bytes on a resource /A/UploadDirectory and the quota > > is actually enforced on the parent, that you would essentially walk up > > the tree until you found an appropriate "mount point" based quota > > requirement. If this is true, the quota-used-bytes should do the same > > thing. Meaning, quota-used-bytes on /A/UploadDirectory would be the > > same as quota-used-bytes /A if /A/UploadDirectory did not contain a > > more specific quota rule. > > > > This is also an efficiency win for implementors. If an implementation > > has to support quota-used-bytes on an arbitrary URL, it is impractical > > to think that quota-used-bytes could be incrementally adjusted and > > would necessarily need to be calculated on-the-fly, which does not > > scale well for most implementations. > > > > How NFSv4 handles this situation? > > > > > > Also, under the "Notes" section, "What clients should expect" seems to > > have a sentence which is not grammatically correct. > > "This allows the space used by /~milele/public/ to be as > > large as the quota on /~milele/ allows (depending on the other > > contents of /~milele/) even if the quota on /~milele/ is changed." > > > > Regards, > > > > Chris. > > On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote: > > > >> > >> Brian, > >> > >> I put my mind into blank slate mode and read the draft 2 for the > >> first time. > >> > >> I think it is a big improvment from where we started from. One item I > >> found > >> confusing though and that is the example for DAV:quota-assigned-bytes > >> (and the mental model behind the example). > >> > >> The draft seems to say that /A and /A/B have separate > >> DAV:quota-assigned-bytes > >> properties, however they are in the same "set of collections" when > >> the value > >> of DAV:quota-available-bytes/DAV:quota-used-bytes is computed. > >> > >> (See definition of "set" in the explanation to DAV:quota-used-bytes - > >> seems to > >> be a copy from the NFS spec.) > >> > >> In NFS-Quota, the model seems to be simple: each quota applies to a > >> set > >> of collections/files and each member of this set would report the same > >> quota properties. > >> > >> In WebDAV-quota (draft-2): there is a separate quota for each > >> collection > >> (e.g. the assigned-bytes), but available-/used-bytes are the same for > >> resources in the same set. > >> > >> Two Problems come to my mind now: > >> 1) If a collection of the "set" has the DAV:quota-assigned-bytes not > >> explicitly set, what value would it report? Say for /A/C, /A/B/D and > >> /E (all in the same set)? > >> > >> 2) If a client wants to increase DAV:quota-available-bytes in a > >> certain > >> collection, it has to increase the DAV:quota-assigned-bytes. But in > >> your example: increasing assigned-bytes on /A/B will not have any > >> effect on the DAV:quota-available-bytes. What is a generic client > >> supposed > >> to do then? > >> > >> Best Regards, Stefan > >> > >> Am 13.11.2003 um 22:06 schrieb Brian Korver: > >> > >>> > >>> On Thursday, November 13, 2003, at 01:14 PM, Julian Reschke wrote: > >>>> Brian, > >>>> > >>>> when I re-raised these issues, I *did* read the current draft. So I > >>>> think it's up to you to go back to the mailing list discussion and > >>>> explain why the concerns raised by Stefan and myself aren't valid. > >>>> > >>>> Julian > >>> > >>> Julian, > >>> > >>> I'm planning to do so in today's meeting, but to restate for the > >>> mailing list, > >>> Stefan pointed out that if we used quota-limit, then quota-limit > >>> would not be > >>> a fixed value (which is the reason we defined things in terms of > >>> quota-limit > >>> to begin with). Thus, instead of quota-limit, the new draft uses > >>> NFS's > >>> quota-available. This has the semantics that it isn't fixed. > >>> Problem solved. > >>> Note, quota-available is consistent with the rest of the the quota > >>> definitions > >>> we pulled from NFS, so it's conceptually attractive too. > >>> > >>> I still don't know what you find confusing, so I can't comment on > >>> that yet. > >>> > >>> -brian > >>> briank@xythos.com > >> > From w3c-dist-auth-request@w3.org Fri Dec 12 10:19:55 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11849 for ; Fri, 12 Dec 2003 10:19:54 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 82620A0977; Fri, 12 Dec 2003 10:19:56 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EBA0BA0E29 for ; Fri, 12 Dec 2003 10:19:46 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id EC00714303; Fri, 12 Dec 2003 10:18:21 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from greenbytes.de (unknown [217.5.201.10]) by dr-nick.w3.org (Postfix) with ESMTP id DAF03142FD for ; Fri, 12 Dec 2003 10:18:20 -0500 (EST) Received: from 192.168.1.26 ([192.168.1.26]) (authenticated user se@greenbytes.de) by greenbytes.de (greenbytes.de [217.5.201.11]) (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v6.8.5.R) with ESMTP id 53-md50000000079.tmp for ; Fri, 12 Dec 2003 16:17:38 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3025829C-2CB6-11D8-BA59-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Stefan Eissing Date: Fri, 12 Dec 2003 16:16:41 +0100 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.606) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Fri, 12 Dec 2003 16:17:38 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: Review of draft-ietf-webdav-quota-02.txt X-Archived-At: http://www.w3.org/mid/3025829C-2CB6-11D8-BA59-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8215 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: <20031212151956.82620A0977@frink.w3.org> Resent-Date: Fri, 12 Dec 2003 10:19:56 -0500 (EST) Content-Transfer-Encoding: 7bit Finally someone is paying attention! Am 12.12.2003 um 16:05 schrieb Geoffrey M Clemm: > > I assume in Corollary2, by "all resources", > you mean "all non-collection resources" ? Yes, of course, as usual, you are right. Newly created collections also belong to the same quota space as their parents. BR, Stefan > Cheers, > Geoff > > Stefan wrote on 12/12/2003 04:32:10 AM: > >> >> Chris, >> >> I agree to your analysis that the current definitions lead to >> confusion. The way out >> is to simplify the underlying model. >> >> Definition: a "quota space" is a storage area on the server where >> allocation can >> be restricted. All collections on a server either belong to a >> particular quota space >> or to no quota space at all (in which case storage allocation, if >> possible, in such >> collections cannot be controlled by quotas). >> >> Corollary1: all collections of a particular quota space report the >> same >> values for >> their DAV:quota* properties. >> >> Corollary2: all resources belong to the same quota space as their >> parent collection(s). >> >> Corollary3: all collections which may contain bindings to the same >> resource do >> belong to the same quota space. Collections in different quota spaces >> cannot >> have bindings to the same resource. >> >> With this model, /A and /A/UploadDirectory will either have the same >> DAV:quota* >> values or totally unrelated ones, depending if the two collections >> belong to the >> same or to different quota spaces. Thus the problem of "it does not >> sum >> up" is >> avoided. Also, server side implementation can be much simpler, as the >> hiearchies >> (e.g. bindings) of collections and resources do *not* influence the >> quota values. >> >> //Stefan >> >> Am 11.12.2003 um 19:30 schrieb Chris Sharp: >> >>> Just getting around to understanding this thread. I totally agree, >>> the > >>> quota-assigned-bytes seems unnecessary and confusing. >>> >>> On another note, I think there needs to be some clarification the way >>> quota-available-bytes and quota-used-bytes work. >>> >>> Example: >>> >>> Initial State of Repository with a Quota management system: >>> >>> >>> DAV:quota-available-bytes DAV:quota-used-bytes >>> /A 95MB >>> 5MG <--- used for somewhere for >>> something >>> /A/UploadDirectory 10MB >>> 0 >>> >>> A new 5MB resource is created at /A/UploadDirectory/new5MBFile: >>> >>> DAV:quota-available-bytes DAV:quota-used-bytes >>> /A 90MB >>> 10MB >>> /A/UploadDirectory 5MB >>> 5MB >>> >>> Pretty clear, however, if there is no quota differentiation on >>> /A/UploadDirectory, the current draft of the RFC makes >>> quota-used-bytes, which is really inherited from its parent, >>> incongruent with quota-available-bytes on the same resource. A >>> diagram > >>> is in order: >>> >>> Initial State of Repository with a Quota management system: >>> (quota system on /A only) >>> >>> DAV:quota-available-bytes DAV:quota-used-bytes >>> /A 95MB >>> 5MG >>> >>> A new 5MB resource is created at /A/UploadDirectory/new5MBFile: >>> >>> DAV:quota-available-bytes DAV:quota-used-bytes >>> /A 90MB >>> 10MB >>> /A/UploadDirectory 90MB >>> 5MB >>> >>> The sum of quota-available-bytes and quota-used-bytes is 95 on >>> /A/UploadDirectory and not 100! Logically, if you get a request for >>> quota-available-bytes on a resource /A/UploadDirectory and the quota >>> is actually enforced on the parent, that you would essentially walk >>> up > >>> the tree until you found an appropriate "mount point" based quota >>> requirement. If this is true, the quota-used-bytes should do the same >>> thing. Meaning, quota-used-bytes on /A/UploadDirectory would be the >>> same as quota-used-bytes /A if /A/UploadDirectory did not contain a >>> more specific quota rule. >>> >>> This is also an efficiency win for implementors. If an implementation >>> has to support quota-used-bytes on an arbitrary URL, it is >>> impractical > >>> to think that quota-used-bytes could be incrementally adjusted and >>> would necessarily need to be calculated on-the-fly, which does not >>> scale well for most implementations. >>> >>> How NFSv4 handles this situation? >>> >>> >>> Also, under the "Notes" section, "What clients should expect" seems >>> to > >>> have a sentence which is not grammatically correct. >>> "This allows the space used by /~milele/public/ to be as >>> large as the quota on /~milele/ allows (depending on the other >>> contents of /~milele/) even if the quota on /~milele/ is >>> changed." >>> >>> Regards, >>> >>> Chris. >>> On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote: >>> >>>> >>>> Brian, >>>> >>>> I put my mind into blank slate mode and read the draft 2 for the >>>> first time. >>>> >>>> I think it is a big improvment from where we started from. One item >>>> I > >>>> found >>>> confusing though and that is the example for >>>> DAV:quota-assigned-bytes >>>> (and the mental model behind the example). >>>> >>>> The draft seems to say that /A and /A/B have separate >>>> DAV:quota-assigned-bytes >>>> properties, however they are in the same "set of collections" when >>>> the value >>>> of DAV:quota-available-bytes/DAV:quota-used-bytes is computed. >>>> >>>> (See definition of "set" in the explanation to DAV:quota-used-bytes >>>> - > >>>> seems to >>>> be a copy from the NFS spec.) >>>> >>>> In NFS-Quota, the model seems to be simple: each quota applies to a >>>> set >>>> of collections/files and each member of this set would report the > same >>>> quota properties. >>>> >>>> In WebDAV-quota (draft-2): there is a separate quota for each >>>> collection >>>> (e.g. the assigned-bytes), but available-/used-bytes are the same >>>> for >>>> resources in the same set. >>>> >>>> Two Problems come to my mind now: >>>> 1) If a collection of the "set" has the DAV:quota-assigned-bytes not >>>> explicitly set, what value would it report? Say for /A/C, /A/B/D > and >>>> /E (all in the same set)? >>>> >>>> 2) If a client wants to increase DAV:quota-available-bytes in a >>>> certain >>>> collection, it has to increase the DAV:quota-assigned-bytes. But >>>> in >>>> your example: increasing assigned-bytes on /A/B will not have any >>>> effect on the DAV:quota-available-bytes. What is a generic client >>>> supposed >>>> to do then? >>>> >>>> Best Regards, Stefan >>>> >>>> Am 13.11.2003 um 22:06 schrieb Brian Korver: >>>> >>>>> >>>>> On Thursday, November 13, 2003, at 01:14 PM, Julian Reschke wrote: >>>>>> Brian, >>>>>> >>>>>> when I re-raised these issues, I *did* read the current draft. So >>>>>> I > >>>>>> think it's up to you to go back to the mailing list discussion and >>>>>> explain why the concerns raised by Stefan and myself aren't valid. >>>>>> >>>>>> Julian >>>>> >>>>> Julian, >>>>> >>>>> I'm planning to do so in today's meeting, but to restate for the >>>>> mailing list, >>>>> Stefan pointed out that if we used quota-limit, then quota-limit >>>>> would not be >>>>> a fixed value (which is the reason we defined things in terms of >>>>> quota-limit >>>>> to begin with). Thus, instead of quota-limit, the new draft uses >>>>> NFS's >>>>> quota-available. This has the semantics that it isn't fixed. >>>>> Problem solved. >>>>> Note, quota-available is consistent with the rest of the the quota >>>>> definitions >>>>> we pulled from NFS, so it's conceptually attractive too. >>>>> >>>>> I still don't know what you find confusing, so I can't comment on >>>>> that yet. >>>>> >>>>> -brian >>>>> briank@xythos.com >>>> >> From w3c-dist-auth-request@w3.org Fri Dec 12 15:24:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24517 for ; Fri, 12 Dec 2003 15:24:48 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 42D8AA0881; Fri, 12 Dec 2003 15:24:48 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E0CECA0881 for ; Fri, 12 Dec 2003 15:24:34 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 614E41359F; Fri, 12 Dec 2003 15:24:34 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id EB72E133AD for ; Fri, 12 Dec 2003 15:24:33 -0500 (EST) Received: from [192.168.1.151] ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Dec 2003 12:24:28 -0800 In-Reply-To: <0F49B0A0-2C86-11D8-BA59-00039384827E@greenbytes.de> References: <35F86684-161D-11D8-B03D-000393751598@xythos.com> <1693B4A4-168D-11D8-A8E2-00039384827E@greenbytes.de> <189E09D8-2C08-11D8-9607-003065B4EF3A@apple.com> <0F49B0A0-2C86-11D8-BA59-00039384827E@greenbytes.de> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2F629A30-2CE1-11D8-8BCD-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: WebDAV From: Brian Korver Date: Fri, 12 Dec 2003 12:24:28 -0800 To: Stefan Eissing X-Mailer: Apple Mail (2.606) X-OriginalArrivalTime: 12 Dec 2003 20:24:28.0710 (UTC) FILETIME=[F1727C60:01C3C0ED] Subject: Re: Review of draft-ietf-webdav-quota-02.txt X-Archived-At: http://www.w3.org/mid/2F629A30-2CE1-11D8-8BCD-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8216 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: <20031212202448.42D8AA0881@frink.w3.org> Resent-Date: Fri, 12 Dec 2003 15:24:48 -0500 (EST) Content-Transfer-Encoding: 7bit On Dec 12, 2003, at 1:32 AM, Stefan Eissing wrote: > Chris, > > I agree to your analysis that the current definitions lead to > confusion. The way out > is to simplify the underlying model. > > Definition: a "quota space" is a storage area on the server where > allocation can > be restricted. All collections on a server either belong to a > particular quota space > or to no quota space at all (in which case storage allocation, if > possible, in such > collections cannot be controlled by quotas). Finally, the definition of "quota space". > > Corollary1: all collections of a particular quota space report the > same values for > their DAV:quota* properties. > > Corollary2: all resources belong to the same quota space as their > parent collection(s). That was the implicit model of the original spec (when quotas were on directories only). I think this is a good simplification. > > Corollary3: all collections which may contain bindings to the same > resource do > belong to the same quota space. Collections in different quota spaces > cannot > have bindings to the same resource. I have several problems with this. First, I believe it implicitly forbids soft-link type binding models. Did you mean here only the binding model spelled out in the current binding draft? Second, it forbids quota models that some vendors support (and have customers that find useful). > > With this model, /A and /A/UploadDirectory will either have the same > DAV:quota* > values or totally unrelated ones, depending if the two collections > belong to the > same or to different quota spaces. Thus the problem of "it does not > sum up" is > avoided. Also, server side implementation can be much simpler, as the > hiearchies > (e.g. bindings) of collections and resources do *not* influence the > quota values. > > //Stefan -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Dec 12 17:56:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00956 for ; Fri, 12 Dec 2003 17:56:41 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 5C6A5A0838; Fri, 12 Dec 2003 17:56:44 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 387E5A0838 for ; Fri, 12 Dec 2003 17:56:33 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id E249A1350B; Fri, 12 Dec 2003 17:56:32 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by dr-nick.w3.org (Postfix) with ESMTP id 9D3111338D for ; Fri, 12 Dec 2003 17:56:32 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hBCMuWg6736288 for ; Fri, 12 Dec 2003 17:56:32 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBCMuVlh032974 for ; Fri, 12 Dec 2003 17:56:31 -0500 In-Reply-To: <2F629A30-2CE1-11D8-8BCD-000A95AACED2@xythos.com> To: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 12 Dec 2003 17:56:32 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 12/12/2003 17:57:27, Serialize complete at 12/12/2003 17:57:27 Content-Type: text/plain; charset="US-ASCII" Subject: Re: Review of draft-ietf-webdav-quota-02.txt X-Archived-At: http://www.w3.org/mid/OF62C4DEFD.38CC92D1-ON85256DFA.007D22EA-85256DFA.007E0681@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8217 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: <20031212225644.5C6A5A0838@frink.w3.org> Resent-Date: Fri, 12 Dec 2003 17:56:44 -0500 (EST) I believe it is extremely probable that Stefan was using the word "binding" as it is defined by the WebDAV binding protocol. So this definition does not implicitly forbid (or say anything about) soft-links (which are redirect references, not bindings). WRT to modeling all possible quota models, one always has to balance the simplicity of the model with the flexibility of the model (in the case of the ACL spec, we ended up being directed to decrease the flexibility in order to increase the simplicity). How widespread are the examples of repositories that let you bind (in the binding protocol sense of the term "bind") a resource into two collections that are in different quota spaces? Cheers, Geoff Brian wrote on 12/12/2003 03:24:28 PM: > > On Dec 12, 2003, at 1:32 AM, Stefan Eissing wrote: > > Chris, > > > > I agree to your analysis that the current definitions lead to > > confusion. The way out > > is to simplify the underlying model. > > > > Definition: a "quota space" is a storage area on the server where > > allocation can > > be restricted. All collections on a server either belong to a > > particular quota space > > or to no quota space at all (in which case storage allocation, if > > possible, in such > > collections cannot be controlled by quotas). > > Finally, the definition of "quota space". > > > > > > Corollary1: all collections of a particular quota space report the > > same values for > > their DAV:quota* properties. > > > > Corollary2: all resources belong to the same quota space as their > > parent collection(s). > > That was the implicit model of the original spec (when quotas were on > directories only). I think this is a good simplification. > > > > > > Corollary3: all collections which may contain bindings to the same > > resource do > > belong to the same quota space. Collections in different quota spaces > > cannot > > have bindings to the same resource. > > I have several problems with this. First, I believe it implicitly > forbids > soft-link type binding models. Did you mean here only the binding model > spelled out in the current binding draft? Second, it forbids quota > models > that some vendors support (and have customers that find useful). > > > > > > With this model, /A and /A/UploadDirectory will either have the same > > DAV:quota* > > values or totally unrelated ones, depending if the two collections > > belong to the > > same or to different quota spaces. Thus the problem of "it does not > > sum up" is > > avoided. Also, server side implementation can be much simpler, as the > > hiearchies > > (e.g. bindings) of collections and resources do *not* influence the > > quota values. > > > > //Stefan > > -brian > briank@xythos.com > From w3c-dist-auth-request@w3.org Sat Dec 13 08:12:14 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03396 for ; Sat, 13 Dec 2003 08:12:14 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id B4CE0A057B; Sat, 13 Dec 2003 08:12:13 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 955D7A057B for ; Sat, 13 Dec 2003 08:12:05 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 32192136CD; Sat, 13 Dec 2003 08:12:05 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 900FB13530 for ; Sat, 13 Dec 2003 08:12:04 -0500 (EST) Received: (qmail 17579 invoked by uid 65534); 13 Dec 2003 13:12:00 -0000 Received: from p3EE2470C.dip.t-dialin.net (EHLO gmx.de) (62.226.71.12) by mail.gmx.net (mp025) with SMTP; 13 Dec 2003 14:12:00 +0100 X-Authenticated: #1915285 Message-ID: <3FDB0FEC.4000402@gmx.de> Date: Sat, 13 Dec 2003 14:11:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV Cc: Geoffrey M Clemm References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Review of draft-ietf-webdav-quota-02.txt X-Archived-At: http://www.w3.org/mid/3FDB0FEC.4000402@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8218 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: <20031213131213.B4CE0A057B@frink.w3.org> Resent-Date: Sat, 13 Dec 2003 08:12:13 -0500 (EST) Content-Transfer-Encoding: 7bit Just to restate, here are other issues that make the spec more complicated than it needs to be and/or incomplete: - The spec tries to make handling of quotas simple by just reporting a single quota, selected by the server (just like in NFS). This is fine as long as the information is only used for display in the UI or for diagnostics. However, it fails completely if you want to make the quota authorable, because in this case you have no control whatsoever about *what* quota you're trying to change. I think this is the cause for most of the confusion about the "third" property. The simplest way to fix this is to remove support for authoring quota values from the spec. - Disk limits are not quotas. Treating disk limits the same way causes funny effects. In addition, method failures due to physical storage limits should be treated differently (for instance, when mapping to a Unix FS like in the MacOS X driver, you may want to map to two separate error codes). IMHO the spec should clearly state that disk limits are *not* quotas. If it adds live properties and precondition/postcondition names to marshall to disk limit information *separately*, that'll be fine as well. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Dec 13 14:27:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10871 for ; Sat, 13 Dec 2003 14:27:40 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id B9B8BA0568; Sat, 13 Dec 2003 14:27:40 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 91E50A0A7A for ; Sat, 13 Dec 2003 14:27:32 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 13B15131D6; Sat, 13 Dec 2003 14:27:32 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 80B56131DA for ; Sat, 13 Dec 2003 14:27:31 -0500 (EST) Received: (qmail 4262 invoked by uid 65534); 13 Dec 2003 19:27:15 -0000 Received: from p3EE24727.dip.t-dialin.net (EHLO gmx.de) (62.226.71.39) by mail.gmx.net (mp011) with SMTP; 13 Dec 2003 20:27:15 +0100 X-Authenticated: #1915285 Message-ID: <3FDB67F8.2020306@gmx.de> Date: Sat, 13 Dec 2003 20:26:48 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: WebDAV Ordered Collections Protocol published X-Archived-At: http://www.w3.org/mid/3FDB67F8.2020306@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8219 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: <20031213192740.B9B8BA0568@frink.w3.org> Resent-Date: Sat, 13 Dec 2003 14:27:40 -0500 (EST) Content-Transfer-Encoding: 7bit Hi all, the WebDAV Ordered Collections Protocol has finally been published as RFC3648 (). Note that it took us nearly two years to come up with the next RFC (after RFC3253), so let's try to make sure that we're getting out RFC2518bis, the BIND spec and the REDIRECT spec (all of which are on the working group's agenda) in a shorter amount of time (the ACL spec is already in the publication queue!). Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 15 15:10:23 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24419 for ; Mon, 15 Dec 2003 15:10:23 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 20D35A051C; Mon, 15 Dec 2003 15:10:24 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B67CEA051C for ; Mon, 15 Dec 2003 15:10:15 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 560AD1356C; Mon, 15 Dec 2003 15:10:15 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id C85D913340 for ; Mon, 15 Dec 2003 15:10:14 -0500 (EST) Received: (qmail 29513 invoked by uid 65534); 15 Dec 2003 20:10:11 -0000 Received: from p3EE24708.dip.t-dialin.net (EHLO gmx.de) (62.226.71.8) by mail.gmx.net (mp007) with SMTP; 15 Dec 2003 21:10:11 +0100 X-Authenticated: #1915285 Message-ID: <3FDE150D.7060701@gmx.de> Date: Mon, 15 Dec 2003 21:09:49 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: new BIND draft submitted X-Archived-At: http://www.w3.org/mid/3FDE150D.7060701@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8220 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: <20031215201024.20D35A051C@frink.w3.org> Resent-Date: Mon, 15 Dec 2003 15:10:24 -0500 (EST) Content-Transfer-Encoding: 7bit A new version of the BIND draft is available at: The issues list and the new current edits are here: Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 15 15:29:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26092 for ; Mon, 15 Dec 2003 15:29:40 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 1F875A071C; Mon, 15 Dec 2003 15:29:41 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 4D8D7A071C for ; Mon, 15 Dec 2003 15:29:32 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id B99761391D; Mon, 15 Dec 2003 15:29:31 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (Postfix) with ESMTP id E156A13692 for ; Mon, 15 Dec 2003 15:29:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26068; Mon, 15 Dec 2003 15:29:29 -0500 (EST) Message-Id: <200312152029.PAA26068@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 15 Dec 2003 15:29:29 -0500 Subject: I-D ACTION:draft-ietf-webdav-bind-03.txt X-Archived-At: http://www.w3.org/mid/200312152029.PAA26068@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8221 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: <20031215202941.1F875A071C@frink.w3.org> Resent-Date: Mon, 15 Dec 2003 15:29:41 -0500 (EST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) Author(s) : G. Clemm, J. Crawford Filename : draft-ietf-webdav-bind-03.txt Pages : 32 Date : 2003-12-15 This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-bind-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-bind-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-15150406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-bind-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-bind-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-15150406.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Dec 18 14:08:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09252 for ; Thu, 18 Dec 2003 14:08:40 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id B5FE4A0953; Thu, 18 Dec 2003 14:08:40 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id D4A60A0D8C for ; Thu, 18 Dec 2003 14:06:57 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id C6F021436A; Thu, 18 Dec 2003 14:01:31 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by dr-nick.w3.org (Postfix) with ESMTP id 84FED1457C for ; Thu, 18 Dec 2003 14:01:31 -0500 (EST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by agminet01.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hBIJ1VZv019429 for ; Thu, 18 Dec 2003 11:01:31 -0800 Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id hBIJ1Uk17371 for ; Thu, 18 Dec 2003 12:01:30 -0700 (MST) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id hBIJ1Ok17083 for ; Thu, 18 Dec 2003 12:01:29 -0700 (MST) Message-ID: <0c9701c3c599$2b1c77e0$c5b42382@us.oracle.com> From: "Stanley Guan" To: Date: Thu, 18 Dec 2003 11:00:09 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C94_01C3C556.1A411CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: Depth header in a lock refreshing method X-Archived-At: http://www.w3.org/mid/0c9701c3c599$2b1c77e0$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8222 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: <20031218190840.B5FE4A0953@frink.w3.org> Resent-Date: Thu, 18 Dec 2003 14:08:40 -0500 (EST) This is a multi-part message in MIME format. ------=_NextPart_000_0C94_01C3C556.1A411CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Under the topic of "Refreshing Locks", it hints that Client may include a Timeout header. But, Depth header has not being mentioned. Under the topic of "Depth and Locking", it discussed what will happen if "Depth" header is specified for=20 creating a new lock. But, nothing was mentioned on=20 what's its implication on a lock refreshing command. Should "bis" document clarify this? Thx, -Stanley ------=_NextPart_000_0C94_01C3C556.1A411CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Under the topic of "Refreshing Locks", = it hints=20 that
Client may include a Timeout header. = But, Depth=20 header
has not being mentioned.
 
Under the topic of "Depth and Locking", = it=20 discussed
what will happen if "Depth" header is = specified for=20
creating a new lock.  But, nothing = was=20 mentioned on
what's its implication on a lock = refreshing=20 command.
 
Should "bis" document clarify = this?
 
Thx,
 
-Stanley
------=_NextPart_000_0C94_01C3C556.1A411CC0--