From w3c-dist-auth-request@w3.org Sat Nov 1 11:44: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 LAA10396 for ; Sat, 1 Nov 2003 11:44:22 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id B0260A0522; Sat, 1 Nov 2003 11:44:32 -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 9AE0FA0522 for ; Sat, 1 Nov 2003 11:44:29 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 6BF3013C01; Sat, 1 Nov 2003 11:44:29 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail6.atl.registeredsite.com (mail6.atl.registeredsite.com [64.224.219.80]) by dr-nick.w3.org (Postfix) with ESMTP id 4E8F813BC0 for ; Sat, 1 Nov 2003 11:44:29 -0500 (EST) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail6.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id hA1GiRbn008762; Sat, 1 Nov 2003 11:44:27 -0500 Received: from compagno (67-42-105-77.tukw.qwest.net [67.42.105.77]) by infonuovo.com (8.8.7/8.8.5) with SMTP id IAA16463; Sat, 1 Nov 2003 08:44:26 -0800 (PST) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , Date: Sat, 1 Nov 2003 08:44:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F9ECF13.3@gmx.de> Subject: RE: rfc2518-bis-05 issues (part 1) - DAV: Scheme X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAAEFHDEAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8075 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: <20031101164432.B0260A0522@frink.w3.org> Resent-Date: Sat, 1 Nov 2003 11:44:32 -0500 (EST) Content-Transfer-Encoding: quoted-printable I support Julian's observation about the paragraph on use of the "DAV:"=20 URI scheme. The earlier statement snarls up scheme names and Namespace URIs too much. I proposed the following amendment, although I am not entirely happy with it. It is not clear to me what this provides. It is informative. Is there anything more to say about this. I.e., are we promising not to do this again, not to expand it beyond the current approach to DAV interoperability preservation, or what? =20 Finally, section 19's discussion about what IANA must do (!?) should be repaired to identify the two *URI*schemes* that must be registered, the = one for "DAV:" URIs and the one for "opaquelocktoken:" URIs. IANA does not register namespaces, and that language should be removed from section = 19. Furthermore, it seems inappropriate to embed a requirement for some third-party in = the body of the DAV specification. It would seem that the DAV WG must take responsibility for ensuring that there is appropriate reservation of the DAV and opaquelocktoken schemes, and section 19 should assert that such reservation has been accomplished (and a reference would be useful). AMENDED CHANGE PROPOSAL -05 section 4.4, last paragraph:=20 Note that =93DAV:=94 is a scheme name defined solely to provide a namespace for WebDAV XML elements and property names. This practice is discouraged in part because registration of new scheme names is difficult. "DAV:" was defined as the WebDAV namespace before standard best practices emerged, and this namespace is kept and still used because of significant existing deployments, but this should not be emulated. rewrite as: Note that both defining a new URI scheme just for the purpose of=20 identifying protocol elements and using just the scheme name as a=20 namespace name are inconsistent with current best practice. Use of the "DAV:" and "opaquelocktoken:" URIs is preserved for=20 compatibility with existing deployments. There will be no further introduction of new URI schemes as part of DAV.=20 -- Dennis -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke Sent: Tuesday, October 28, 2003 12:18 To: w3c-dist-auth@w3.org Subject: rfc2518-bis-05 issues (part 1) Hi. Below is a list of issues I raised against drafts 03 and 04 which IMHO=20 have not been adequately addressed in the latest draft (see [1] for the=20 original message). 03-C03 4.4: =93Note that the use of a new top-level URI identifier as a = namespace=20 is considered by many to be a bad thing=85=94 Rewrite as: =93Note that both defining a new URI scheme just for the purpose of=20 identifying protocol elements, and using just the scheme name as a=20 namespace name is to be considered a bad practice, and should not be=20 copied=94. [draft 05 now says...] Note that =93DAV:=94 is a scheme name defined solely to provide a namespace for WebDAV XML elements and property names. This practice is discouraged in part because registration of new scheme names is difficult. "DAV:" was defined as the WebDAV namespace before standard best practices emerged, and this namespace is kept and still used because of significant existing deployments, but this should not be emulated. [ ... ] [1] = --=20 bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Nov 1 14:09:13 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 OAA12594 for ; Sat, 1 Nov 2003 14:09:13 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 26272A05C9; Sat, 1 Nov 2003 14:09: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 2F1D7A05C9 for ; Sat, 1 Nov 2003 14:09:15 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 420FF14AC8; Sat, 1 Nov 2003 14:06:03 -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 86A5014AC2 for ; Sat, 1 Nov 2003 14:06:02 -0500 (EST) Received: (qmail 6088 invoked by uid 65534); 1 Nov 2003 19:05:44 -0000 Received: from p3EE24725.dip.t-dialin.net (EHLO gmx.de) (62.226.71.37) by mail.gmx.net (mp016) with SMTP; 01 Nov 2003 20:05:44 +0100 X-Authenticated: #1915285 Message-ID: <3FA403E3.2010508@gmx.de> Date: Sat, 01 Nov 2003 20:05:07 +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: dennis.hamilton@acm.org Cc: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: rfc2518bis issue 03-C03, was: rfc2518-bis-05 issues (part 1) - DAV: Scheme X-Archived-At: http://www.w3.org/mid/3FA403E3.2010508@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8076 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: <20031101190924.26272A05C9@frink.w3.org> Resent-Date: Sat, 1 Nov 2003 14:09:24 -0500 (EST) Content-Transfer-Encoding: 8bit Dennis E. Hamilton wrote: > I support Julian's observation about the paragraph on use of the "DAV:" > URI scheme. The earlier statement snarls up scheme names and Namespace > URIs too much. > > I proposed the following amendment, although I am not entirely happy > with it. It is not clear to me what this provides. It is informative. > Is there anything more to say about this. I.e., are we promising not > to do this again, not to expand it beyond the current approach to DAV > interoperability preservation, or what? Yes. This, and: "we are aware of the fact that this was a mistake". BTW: we want to do this because it seems that many abuses of ad-hoc URI scheme usage was indeed inspired by WebDAV. > Finally, section 19's discussion about what IANA must do (!?) should be > repaired to identify the two *URI*schemes* that must be registered, the one > for "DAV:" URIs and the one for "opaquelocktoken:" URIs. IANA does not > register namespaces, and that language should be removed from section 19. I agree with the statement that "DAV:" and "opaquelocktoken:" are URI schemes, not URI namespaces. I'm *not* sure that I agree with the rest. "Instructions to Request for Comments (RFC) Authors" says in : Any RFC that defines a new "namespace" of assigned numbers should include an IANA Considerations section specifying how that space should be administered. See "Guidelines for Writing an IANA Considerations Section in RFCs" [IANA98] for a detailed discussion of the issues to be considered and the contents of this section. RFC2518 does define several namespaces: the space of WebDAV property names, the space of WebDAV protocol element names, and so on. I think it's correct to mention that in the IANA Considerations section. > Furthermore, > it seems inappropriate to embed a requirement for some third-party in the > body of the DAV specification. It would seem that the DAV WG must take > responsibility for ensuring that there is appropriate reservation of the > DAV and opaquelocktoken schemes, and section 19 should assert that such > reservation has been accomplished (and a reference would be useful). In general, I disagree. Publishing an RFC is actually the correct way to register a URI scheme. As RFC2518bis is supposed to "obosolete" RFC2518, it should contain the same information. Quote from : Obsoletes Specifies an earlier document that is replaced by the new document. The new document can be used alone as a replacement for the obsoleted document. The new document may contain revised information or all of the same information plus some new information, however extensive or brief that new information may be. > AMENDED CHANGE PROPOSAL > > -05 section 4.4, last paragraph: > > Note that “DAV:” is a scheme name defined solely to provide a > namespace for WebDAV XML elements and property names. This practice > is discouraged in part because registration of new scheme names is > difficult. "DAV:" was defined as the WebDAV namespace before > standard best practices emerged, and this namespace is kept and > still used because of significant existing deployments, but this > should not be emulated. > > rewrite as: > > Note that both defining a new URI scheme just for the purpose of > identifying protocol elements and using just the scheme name as a > namespace name are inconsistent with current best practice. Use > of the "DAV:" and "opaquelocktoken:" URIs is preserved for > compatibility with existing deployments. There will be no further > introduction of new URI schemes as part of DAV. I like that except for "...are inconsistent with current best practice". The usage of a URI scheme name as a URI indeed does not comply to the URI syntax (according RFC2396, there is no such thing as a URI with an empty scheme-dependant part). If we want to get really verbose we can also state that RFC2396bis () is going to lift this restriction in order to make usage of URIs auch as "dav:" or "about:" legal (). But that's a future IETF document we probably don't want to wait for. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Nov 2 16:33:05 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 QAA26141 for ; Sun, 2 Nov 2003 16:33:05 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id C6611A05AE; Sun, 2 Nov 2003 16:33: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 14E0AA05FA for ; Sun, 2 Nov 2003 16:33:13 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id EE31D13463; Sun, 2 Nov 2003 16:33:12 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail7.atl.registeredsite.com (mail7.atl.registeredsite.com [64.224.219.81]) by dr-nick.w3.org (Postfix) with ESMTP id CE2501340F for ; Sun, 2 Nov 2003 16:33:12 -0500 (EST) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail7.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id hA2LX4md013244; Sun, 2 Nov 2003 16:33:04 -0500 Received: from compagno (67-42-105-77.tukw.qwest.net [67.42.105.77]) by infonuovo.com (8.8.7/8.8.5) with SMTP id NAA22294; Sun, 2 Nov 2003 13:33:03 -0800 (PST) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" Cc: Date: Sun, 2 Nov 2003 13:32:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <3FA403E3.2010508@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: rfc2518bis issue 03-C03 - DAV: Scheme X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAEEFPDEAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8077 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: <20031102213315.C6611A05AE@frink.w3.org> Resent-Date: Sun, 2 Nov 2003 16:33:15 -0500 (EST) Content-Transfer-Encoding: quoted-printable Oh my. Let me make sure I understand the key aspects of the situation here: 1. The DAV and opaquelocktoken URI scheme *names* are registered with = IANA (with the names as their descriptions and citation of rfc2518 as = the source),=20 . =20 Is there actually a defined scheme, or has there been merely = registration of the scheme name? 2. The form "DAV:" is not an acceptable form for a URI according to the = URI format specifications, although the editors of the URI specification = revision have accepted the request to allow that form. 3. The XML Namespace specifications requires a URI as the value for the = xmlns attribute. At the moment, it would be permissible for an XML = processor to reject DAV XML because of a malformed xmlns URI, though I = doubt that has come up in practice, since a URI is basically opaque in = the context of XML Namespace. This is an interesting nit. I gather it is not new news. =20 What is the appropriate action? -- Dennis PS: I don't think the passage in = is about XML Namespaces as = such. If the DAV WG thinks that the DAV namespace is an assigned-number = space -- that is, the equivalent of a protocol tag set, then the issue = should be addressed (even by an explicit statement that it is not being = addressed or the requirement is not applicable, etc.). I don't believe = that registering a scheme name is responsive to this requirement, = however. My sense is that the greatest contribution to management of = the protocol elements identified using the DAV namespace would be making = an explicit, clear statement about what the extension mechanism is and = who is the authority for additions to the DAV namespace, since it is = allowed to be extended over time. The question then becomes, what is = invariant over time? And once an element is introduced, what is then = invariant over time? -- dh -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, November 01, 2003 11:05 To: dennis.hamilton@acm.org Cc: w3c-dist-auth@w3.org Subject: rfc2518bis issue 03-C03, was: rfc2518-bis-05 issues (part 1) - DAV: Scheme Dennis E. Hamilton wrote: > I support Julian's observation about the paragraph on use of the = "DAV:"=20 > URI scheme. The earlier statement snarls up scheme names and = Namespace > URIs too much. >=20 > I proposed the following amendment, although I am not entirely happy > with it. It is not clear to me what this provides. It is informative. > Is there anything more to say about this. I.e., are we promising not > to do this again, not to expand it beyond the current approach to DAV > interoperability preservation, or what? =20 Yes. This, and: "we are aware of the fact that this was a mistake". BTW: we want to do this because it seems that many abuses of ad-hoc URI=20 scheme usage was indeed inspired by WebDAV. > Finally, section 19's discussion about what IANA must do (!?) should = be > repaired to identify the two *URI*schemes* that must be registered, = the one > for "DAV:" URIs and the one for "opaquelocktoken:" URIs. IANA does = not > register namespaces, and that language should be removed from section = 19. I agree with the statement that "DAV:" and "opaquelocktoken:" are URI=20 schemes, not URI namespaces. I'm *not* sure that I agree with the rest.=20 "Instructions to Request for Comments (RFC) Authors" says in=20 : Any RFC that defines a new "namespace" of assigned numbers should include an IANA Considerations section specifying how that space should be administered. See "Guidelines for Writing an IANA Considerations Section in RFCs" [IANA98] for a detailed = discussion of the issues to be considered and the contents of this section. RFC2518 does define several namespaces: the space of WebDAV property=20 names, the space of WebDAV protocol element names, and so on. I think=20 it's correct to mention that in the IANA Considerations section. [ ... ] >=20 > Note that both defining a new URI scheme just for the purpose of=20 > identifying protocol elements and using just the scheme name as a=20 > namespace name are inconsistent with current best practice. Use > of the "DAV:" and "opaquelocktoken:" URIs is preserved for=20 > compatibility with existing deployments. There will be no further > introduction of new URI schemes as part of DAV.=20 I like that except for "...are inconsistent with current best practice". = The usage of a URI scheme name as a URI indeed does not comply to the=20 URI syntax (according RFC2396, there is no such thing as a URI with an=20 empty scheme-dependant part). If we want to get really verbose we can also state that RFC2396bis=20 () is going to lift this=20 restriction in order to make usage of URIs auch as "dav:" or "about:"=20 legal=20 ().=20 But that's a future IETF document we probably don't want to wait for. Julian --=20 bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Nov 2 16:59:10 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 QAA26689 for ; Sun, 2 Nov 2003 16:59:09 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 9A0F7A0590; Sun, 2 Nov 2003 16:58:18 -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 C3F1AA0590 for ; Sun, 2 Nov 2003 16:58:15 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 7CA6013372; Sun, 2 Nov 2003 16:58:15 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 1E17613364 for ; Sun, 2 Nov 2003 16:58:15 -0500 (EST) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AGQEg-0006sa-00; Sun, 02 Nov 2003 21:58:14 +0000 Received: from [198.144.203.248] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AGQEf-0006sP-00; Sun, 02 Nov 2003 21:58:13 +0000 From: "Lisa Dusseault" To: , "'Julian Reschke'" Cc: Date: Sun, 2 Nov 2003 13:58:24 -0800 Message-ID: <094d01c3a18c$7075d650$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: dennis.hamilton@acm.org, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: rfc2518bis issue 03-C03 - DAV: Scheme X-Archived-At: http://www.w3.org/mid/094d01c3a18c$7075d650$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8078 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: <20031102215818.9A0F7A0590@frink.w3.org> Resent-Date: Sun, 2 Nov 2003 16:58:18 -0500 (EST) Content-Transfer-Encoding: 7bit > 2. The form "DAV:" is not an acceptable form for a URI > according to the URI format specifications, although the > editors of the URI specification revision have accepted the > request to allow that form. I would be surprised to hear this -- I'd like to see what makes it unacceptable. I agree it's not well specified, so to believe it's acceptable means you have to assume that the definition for the DAV: scheme allows a null URI after the scheme part. But why would you assume that would be unacceptable? Most URI schemes require something after the scheme name, but clearly DAV: doesn't. > explicit, clear statement about what the extension mechanism > is and who is the authority for additions to the DAV > namespace, since it is allowed to be extended over time. The > question then becomes, what is invariant over time? And once > an element is introduced, what is then invariant over time? -- dh That's a good point. It *is* possible to create new URIs under the DAV: scheme name, now that it's defined. E.g. we could have defined "DAV:deltav", "DAV:bindings", etc as namespaces for various extension elements. There isn't anything written down, however, about how to construct valid URIs using the DAV: scheme. lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Saturday, November 01, 2003 11:05 > To: dennis.hamilton@acm.org > Cc: w3c-dist-auth@w3.org > Subject: rfc2518bis issue 03-C03, was: rfc2518-bis-05 issues > (part 1) - > DAV: Scheme > > > Dennis E. Hamilton wrote: > > > I support Julian's observation about the paragraph on use of the > > "DAV:" > > URI scheme. The earlier statement snarls up scheme names > and Namespace > > URIs too much. > > > > I proposed the following amendment, although I am not > entirely happy > > with it. It is not clear to me what this provides. It is > informative. > > Is there anything more to say about this. I.e., are we > promising not > > to do this again, not to expand it beyond the current > approach to DAV > > interoperability preservation, or what? > > Yes. This, and: "we are aware of the fact that this was a mistake". > > BTW: we want to do this because it seems that many abuses of > ad-hoc URI > scheme usage was indeed inspired by WebDAV. > > > Finally, section 19's discussion about what IANA must do > (!?) should > > be repaired to identify the two *URI*schemes* that must be > registered, > > the one for "DAV:" URIs and the one for "opaquelocktoken:" > URIs. IANA > > does not register namespaces, and that language should be > removed from > > section 19. > > I agree with the statement that "DAV:" and "opaquelocktoken:" are URI > schemes, not URI namespaces. I'm *not* sure that I agree with > the rest. > "Instructions to Request for Comments (RFC) Authors" says in > : > > Any RFC that defines a new "namespace" of assigned > numbers should > include an IANA Considerations section specifying how > that space > should be administered. See "Guidelines for Writing an IANA > Considerations Section in RFCs" [IANA98] for a > detailed discussion > of the issues to be considered and the contents of > this section. > > RFC2518 does define several namespaces: the space of WebDAV property > names, the space of WebDAV protocol element names, and so on. I think > it's correct to mention that in the IANA Considerations section. > > [ ... ] > > > > Note that both defining a new URI scheme just for the purpose of > > identifying protocol elements and using just the scheme > name as a > > namespace name are inconsistent with current best practice. Use > > of the "DAV:" and "opaquelocktoken:" URIs is preserved for > > compatibility with existing deployments. There will be no further > > introduction of new URI schemes as part of DAV. > > I like that except for "...are inconsistent with current best > practice". > The usage of a URI scheme name as a URI indeed does not comply to the > URI syntax (according RFC2396, there is no such thing as a > URI with an > empty scheme-dependant part). > > If we want to get really verbose we can also state that RFC2396bis > () is going to > lift this > restriction in order to make usage of URIs auch as "dav:" or "about:" > legal > (). But that's a future IETF document we probably don't want to wait for. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Nov 2 17:14: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 RAA27093 for ; Sun, 2 Nov 2003 17:14:23 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 2B597A051D; Sun, 2 Nov 2003 17:14: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 F21F7A051D for ; Sun, 2 Nov 2003 17:14:30 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 8FD5713378; Sun, 2 Nov 2003 17:14:30 -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 1F9EF13364 for ; Sun, 2 Nov 2003 17:14:30 -0500 (EST) Received: (qmail 14920 invoked by uid 65534); 2 Nov 2003 22:14:15 -0000 Received: from p3EE24831.dip.t-dialin.net (EHLO gmx.de) (62.226.72.49) by mail.gmx.net (mp006) with SMTP; 02 Nov 2003 23:14:15 +0100 X-Authenticated: #1915285 Message-ID: <3FA5818B.10305@gmx.de> Date: Sun, 02 Nov 2003 23:13:31 +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: dennis.hamilton@acm.org 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: rfc2518bis issue 03-C03 - DAV: Scheme X-Archived-At: http://www.w3.org/mid/3FA5818B.10305@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8079 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: <20031102221433.2B597A051D@frink.w3.org> Resent-Date: Sun, 2 Nov 2003 17:14:33 -0500 (EST) Content-Transfer-Encoding: 7bit Dennis E. Hamilton wrote: > Oh my. > > Let me make sure I understand the key aspects of the situation here: > > 1. The DAV and opaquelocktoken URI scheme *names* are registered with IANA (with the names as their descriptions and citation of rfc2518 as the source), > . > Is there actually a defined scheme, or has there been merely registration of the scheme name? A URI scheme registration takes place by defining it inside a standards track document. For "opaquelocktoken", the scheme is indeed defined inside RFC2518 (both purpose and syntax), while there isn't a lot of text about "DAV:". We may want to fix that. > 2. The form "DAV:" is not an acceptable form for a URI according to the URI format specifications, although the editors of the URI specification revision have accepted the request to allow that form. Correct. > 3. The XML Namespace specifications requires a URI as the value for the xmlns attribute. At the moment, it would be permissible for an XML processor to reject DAV XML because of a malformed xmlns URI, though I doubt that has come up in practice, since a URI is basically opaque in the context of XML Namespace. Yes. In fact, the namespace recommendation only says "takes the form of a URI (reference)", so there was a lot of dicussion about that two years ago. Fact is, the whole issue was triggered by Jing (a schema validator written by Jim Clark) rejecting the namespace name "DAV:". > This is an interesting nit. I gather it is not new news. Nope. > What is the appropriate action? Make "DAV:" a legal URI (update RFC2396) and apologize for the URI abuse (updated RFC2518). Both underway. > PS: I don't think the passage in is about XML Namespaces as such. If the DAV WG thinks that the DAV namespace is an assigned-number space -- that is, the equivalent of a protocol tag set, then the issue should be addressed (even by an explicit statement that it is not being addressed or the requirement is not applicable, etc.). I don't believe that registering a scheme name is responsive to this requirement, however. My sense is that the greatest contribution to management of the protocol elements identified using the DAV namespace would be making an explicit, clear statement about what the extension mechanism is and who is the authority for additions to the DAV namespace, since it is allowed to be extended over time. The question then becomes, what is invariant over time? And once an element is introduced, what is then invariant over time? -- dh No, it's not about XML namespaces. But that doesn't change the fact that RFC2518 introduces new spaces of names, and it needs to define them (syntax, change control and so on). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Nov 2 17: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 RAA27320 for ; Sun, 2 Nov 2003 17:27:56 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id DC457A051D; Sun, 2 Nov 2003 17:28: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 B605CA051D for ; Sun, 2 Nov 2003 17:28:04 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 3C6D2134BC; Sun, 2 Nov 2003 17:28:04 -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 C06C113363 for ; Sun, 2 Nov 2003 17:28:03 -0500 (EST) Received: (qmail 1548 invoked by uid 65534); 2 Nov 2003 22:27:56 -0000 Received: from p3EE24831.dip.t-dialin.net (EHLO gmx.de) (62.226.72.49) by mail.gmx.net (mp026) with SMTP; 02 Nov 2003 23:27:56 +0100 X-Authenticated: #1915285 Message-ID: <3FA584B4.5030305@gmx.de> Date: Sun, 02 Nov 2003 23:27:00 +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: dennis.hamilton@acm.org, w3c-dist-auth@w3.org References: <094d01c3a18c$7075d650$f8cb90c6@lisalap> In-Reply-To: <094d01c3a18c$7075d650$f8cb90c6@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: rfc2518bis issue 03-C03 - DAV: Scheme X-Archived-At: http://www.w3.org/mid/3FA584B4.5030305@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8080 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: <20031102222806.DC457A051D@frink.w3.org> Resent-Date: Sun, 2 Nov 2003 17:28:06 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >>2. The form "DAV:" is not an acceptable form for a URI >>according to the URI format specifications, although the >>editors of the URI specification revision have accepted the >>request to allow that form. > > > I would be surprised to hear this -- I'd like to see what It should also be mentioned in: > makes it unacceptable. I agree it's not well specified, so to It isn't an absolute URI because absolute URIs have non-empty scheme-dependant parts. It's not a URI reference either because it contains an unescaped ":". Again - see the entries on the issues lists for RFC2396 and RFC2518. > believe it's acceptable means you have to assume that the > definition for the DAV: scheme allows a null URI after the > scheme part. But why would you assume that would be > unacceptable? Most URI schemes require something after the > scheme name, but clearly DAV: doesn't. No, no, that's incorrect. The syntax of "DAV:" URIs MUST comply to what the URI specification says (see above). > That's a good point. It *is* possible to create new URIs > under the DAV: scheme name, now that it's defined. E.g. we > could have defined "DAV:deltav", "DAV:bindings", etc as > namespaces for various extension elements. There isn't anything > written down, however, about how to construct valid URIs using > the DAV: scheme. ...because we are too lazy, and this doesn't seem to be an issue. What we *should* state is: only WebDAV WG standard tracks documents may define/use new URIs in the DAV: scheme (that's the "change control" part). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Nov 2 19:41: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 TAA01487 for ; Sun, 2 Nov 2003 19:41:20 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 09B9DA0690; Sun, 2 Nov 2003 19:41:29 -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 39C0FA0690 for ; Sun, 2 Nov 2003 19:41:26 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 0DD111359D; Sun, 2 Nov 2003 19:41:26 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail4.atl.registeredsite.com (mail4.atl.registeredsite.com [64.224.219.78]) by dr-nick.w3.org (Postfix) with ESMTP id E727513484 for ; Sun, 2 Nov 2003 19:41:25 -0500 (EST) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail4.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id hA30fOlC003454; Sun, 2 Nov 2003 19:41:24 -0500 Received: from compagno (67-42-105-77.tukw.qwest.net [67.42.105.77]) by infonuovo.com (8.8.7/8.8.5) with SMTP id QAA03386; Sun, 2 Nov 2003 16:41:22 -0800 (PST) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , "Lisa Dusseault" Cc: Date: Sun, 2 Nov 2003 16:41:15 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <3FA584B4.5030305@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: rfc2518bis issue 03-C03 - DAV: Scheme X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAOEGBDEAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8081 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: <20031103004129.09B9DA0690@frink.w3.org> Resent-Date: Sun, 2 Nov 2003 19:41:29 -0500 (EST) Content-Transfer-Encoding: quoted-printable Lisa, My reading of this is the same as Julian's. The URI RFC stipulates the = admissible syntax of URIs, with a modest variety of flavors. None of = the rules currently allow "DAV:" as a valid URI form. And the editor of = their -bis document has accepted a modification that allows the empty = part.=20 Julian, I think a bigger part of the change control has to do with use of a DAV = URI as a namespace identifier. Something similar should be stated in = that respect, along with the condition on who gets to create URIs in the = DAV scheme. I think that means I am also aligned with what you say = about defining the "namespace" in your other note with this subject = line. -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, November 02, 2003 14:27 To: Lisa Dusseault Cc: dennis.hamilton@acm.org; w3c-dist-auth@w3.org Subject: Re: rfc2518bis issue 03-C03 - DAV: Scheme Lisa Dusseault wrote: >>2. The form "DAV:" is not an acceptable form for a URI=20 >>according to the URI format specifications, although the=20 >>editors of the URI specification revision have accepted the=20 >>request to allow that form. >=20 >=20 > I would be surprised to hear this -- I'd like to see what=20 It should also be mentioned in: > makes it unacceptable. I agree it's not well specified, so to It isn't an absolute URI because absolute URIs have non-empty=20 scheme-dependant parts. It's not a URI reference either because it=20 contains an unescaped ":". Again - see the entries on the issues lists for RFC2396 and RFC2518. [ ... ] > There isn't anything > written down, however, about how to construct valid URIs using > the DAV: scheme. =20 ...because we are too lazy, and this doesn't seem to be an issue. What=20 we *should* state is: only WebDAV WG standard tracks documents may=20 define/use new URIs in the DAV: scheme (that's the "change control" = part). Julian --=20 bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Nov 3 16:14:56 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21828 for ; Mon, 3 Nov 2003 16:14:56 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id E3BA0A05E7; Mon, 3 Nov 2003 16:15:04 -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 62175A05E7 for ; Mon, 3 Nov 2003 16:15:01 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id F164A13716; Mon, 3 Nov 2003 16:15:00 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by dr-nick.w3.org (Postfix) with ESMTP id E3A87136BF for ; Mon, 3 Nov 2003 16:15:00 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AGlmT-0001Us-CY; Mon, 03 Nov 2003 15:58:33 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce: ; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Mon, 03 Nov 2003 15:58:33 -0500 Subject: Protocol Action: 'WebDAV Access Control Protocol' to Proposed Standard X-Archived-At: http://www.w3.org/mid/E1AGlmT-0001Us-CY@asgard.ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8082 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: <20031103211504.E3BA0A05E7@frink.w3.org> Resent-Date: Mon, 3 Nov 2003 16:15:04 -0500 (EST) The IESG has approved following document: - 'WebDAV Access Control Protocol ' as a Proposed Standard This document is the product of the WWW Distributed Authoring and Versioning Working Group. The IESG contact persons are Ted Hardie and Ned Freed. Technical Summary This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. Working Group Summary This document is a product of the Web Distributed Authoring and Versioning (WebDAV) working group of the Internet Engineering Task Force. Protocol Quality Ned Freed reviewed this document for the IESG. From w3c-dist-auth-request@w3.org Mon Nov 3 19:59: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 TAA06410 for ; Mon, 3 Nov 2003 19:59:20 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 620F6A068C; Mon, 3 Nov 2003 19:59:29 -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 077FDA068C for ; Mon, 3 Nov 2003 19:59:26 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 496DD138D0; Mon, 3 Nov 2003 19:58:09 -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 C032613509 for ; Mon, 3 Nov 2003 19:58:08 -0500 (EST) Received: from Tycho (dhcp-63-150.cse.ucsc.edu [128.114.63.150]) by ucsc.edu (8.10.1/8.10.1) with SMTP id hA40tCk22170 for ; Mon, 3 Nov 2003 16:55:12 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 3 Nov 2003 16:56:31 -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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Protocol Action: 'WebDAV Access Control Protocol' to Proposed Standard X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIEEMAJPAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8083 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: <20031104005929.620F6A068C@frink.w3.org> Resent-Date: Mon, 3 Nov 2003 19:59:29 -0500 (EST) Content-Transfer-Encoding: 7bit Yeah! After over five years of work, we now have an access control protocol standard. Many thanks are due to Julian Reschke, Geoff Clemm, and Eric Sedlar for pushing this draft through to completion. Additionally, there have been many, many people over the years who have contributed to this specification through direct work, list messages, implementation experience, reading drafts, etc. Most of these are captured in the acknowledgements of this draft (let me know if you think there are any omissions) -- my sincere gratitude to everyone who has contributed. There were many times when I didn't think this draft would *ever* see RFC status, and so it's very gratifying that this important piece of the WebDAV protocol architecture is now complete. We now have the basis for interoperable access control across a wide range of client applications, opening up WebDAV servers for many new kinds of applications. Let's now turn our attention to DASL and bindings, and finish the final pieces of the WebDAV protocol suite. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of The IESG > Sent: Monday, November 03, 2003 12:59 PM > To: IETF-Announce: > Cc: Internet Architecture Board; RFC Editor; w3c-dist-auth@w3.org > Subject: Protocol Action: 'WebDAV Access Control Protocol' to Proposed > Standard > > > > The IESG has approved following document: > > - 'WebDAV Access Control Protocol ' > as a Proposed Standard > > This document is the product of the WWW Distributed Authoring and > Versioning > Working Group. > > The IESG contact persons are Ted Hardie and Ned Freed. > > Technical Summary > > This document specifies a set of methods, headers, message bodies, > properties, and reports that define Access Control extensions to the > WebDAV Distributed Authoring Protocol. This protocol permits a client > to read and modify access control lists that instruct a server > whether to allow or deny operations upon a resource (such as > HyperText Transfer Protocol (HTTP) method invocations) by a given > principal. A lightweight representation of principals as Web > resources supports integration of a wide range of user management > repositories. Search operations allow discovery and manipulation of > principals using human names. > > Working Group Summary > > This document is a product of the Web Distributed Authoring and > Versioning (WebDAV) working group of the Internet Engineering Task > Force. > > Protocol Quality > > Ned Freed reviewed this document for the IESG. From w3c-dist-auth-request@w3.org Mon Nov 3 20:06: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 UAA06621 for ; Mon, 3 Nov 2003 20:06:59 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 41703A0503; Mon, 3 Nov 2003 20:07: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 07E58A077A for ; Mon, 3 Nov 2003 20:07:06 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id A6ACE1341C; Mon, 3 Nov 2003 20:07:05 -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 3AE3C13374 for ; Mon, 3 Nov 2003 20:07:05 -0500 (EST) Received: from Tycho (dhcp-63-150.cse.ucsc.edu [128.114.63.150]) by ucsc.edu (8.10.1/8.10.1) with SMTP id hA415Gk25904 for ; Mon, 3 Nov 2003 17:05:16 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 3 Nov 2003 17:06:36 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: WebDAV book now available X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIOEMAJPAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8084 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: <20031104010708.41703A0503@frink.w3.org> Resent-Date: Mon, 3 Nov 2003 20:07:08 -0500 (EST) Content-Transfer-Encoding: 7bit The WebDAV community also had a milestone of a different sort this week, with the publication of the first book dedicated to WebDAV. It's titled, "WebDAV: Next-Generation Collaborative Web Authoring," by our WG Co-Chair, Lisa Dusseault. http://www.amazon.com/exec/obidos/ASIN/0130652083/ The book is published by Prentice-Hall, and is 544 pages long. It describes the WebDAV and DeltaV protocols, and gives examples of how to write WebDAV applications. There are currently no other books available that describe the WebDAV protocol as thoroughly. Congratulations, Lisa, on the successful completion of this challenging project! - Jim From w3c-dist-auth-request@w3.org Tue Nov 4 13:34: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 NAA26915 for ; Tue, 4 Nov 2003 13:34:58 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 6BD36A051E; Tue, 4 Nov 2003 13:35: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 2B5E3A051E for ; Tue, 4 Nov 2003 13:35:02 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 0B63113671; Tue, 4 Nov 2003 13:35:02 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by dr-nick.w3.org (Postfix) with ESMTP id B30D013377 for ; Tue, 4 Nov 2003 13:35:01 -0500 (EST) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail1.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hA4IYYjf005500 for ; Tue, 4 Nov 2003 10:35:00 -0800 (PST) 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 hA4IY7P27205 for ; Tue, 4 Nov 2003 11:34:08 -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 hA4HYpP12176 for ; Tue, 4 Nov 2003 10:34:51 -0700 (MST) Message-ID: <008301c3a2f9$a082f800$c5b42382@us.oracle.com> From: "Stanley Guan" To: Date: Tue, 4 Nov 2003 09:32:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01C3A2B6.9228C980" 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: Status Code/Entity body encoded in XML X-Archived-At: http://www.w3.org/mid/008301c3a2f9$a082f800$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8085 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: <20031104183508.6BD36A051E@frink.w3.org> Resent-Date: Tue, 4 Nov 2003 13:35:08 -0500 (EST) This is a multi-part message in MIME format. ------=_NextPart_000_0080_01C3A2B6.9228C980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, What's the rule of thumb to find out there is an XML payload in the entity body? In the following examples,=20 1. Status code alone doesn't provide the clue However, the spec. says that: "Based on returned status code, the client can=20 always take a resonable course of action." 2. Content-Type seems to be the clue. What's the guideline for the server to return an XML payload in the entity body? Say, for the PROPFIND, can it returns 200 (instead of 207) as status code and returns the property value like: ... Will appreciate your clarification! -Stanley =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PROPFIND /container/ HTTP/1.1=20 Host: www.foo.bar=20 Content-Length: xxxx=20 Content-Type: text/xml; charset=3D"utf-8"=20 >>Response=20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 ... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Request LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: = webdav.sb.aol.com Timeout: Infinite, Second-4100000000 Content-Type: = text/xml; charset=3D"utf-8" Content-Length: xxxx Authorization: Digest = username=3D"ejw", realm=3D"ejw@webdav.sb.aol.com", nonce=3D"...", = uri=3D"/workspace/webdav/proposal.doc", response=3D"...", opaque=3D"..." = http://www.ics.uci.edu/~ejw/contact.html> >>Response HTTP/1.1 200 OK Content-Type: text/xml; charset=3D"utf-8" = Content-Length: xxxx ... ------=_NextPart_000_0080_01C3A2B6.9228C980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
What's the rule of thumb to find out = there is an=20 XML payload
in the entity body?  In the = following=20 examples,
    1. Status code alone = doesn't=20 provide the clue
        However,=20 the spec. says that:
           = "Based on=20 returned status code, the client can=20
            = always=20 take a resonable course of action."
    2. Content-Type = seems to be the=20 clue.
 
What's the guideline for the server to = return an=20 XML payload
in the entity body?  Say, for the = PROPFIND,=20 can it returns
200 (instead of 207) as status code and = returns the=20 property
value like:
   <?xml version=3D"1.0" encoding=3D"utf-8" = ?>
  =20 <D:prop xmlns:D=3D"DAV:">
  =20 ...
   = </D:prop>
 
Will appreciate your = clarification!
 
-Stanley
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar =
Content-Length: xxxx=20
Content-Type: text/xml; charset=3D"utf-8"=20 

   <?xml version=3D"1.0" encoding=3D"utf-8" ?>
   <D:propfind xmlns:D=3D'DAV:'>
     <D:prop><D:lockdiscovery/></D:prop>
   </D:propfind>

>>Response=20

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; = charset=3D"utf-8"=20
Content-Length: xxxx=20 

   <?xml version=3D"1.0" encoding=3D"utf-8" ?>
  =
 ...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>>Request

LOCK /workspace/webdav/proposal.doc HTTP/1.1 =
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000 =
Content-Type: text/xml; charset=3D"utf-8"
Content-Length: xxxx =
Authorization: Digest username=3D"ejw", =
realm=3D"ejw@webdav.sb.aol.com", nonce=3D"...", =
uri=3D"/workspace/webdav/proposal.doc",
response=3D"...", = opaque=3D"..." 

   <?xml version=3D"1.0" encoding=3D"utf-8" =
?>
   <D:lockinfo xmlns:D=3D'DAV:'>
     <D:lockscope><D:exclusive/></D:lockscope>
     <D:locktype><D:write/></D:locktype>
     <D:owner>
          <D:href>        =
">http://www.ics.uci.edu/~ejw/contact.html>
     </D:owner>
   </D:lockinfo>
>>Response 
HTTP/1.1 200 OK 
Content-Type: text/xml; =
charset=3D"utf-8" 
Content-Length: xxxx 
   <?xml =
version=3D"1.0" encoding=3D"utf-8" ?>
    ...


------=_NextPart_000_0080_01C3A2B6.9228C980--



From w3c-dist-auth-request@w3.org  Tue Nov  4 13:49: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 NAA27414
	for ; Tue, 4 Nov 2003 13:49:38 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 676C9A0788; Tue,  4 Nov 2003 13:49: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 57708A0A88
	for ; Tue,  4 Nov 2003 13:49:17 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id E8D9413BEE; Tue,  4 Nov 2003 13:45:09 -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 55C1D13BC8
	for ; Tue,  4 Nov 2003 13:45:09 -0500 (EST)
Received: (qmail 11240 invoked by uid 65534); 4 Nov 2003 18:45:04 -0000
Received: from pD950C243.dip.t-dialin.net (EHLO gmx.de) (217.80.194.67)
  by mail.gmx.net (mp005) with SMTP; 04 Nov 2003 19:45:04 +0100
X-Authenticated: #1915285
Message-ID: <3FA7F38A.9090205@gmx.de>
Date: Tue, 04 Nov 2003 19:44:26 +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: Stanley Guan 
Cc: w3c-dist-auth@w3.org
References: <008301c3a2f9$a082f800$c5b42382@us.oracle.com>
In-Reply-To: <008301c3a2f9$a082f800$c5b42382@us.oracle.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Status Code/Entity body encoded in XML
X-Archived-At: http://www.w3.org/mid/3FA7F38A.9090205@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8086
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: <20031104184935.676C9A0788@frink.w3.org>
Resent-Date: Tue,  4 Nov 2003 13:49:35 -0500 (EST)
Content-Transfer-Encoding: 7bit


Stanley Guan wrote:

> Hi,
>  
> What's the rule of thumb to find out there is an XML payload
> in the entity body?  In the following examples,
>     1. Status code alone doesn't provide the clue
>         However, the spec. says that:
>            "Based on returned status code, the client can
>             always take a resonable course of action."
>     2. Content-Type seems to be the clue.
>  
> What's the guideline for the server to return an XML payload
> in the entity body?  Say, for the PROPFIND, can it returns
> 200 (instead of 207) as status code and returns the property
> value like:
>    
>    
>    ...
>    
>  
> Will appreciate your clarification!

1) PROPFIND never returns a 200 code.

2) If a method returns 207, the content type MUST be */xml, and the 
response must have a DAV:multistatus root element.

3) Servers *may* return a */xml response for 4xx and 5xx status codes, 
in which case a client can test for a DAV:error root element or a 
DAV:multistatus element to extract more information.

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov  4 15:24:54 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03595
	for ; Tue, 4 Nov 2003 15:24:54 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E998AA099C; Tue,  4 Nov 2003 15:23: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 AD72BA099C
	for ; Tue,  4 Nov 2003 15:23:38 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 3B3C713917; Tue,  4 Nov 2003 15:23:38 -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 07286136A0
	for ; Tue,  4 Nov 2003 15:23:38 -0500 (EST)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by agminet01.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hA4KNZjK002344;
	Tue, 4 Nov 2003 12:23:35 -0800
Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1])
	by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id hA4KNYw08537;
	Tue, 4 Nov 2003 13:23:34 -0700 (MST)
Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197])
	by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id hA4KNUw08343;
	Tue, 4 Nov 2003 13:23:30 -0700 (MST)
Message-ID: <009901c3a311$7135ab20$c5b42382@us.oracle.com>
From: "Stanley Guan" 
To: "Julian Reschke" 
Cc: 
References: <008301c3a2f9$a082f800$c5b42382@us.oracle.com> <3FA7F38A.9090205@gmx.de>
Date: Tue, 4 Nov 2003 12:23:00 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: Re: Status Code/Entity body encoded in XML
X-Archived-At: http://www.w3.org/mid/009901c3a311$7135ab20$c5b42382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8087
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: <20031104202341.E998AA099C@frink.w3.org>
Resent-Date: Tue,  4 Nov 2003 15:23:41 -0500 (EST)
Content-Transfer-Encoding: 7bit


See comments in line!

Thx,

-Stanley

----- Original Message ----- 
From: "Julian Reschke" 
To: "Stanley Guan" 
Cc: 
Sent: Tuesday, November 04, 2003 10:44 AM
Subject: Re: Status Code/Entity body encoded in XML


> Stanley Guan wrote:
> 
>   
>
> 1) PROPFIND never returns a 200 code.

How do you come up with the conclusion?  What section of the
spec. says about it?

> 
> 2) If a method returns 207, the content type MUST be */xml, and the 
> response must have a DAV:multistatus root element.
> 
> 3) Servers *may* return a */xml response for 4xx and 5xx status codes, 
> in which case a client can test for a DAV:error root element or a 
> DAV:multistatus element to extract more information.

Does the only status codes that servers may return a */xml response include
only:
    4xx, 5xx, and 207?

> 
> Julian
> 
> -- 
> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> 



From w3c-dist-auth-request@w3.org  Tue Nov  4 15:32: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 PAA04052
	for ; Tue, 4 Nov 2003 15:32:19 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0C02EA09F7; Tue,  4 Nov 2003 15:32:30 -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 69FC0A09F7
	for ; Tue,  4 Nov 2003 15:32:27 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 4FFCD13974; Tue,  4 Nov 2003 15:32:27 -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 22C6013958
	for ; Tue,  4 Nov 2003 15:32:27 -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 hA4KWPjK009882;
	Tue, 4 Nov 2003 12:32:25 -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 hA4KWN120821;
	Tue, 4 Nov 2003 13:32:24 -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 hA4KWM120789;
	Tue, 4 Nov 2003 13:32:22 -0700 (MST)
Message-ID: <00a501c3a312$ae19efa0$c5b42382@us.oracle.com>
From: "Stanley Guan" 
To: "Julian Reschke" 
Cc: 
References: <008301c3a2f9$a082f800$c5b42382@us.oracle.com> <3FA7F38A.9090205@gmx.de>
Date: Tue, 4 Nov 2003 12:31:51 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: Re: Status Code/Entity body encoded in XML
X-Archived-At: http://www.w3.org/mid/00a501c3a312$ae19efa0$c5b42382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8088
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: <20031104203230.0C02EA09F7@frink.w3.org>
Resent-Date: Tue,  4 Nov 2003 15:32:30 -0500 (EST)
Content-Transfer-Encoding: 7bit


> 3) Servers *may* return a */xml response for 4xx and 5xx status codes, 
> in which case a client can test for a DAV:error root element or a 
> DAV:multistatus element to extract more information.
> 
> Julian

"DAV:error" seems to be new in "bis".   Do we need a subsection
for it in section 13 of "XML Element Definitions"?

> 
> -- 
> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> 



From w3c-dist-auth-request@w3.org  Tue Nov  4 15:35: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 PAA04299
	for ; Tue, 4 Nov 2003 15:35:46 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 598F1A09C9; Tue,  4 Nov 2003 15:35:57 -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 650A3A09C9
	for ; Tue,  4 Nov 2003 15:35:55 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 43FA013999; Tue,  4 Nov 2003 15:35:55 -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 70BEA13820
	for ; Tue,  4 Nov 2003 15:35:54 -0500 (EST)
Received: (qmail 18950 invoked by uid 65534); 4 Nov 2003 20:35:47 -0000
Received: from pD950C243.dip.t-dialin.net (EHLO gmx.de) (217.80.194.67)
  by mail.gmx.net (mp010) with SMTP; 04 Nov 2003 21:35:47 +0100
X-Authenticated: #1915285
Message-ID: <3FA80D88.7030707@gmx.de>
Date: Tue, 04 Nov 2003 21:35:20 +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: Stanley Guan 
Cc: w3c-dist-auth@w3.org
References: <008301c3a2f9$a082f800$c5b42382@us.oracle.com> <3FA7F38A.9090205@gmx.de> <009901c3a311$7135ab20$c5b42382@us.oracle.com>
In-Reply-To: <009901c3a311$7135ab20$c5b42382@us.oracle.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Status Code/Entity body encoded in XML
X-Archived-At: http://www.w3.org/mid/3FA80D88.7030707@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8089
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: <20031104203557.598F1A09C9@frink.w3.org>
Resent-Date: Tue,  4 Nov 2003 15:35:57 -0500 (EST)
Content-Transfer-Encoding: 7bit


Stanley Guan wrote:

> See comments in line!
> 
> Thx,
> 
> -Stanley
> 
>>Stanley Guan wrote:
>>
>>  
>>
>>1) PROPFIND never returns a 200 code.
> 
> 
> How do you come up with the conclusion?  What section of the
> spec. says about it?

Possibly none. If this is the case, it should be fixed.


>>2) If a method returns 207, the content type MUST be */xml, and the 
>>response must have a DAV:multistatus root element.
>>
>>3) Servers *may* return a */xml response for 4xx and 5xx status codes, 
>>in which case a client can test for a DAV:error root element or a 
>>DAV:multistatus element to extract more information.
> 
> 
> Does the only status codes that servers may return a */xml response include
> only:
>     4xx, 5xx, and 207?

Servers MAY return */xml on any request. However, the spec only 
specifies what this means for 207, 4xx and 5xx.


Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov  4 15:47:10 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 PAA04763
	for ; Tue, 4 Nov 2003 15:47:10 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3AAC1A058C; Tue,  4 Nov 2003 15:47:20 -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 3B2D4A058C
	for ; Tue,  4 Nov 2003 15:47:18 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 0701F133A5; Tue,  4 Nov 2003 15:47:18 -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 7E55413766
	for ; Tue,  4 Nov 2003 15:47:17 -0500 (EST)
Received: (qmail 3325 invoked by uid 65534); 4 Nov 2003 20:47:10 -0000
Received: from pD950C243.dip.t-dialin.net (EHLO gmx.de) (217.80.194.67)
  by mail.gmx.net (mp006) with SMTP; 04 Nov 2003 21:47:10 +0100
X-Authenticated: #1915285
Message-ID: <3FA81030.8030303@gmx.de>
Date: Tue, 04 Nov 2003 21:46:40 +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: Stanley Guan 
Cc: w3c-dist-auth@w3.org
References: <008301c3a2f9$a082f800$c5b42382@us.oracle.com> <3FA7F38A.9090205@gmx.de> <00a501c3a312$ae19efa0$c5b42382@us.oracle.com>
In-Reply-To: <00a501c3a312$ae19efa0$c5b42382@us.oracle.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Status Code/Entity body encoded in XML
X-Archived-At: http://www.w3.org/mid/3FA81030.8030303@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8090
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: <20031104204720.3AAC1A058C@frink.w3.org>
Resent-Date: Tue,  4 Nov 2003 15:47:20 -0500 (EST)
Content-Transfer-Encoding: 7bit


Stanley Guan wrote:

>>3) Servers *may* return a */xml response for 4xx and 5xx status codes, 
>>in which case a client can test for a DAV:error root element or a 
>>DAV:multistatus element to extract more information.
>>
>>Julian
> 
> 
> "DAV:error" seems to be new in "bis".   Do we need a subsection
> for it in section 13 of "XML Element Definitions"?

Yes (if only for consistency with the current documentation style).

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov  4 19:22:52 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 TAA12795
	for ; Tue, 4 Nov 2003 19:22:52 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7FEFFA0688; Tue,  4 Nov 2003 19:23:01 -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 CB256A0B65
	for ; Tue,  4 Nov 2003 19:22:38 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 5339A13CE2; Tue,  4 Nov 2003 19:21:13 -0500 (EST)
Delivered-To: w3c-dist-auth@w3.org
Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by dr-nick.w3.org (Postfix) with ESMTP id D98CA13C6B
	for ; Tue,  4 Nov 2003 19:21:12 -0500 (EST)
Received: from Tycho (dhcp-63-150.cse.ucsc.edu [128.114.63.150])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id hA50IYc04918
	for ; Tue, 4 Nov 2003 16:18:34 -0800 (PST)
From: "Jim Whitehead" 
To: "WebDAV" 
Date: Tue, 4 Nov 2003 16:20:39 -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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: Meeting at IETF-58
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIIEPJJPAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8091
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: <20031105002301.7FEFFA0688@frink.w3.org>
Resent-Date: Tue,  4 Nov 2003 19:23:01 -0500 (EST)
Content-Transfer-Encoding: 7bit


The final agenda for IETF-58 is now out. The WEBDAV Working Group will meet
on Thursday, November 13, 2003, from 3:30 to 5:30 PM (Afternoon Sessions
II).

For more information on the IETF meeting, including details on how to
register and attend, see:

http://www.ietf.org/meetings/IETF-58.html

- Jim



From w3c-dist-auth-request@w3.org  Wed Nov  5 13:23:10 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 NAA15867
	for ; Wed, 5 Nov 2003 13:23:10 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 609B0A0609; Wed,  5 Nov 2003 13:23:01 -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 252DAA09EF
	for ; Wed,  5 Nov 2003 13:22:57 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id F107413E62; Wed,  5 Nov 2003 13:21:51 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id BCA8D13E54
	for ; Wed,  5 Nov 2003 13:21:51 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AHSHv-0000sP-00; Wed, 05 Nov 2003 18:21:51 +0000
Received: from [198.144.203.248] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AHSHu-0000sE-00; Wed, 05 Nov 2003 18:21:50 +0000
From: "Lisa Dusseault" 
To: , "'Webdav WG'" 
Date: Wed, 5 Nov 2003 10:21:15 -0800
Message-ID: <001c01c3a3c9$99955300$f8cb90c6@lisalap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
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
Old-X-Envelope-To: agenda@ietf.org,
 w3c-dist-auth@w3c.org
Subject: Agenda for WebDAV meeting, 58th IETF
X-Archived-At: http://www.w3.org/mid/001c01c3a3c9$99955300$f8cb90c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8092
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: <20031105182301.609B0A0609@frink.w3.org>
Resent-Date: Wed,  5 Nov 2003 13:23:01 -0500 (EST)
Content-Transfer-Encoding: 7bit



WebDAV WG
Meeting 1530-1730, Rochester room

Agenda
 - Review ACL status - to RFC
 - Brief Interop results discussion
 - Discuss bindings and redirects drafts & plans
 - RFC2518bis issues
	- Do namespace prefixes need to be preserved
	- Review requirements for ETags
	- Plans?  Milestones?
 - Quota draft - plans, milestones?

Lisa Dusseault




From w3c-dist-auth-request@w3.org  Thu Nov  6 06:58: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 GAA05265
	for ; Thu, 6 Nov 2003 06:58:05 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8750EA057F; Thu,  6 Nov 2003 06:58:17 -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 A7380A076A
	for ; Thu,  6 Nov 2003 06:58:14 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 5F41713954; Thu,  6 Nov 2003 06:58:14 -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 E8A44137E5
	for ; Thu,  6 Nov 2003 06:58:13 -0500 (EST)
Received: (qmail 14882 invoked by uid 65534); 6 Nov 2003 11:58:09 -0000
Received: from p3EE24748.dip.t-dialin.net (EHLO gmx.de) (62.226.71.72)
  by mail.gmx.net (mp005) with SMTP; 06 Nov 2003 12:58:09 +0100
X-Authenticated: #1915285
Message-ID: <3FAA3741.4090303@gmx.de>
Date: Thu, 06 Nov 2003 12:57:53 +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: <001c01c3a3c9$99955300$f8cb90c6@lisalap>
In-Reply-To: <001c01c3a3c9$99955300$f8cb90c6@lisalap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Agenda for WebDAV meeting, 58th IETF
X-Archived-At: http://www.w3.org/mid/3FAA3741.4090303@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8093
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: <20031106115817.8750EA057F@frink.w3.org>
Resent-Date: Thu,  6 Nov 2003 06:58:17 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> 
> WebDAV WG
> Meeting 1530-1730, Rochester room
> 
> Agenda
>  - Review ACL status - to RFC
>  - Brief Interop results discussion
>  - Discuss bindings and redirects drafts & plans

I'll not be able to attend the meeting, but here's a status update on 
redirect refs...:

- the latest submitted draft is 
 
(October 2003)

- the latest edits are here: 


The main remaining issues are listed at after the TOC:

- get rid of MKRESOURCE if favor of a simpler method that can only 
create redirect reference resources; this should also allow to *update* 
redirect reference resources (with a new target)

- allow authoring of 301s as well,

- finish the synchronization between RFC2518bis and the redirect ref 
spec on how PROPFIND should behave when a collection contains redirect 
references

- almost all other issues are editorial or about terminology -- 
proposals how to resolve these (replacement text!) are welcome

Another issue that's not listed yer:

- COPY applied to a collection containing redirect refs currently is 
specified not to copy the redirects (unless the client explicitly 
specifies that using "Apply-To-Redirect-Ref"). Thus, non-redirect-ref 
aware clients will always get a 207 (that is, only a partial success) 
when attempting the COPY. We should consider allowing he COPY to succeed 
if the server is able to recreate an equivalent redirect reference at 
the target.

 >  - RFC2518bis issues
 > 	- Do namespace prefixes need to be preserved
 > 	- Review requirements for ETags
 > 	- Plans?  Milestones?
 >  - Quota draft - plans, milestones?

Note that I sent an issues list one week ago 
(), 
I haven't seen any feedback since.

 > Lisa Dusseault

Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Nov  6 07:32:52 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 HAA06115
	for ; Thu, 6 Nov 2003 07:32:52 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id ABF6BA05A9; Thu,  6 Nov 2003 07:33:02 -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 E8A86A05B1
	for ; Thu,  6 Nov 2003 07:32:58 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id CD0031377E; Thu,  6 Nov 2003 07:32:58 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.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 AAC641374C
	for ; Thu,  6 Nov 2003 07:32:58 -0500 (EST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA6CWwYJ435470
	for ; Thu, 6 Nov 2003 07:32:58 -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 hA6CWu2v235222
	for ; Thu, 6 Nov 2003 07:32:57 -0500
In-Reply-To: <3FAA3741.4090303@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: Thu, 6 Nov 2003 07:32:48 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF106 | October 27, 2003) at
 11/06/2003 07:32:56,
	Serialize complete at 11/06/2003 07:32:56
Content-Type: multipart/alternative; boundary="=_alternative 0044EA8485256DD6_="
Subject: Re: remaining redirect ref issues
X-Archived-At: http://www.w3.org/mid/OF0BC855F4.78FAFD7D-ON85256DD6.00447C45-85256DD6.0044EA8F@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8094
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: <20031106123302.ABF6BA05A9@frink.w3.org>
Resent-Date: Thu,  6 Nov 2003 07:33:02 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 0044EA8485256DD6_=
Content-Type: text/plain; charset="US-ASCII"

WRT to the open redirect issues:

Julian wrote on 11/06/2003 06:57:53 AM:

> The main remaining issues are listed at after the TOC:
> 
> - get rid of MKRESOURCE if favor of a simpler method that can only 
> create redirect reference resources; this should also allow to *update* 
> redirect reference resources (with a new target)

I agree.

> - allow authoring of 301s as well,

I agree.

> - finish the synchronization between RFC2518bis and the redirect ref 
> spec on how PROPFIND should behave when a collection contains redirect 
> references

Are there issues here, or is this just editorial?

> - almost all other issues are editorial or about terminology -- 
> proposals how to resolve these (replacement text!) are welcome

Probably the best thing here is to start a thread on these issues,
along with your current proposed solution, so we can bring them to
closure.

> Another issue that's not listed yer:
> 
> - COPY applied to a collection containing redirect refs currently is 
> specified not to copy the redirects (unless the client explicitly 
> specifies that using "Apply-To-Redirect-Ref"). Thus, non-redirect-ref 
> aware clients will always get a 207 (that is, only a partial success) 
> when attempting the COPY. We should consider allowing he COPY to succeed 

> if the server is able to recreate an equivalent redirect reference at 
> the target.

I agree.  We should just state this.

Cheers,
Geoff




--=_alternative 0044EA8485256DD6_=
Content-Type: text/html; charset="US-ASCII"



WRT to the open redirect issues:



Julian wrote on 11/06/2003 06:57:53 AM:



> The main remaining issues are listed at after the TOC:

> 

> - get rid of MKRESOURCE if favor of a simpler method that can only


> create redirect reference resources; this should also allow to *update*


> redirect reference resources (with a new target)



I agree.



> - allow authoring of 301s as well,



I agree.



> - finish the synchronization between RFC2518bis and the redirect ref


> spec on how PROPFIND should behave when a collection contains redirect


> references



Are there issues here, or is this just editorial?



> - almost all other issues are editorial or about terminology -- 

> proposals how to resolve these (replacement text!) are welcome



Probably the best thing here is to start a thread
on these issues,

along with your current proposed solution, so we can
bring them to

closure.



> Another issue that's not listed yer:

> 

> - COPY applied to a collection containing redirect refs currently
is 

> specified not to copy the redirects (unless the client explicitly


> specifies that using "Apply-To-Redirect-Ref"). Thus, non-redirect-ref


> aware clients will always get a 207 (that is, only a partial success)


> when attempting the COPY. We should consider allowing he COPY to succeed


> if the server is able to recreate an equivalent redirect reference
at 

> the target.



I agree.  We should just state this.



Cheers,

Geoff








--=_alternative 0044EA8485256DD6_=--



From w3c-dist-auth-request@w3.org  Thu Nov  6 07:40: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 HAA06346
	for ; Thu, 6 Nov 2003 07:40:57 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 71678A0601; Thu,  6 Nov 2003 07:40: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 F0F1FA07C7
	for ; Thu,  6 Nov 2003 07:40:34 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 86811137CF; Thu,  6 Nov 2003 07:40:31 -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 0EE34135AD
	for ; Thu,  6 Nov 2003 07:40:31 -0500 (EST)
Received: (qmail 19866 invoked by uid 65534); 6 Nov 2003 12:40:29 -0000
Received: from p3EE24748.dip.t-dialin.net (EHLO gmx.de) (62.226.71.72)
  by mail.gmx.net (mp016) with SMTP; 06 Nov 2003 13:40:29 +0100
X-Authenticated: #1915285
Message-ID: <3FAA4136.3050507@gmx.de>
Date: Thu, 06 Nov 2003 13:40:22 +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: remaining redirect ref issues
X-Archived-At: http://www.w3.org/mid/3FAA4136.3050507@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8095
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: <20031106124037.71678A0601@frink.w3.org>
Resent-Date: Thu,  6 Nov 2003 07:40:37 -0500 (EST)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> 
> WRT to the open redirect issues:
> 
> Julian wrote on 11/06/2003 06:57:53 AM:

...

>  > - finish the synchronization between RFC2518bis and the redirect ref
>  > spec on how PROPFIND should behave when a collection contains redirect
>  > references
> 
> Are there issues here, or is this just editorial?

I'd say almost editorial. However it would be welcome if someone who was 
part of the WG during the '2000 last call could make suggestions for 
replacement text (or alternatively state why we don't need to make a 
change).

>  > - almost all other issues are editorial or about terminology --
>  > proposals how to resolve these (replacement text!) are welcome
> 
> Probably the best thing here is to start a thread on these issues,
> along with your current proposed solution, so we can bring them to
> closure.
> 
>  > Another issue that's not listed yer:
>  >
>  > - COPY applied to a collection containing redirect refs currently is
>  > specified not to copy the redirects (unless the client explicitly
>  > specifies that using "Apply-To-Redirect-Ref"). Thus, non-redirect-ref
>  > aware clients will always get a 207 (that is, only a partial success)
>  > when attempting the COPY. We should consider allowing he COPY to succeed
>  > if the server is able to recreate an equivalent redirect reference at
>  > the target.
> 
> I agree.  We should just state this.

OK, so we'll say that if a non-referencing-protocol aware client issues 
a COPY, the redirect references should be copied as well (instead of 
leaving them out and producing 302 status entries in the multistatus).

Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Fri Nov  7 21:00:09 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 VAA18552
	for ; Fri, 7 Nov 2003 21:00:09 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 64B40A0B66; Fri,  7 Nov 2003 21:00: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 9707DA0B71
	for ; Fri,  7 Nov 2003 21:00:13 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 48D5F13544; Fri,  7 Nov 2003 21:00: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 2BF051346C
	for ; Fri,  7 Nov 2003 21:00:09 -0500 (EST)
Received: from xythos.com ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 7 Nov 2003 18:00:04 -0800
Date: Fri, 7 Nov 2003 18:00:05 -0800
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: w3c-dist-auth@w3.org
To: Julian Reschke 
From: Brian Korver 
In-Reply-To: <3F9D9256.6080100@gmx.de>
Message-Id: <45B2A98B-118F-11D8-9A81-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-OriginalArrivalTime: 08 Nov 2003 02:00:04.0491 (UTC) FILETIME=[06D995B0:01C3A59C]
Subject: Re: Review of draft-ietf-webdav-quota-02.txt    
X-Archived-At: http://www.w3.org/mid/45B2A98B-118F-11D8-9A81-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8096
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: <20031108020019.64B40A0B66@frink.w3.org>
Resent-Date: Fri,  7 Nov 2003 21:00:19 -0500 (EST)
Content-Transfer-Encoding: 7bit


On Monday, October 27, 2003, at 01:47  PM, Julian Reschke wrote:
>
> Issues with draft-ietf-webdav-quota-02.txt
>
> Content
>
> 01-C01 Organization
>  0425.html>
>  0438.html>
>
> I think the draft could greatly benefit by a more clean separation of  
> (a) terminology, (b) protocol (property/error code) definition and (c)  
> examples.
>
> Proposal for a outline:
>
> 1 Introduction/Notation/Terminology
> 2 Additional live properties
> 3 Modification to behaviour of existing methods (error marshalling)
> 4...n Other standard RFC section
> A (Appendix) Examples of how servers may implement quota
>
> I'm happy to help restructuring the document if this is just a  
> amount-of-work issue.
>
>
> 01-C02 DAV:quota-assigned-bytes
>  0425.html>
>  0436.html>
>
> The issue here seems to be that an additional property is required to  
> make the quota authorable. I honestly haven't understood yet why it's  
> needed. The problem seems to be that as the reported quota may be a  
> "best pick" by the server (there may be multiple quotas in place, but  
> only the most strict will be reported at any point of time). If this  
> is the case this could potentially be fixed by exposing all quotas to  
> the client.

The issue of supporting "many" quotas on a resource was discussed
and rejected.


>
> At the end of the day, unless we can agree about how this is supposed  
> to work I strongly suggest to leave it out of the base spec and use a  
> vendor-specific property for setting it.
>
>
> 01-C03 quota vs disk space
>  0439.html>
>  0460.html>
>
> The spec says that servers may expose physical disk limits as quota.
>
> a) This is incompatible with NFS from which we're borrowing the  
> semantics (it treats disk limits as a separate property, and so should  
> we)
> b) Stefan raised interesting usability issue that weren't resolved so  
> far  
> ( 0456.html>).

Perhaps you're still looking at an older version of the draft?
Addressing this issue was the biggest change between -01 and -02.



>
>
> 02-C01 Condition Name
>
> Use name of precondition, not failure description:  
>  instead of 

Does anyone else want to vote on the necessity of this change?


>
>
> 02-C02 allprop marshalling
>
> Change to MUST NOT (to reflect current ACL/DeltaV/Ordering approach).

Could you provide the text?


>
>
>
> Editorial:
>
> 02-E01 non-ASCII characters in draft
>
> 02-E02 sample host names do not conform to RFC2606
>
> 02-E03 missing section numbers
>
>
> -- 
> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
>
>
-brian
briank@xythos.com



From w3c-dist-auth-request@w3.org  Sat Nov  8 04:27: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 EAA11268
	for ; Sat, 8 Nov 2003 04:27:50 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 240AEA05C6; Sat,  8 Nov 2003 04:27:58 -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 3AC57A0624
	for ; Sat,  8 Nov 2003 04:27:53 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id B8A1514304; Sat,  8 Nov 2003 04:23:12 -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 4B546142EE
	for ; Sat,  8 Nov 2003 04:23:12 -0500 (EST)
Received: (qmail 11517 invoked by uid 65534); 8 Nov 2003 09:23:07 -0000
Received: from pD950C277.dip.t-dialin.net (EHLO gmx.de) (217.80.194.119)
  by mail.gmx.net (mp012) with SMTP; 08 Nov 2003 10:23:07 +0100
X-Authenticated: #1915285
Message-ID: <3FACB5D2.4020000@gmx.de>
Date: Sat, 08 Nov 2003 10:22:26 +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: Brian Korver 
Cc: w3c-dist-auth@w3.org
References: <45B2A98B-118F-11D8-9A81-000393751598@xythos.com>
In-Reply-To: <45B2A98B-118F-11D8-9A81-000393751598@xythos.com>
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/3FACB5D2.4020000@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8097
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: <20031108092758.240AEA05C6@frink.w3.org>
Resent-Date: Sat,  8 Nov 2003 04:27:58 -0500 (EST)
Content-Transfer-Encoding: 7bit


Brian Korver wrote:

>> 01-C02 DAV:quota-assigned-bytes
>> 
>> 
>>
>> The issue here seems to be that an additional property is required to  
>> make the quota authorable. I honestly haven't understood yet why it's  
>> needed. The problem seems to be that as the reported quota may be a  
>> "best pick" by the server (there may be multiple quotas in place, but  
>> only the most strict will be reported at any point of time). If this  
>> is the case this could potentially be fixed by exposing all quotas to  
>> the client.
> 
> 
> The issue of supporting "many" quotas on a resource was discussed
> and rejected.

True. This is a simplification that works well as long as the quota is 
not authorable. If it becomes authorable (by means of this additional 
property), there's a big issue because the behavior of the server 
becomes completely unpredictable.

>> 01-C03 quota vs disk space
>> 
>> 
>>
>> The spec says that servers may expose physical disk limits as quota.
>>
>> a) This is incompatible with NFS from which we're borrowing the  
>> semantics (it treats disk limits as a separate property, and so 
>> should  we)
>> b) Stefan raised interesting usability issue that weren't resolved so  
>> far  (> 0456.html>).
> 
> 
> Perhaps you're still looking at an older version of the draft?
> Addressing this issue was the biggest change between -01 and -02.

Nope. Somewhere on page 3 it says:

"Note that there may be a number of distinct but overlapping limits, 
which may even include physical media limits."

(wouldn't it be nice to have section numbers?)

>> 02-C01 Condition Name
>>
>> Use name of precondition, not failure description:  
>>  instead of 
> 
> 
> Does anyone else want to vote on the necessity of this change?

Please.

>> 02-C02 allprop marshalling
>>
>> Change to MUST NOT (to reflect current ACL/DeltaV/Ordering approach).
> 
> 
> Could you provide the text?

Change:

     None of these properties need be returned in a  request
     though the server may include them.  However, these property names
     MUST be returned in a  request for a resource that
     supports the properties, except in the case of infinite limits which
     are explained below.

to

"A DAV:allprop PROPFIND request SHOULD NOT return any of the properties 
defined by this document."

(or just refer to RFC3253, section 3.11)


Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Sat Nov  8 05:59: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 FAA12756
	for ; Sat, 8 Nov 2003 05:59:21 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B80EFA055C; Sat,  8 Nov 2003 05:59:31 -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 699D8A055C
	for ; Sat,  8 Nov 2003 05:59:28 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 2162814317; Sat,  8 Nov 2003 05:59:28 -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 A1A9014307
	for ; Sat,  8 Nov 2003 05:59:27 -0500 (EST)
Received: (qmail 10328 invoked by uid 65534); 8 Nov 2003 10:59:23 -0000
Received: from pD950C277.dip.t-dialin.net (EHLO gmx.de) (217.80.194.119)
  by mail.gmx.net (mp006) with SMTP; 08 Nov 2003 11:59:23 +0100
X-Authenticated: #1915285
Message-ID: <3FACCC66.2070603@gmx.de>
Date: Sat, 08 Nov 2003 11:58: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: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: rfc2518-bis-05 issues (part 4)
X-Archived-At: http://www.w3.org/mid/3FACCC66.2070603@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8098
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: <20031108105931.B80EFA055C@frink.w3.org>
Resent-Date: Sat,  8 Nov 2003 05:59:31 -0500 (EST)
Content-Transfer-Encoding: 7bit


Here's another issue:


05-C13 extensibility of responsedescription element

Section 13.19 states:

"Extensibility: MAY be extended with attributes which SHOULD be ignored."

However: RFC3253, section 1.6 *already* does extend it with a child 
element (DAV:error).


Regards, Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760




From w3c-dist-auth-request@w3.org  Sat Nov  8 08:03:43 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15332
	for ; Sat, 8 Nov 2003 08:03:43 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 59033A066D; Sat,  8 Nov 2003 08:03: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 0BE7CA066D
	for ; Sat,  8 Nov 2003 08:03:49 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 52A4A143A5; Sat,  8 Nov 2003 08:00:41 -0500 (EST)
Delivered-To: w3c-dist-auth@w3.org
Received: from smtpout.mac.com (A17-250-248-85.apple.com [17.250.248.85])
	by dr-nick.w3.org (Postfix) with ESMTP id F02EB143A3
	for ; Sat,  8 Nov 2003 08:00:40 -0500 (EST)
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id hA8D0ewk013608
	for ; Sat, 8 Nov 2003 05:00:40 -0800 (PST)
Received: from [192.168.1.103] (h189.240.40.162.ip.alltel.net [162.40.240.189])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id hA8D0dZr028403
	for ; Sat, 8 Nov 2003 05:00:39 -0800 (PST)
Mime-Version: 1.0
X-Sender: frank.lowney@mail.mac.com
Message-Id: 
In-Reply-To: <45B2A98B-118F-11D8-9A81-000393751598@xythos.com>
References: <45B2A98B-118F-11D8-9A81-000393751598@xythos.com>
Date: Sat, 8 Nov 2003 08:00:37 -0500
To: w3c-dist-auth@w3.org
From: Frank Lowney 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: Review of draft-ietf-webdav-quota-02.txt
X-Archived-At: http://www.w3.org/mid/p06010201bbd29452e5a2@%5B192.168.1.103%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8099
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: <20031108130352.59033A066D@frink.w3.org>
Resent-Date: Sat,  8 Nov 2003 08:03:52 -0500 (EST)


Re quotas, as an implementor (reliant on what server vendors make 
available) I'm not sure I understand the discussion very well so let 
me make a few general comments from my perspective and hope that you 
can see whether and how they fit.

The current bias of WebDAV implementation favors the single web site 
that has multiple authors.  In this context, a single, overriding 
quota makes sense.  Of course, this site could be one of many Virtual 
Hosts running on the same machine, served by the same webserver, etc. 
I have no quarrel with that scenario at all.

My problem is with the exclusion of another, very important class of 
website, the individual web site and this is not favored by the 
WebDAV bias.  While this class of web site may include personal web 
sites that may be considered frivolous, it also includes  many 
serious, professional web sites that need WebDAV even more that 
large, corporate/institutional web sites do.

For example, we currently host a Faculty Web Server where every 
faculty person is allocated 250 Mb of space with which to share 
information relevant to their teaching, service and research.  If 
they try to FTP upload beyond that limit, they are programmatically 
refused.  There is also a "soft" limit where they get a warning and 
we have a CGI that gives them a graphical and numeric representation 
of their allocation and how much of it has been used.

We would really like to replace FTP with WebDAV but to do so will 
require being able to set and enforce hard/soft limits and provide 
feedback such that account holders can regulate their own behavior.

At this point in history, WebDAV is like the Wild West.  The first 
person to grab disk space gets to keep it and the others have to make 
do with less.  We actually have one faculty person who managed to lay 
claim to more than a Gig of space before we implemented the limits.

Even more daunting is the prospect of a Student Web Server with 
5,000+ accounts that we are currently in the planning stages for. 
Students will be required to develop portfolios that will be used to 
evaluate their work prior to graduation and provide prospective 
employers with data to support employment decisions after graduation. 
Not frivolous at all.
-- 
=====================================================================
Dr. Frank Lowney  frank.lowney@gcsu.edu
     Director, Electronic Instructional Services, a unit of the
     Office of Information and Instructional Technology,
     Professional Pages: http://www.gcsu.edu/oiit/eis/
     Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
=====================================================================
We don't make instruction effective, we make effective instruction 
more accessible.

Please note that my new e-mail address is: frank.lowney@gcsu.edu



From w3c-dist-auth-request@w3.org  Sat Nov  8 08:47: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 IAA15990
	for ; Sat, 8 Nov 2003 08:47:41 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8F245A0884; Sat,  8 Nov 2003 08:47:50 -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 DAE25A0884
	for ; Sat,  8 Nov 2003 08:47:44 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id A6CAE139ED; Sat,  8 Nov 2003 08:47:44 -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 188F4135F1
	for ; Sat,  8 Nov 2003 08:47:44 -0500 (EST)
Received: (qmail 20649 invoked by uid 65534); 8 Nov 2003 13:47:38 -0000
Received: from p3EE24766.dip.t-dialin.net (EHLO gmx.de) (62.226.71.102)
  by mail.gmx.net (mp003) with SMTP; 08 Nov 2003 14:47:38 +0100
X-Authenticated: #1915285
Message-ID: <3FACF3C9.3050101@gmx.de>
Date: Sat, 08 Nov 2003 14:46:49 +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: Frank Lowney 
Cc: w3c-dist-auth@w3.org
References: <45B2A98B-118F-11D8-9A81-000393751598@xythos.com> 
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/3FACF3C9.3050101@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8100
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: <20031108134750.8F245A0884@frink.w3.org>
Resent-Date: Sat,  8 Nov 2003 08:47:50 -0500 (EST)
Content-Transfer-Encoding: 7bit


Frank Lowney wrote:

> Re quotas, as an implementor (reliant on what server vendors make 
> available) I'm not sure I understand the discussion very well so let me 
> make a few general comments from my perspective and hope that you can 
> see whether and how they fit.
>
 > ...

Frank, essentially what you're saying is that quotas are a good thing. I 
don't think anybody disagrees. As a matter of fact, some WebDAV servers 
indeed support quotas (for instance, the Xythos server or (I think) 
Apple's IDisk server).

The discussion that we're currently having is how a server can *expose* 
quota information to the client. This has little to do with actually 
*enforcing* the quota (as the current implementations show). All this 
new protocol is supposed to add is

- an interoperable way for clients to find out about their quota situation
- and possibly a way to modify quotas from the client (although it seems 
to be hard to define an interoperable way to do that)

Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 10 07:56: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 HAA18163
	for ; Mon, 10 Nov 2003 07:56:02 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id F216FA0A77; Mon, 10 Nov 2003 07:56:09 -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 4A721A0A78
	for ; Mon, 10 Nov 2003 07:56:00 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 068AF133EE; Mon, 10 Nov 2003 07:56:00 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20])
	by dr-nick.w3.org (Postfix) with SMTP id 8212E13807
	for ; Mon, 10 Nov 2003 07:55:58 -0500 (EST)
Received: (qmail 9425 invoked by uid 65534); 10 Nov 2003 12:55:58 -0000
Received: from unknown (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp021) with SMTP; 10 Nov 2003 13:55:58 +0100
X-Authenticated: #1915285
Message-ID: <3FAF8ADA.7070000@gmx.de>
Date: Mon, 10 Nov 2003 13:55:54 +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: w3c-dist-auth@w3c.org, dav-dev@lyra.org, slide-user@jakarta.apache.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Agenda for WebDAV meeting, 58th IETF
X-Archived-At: http://www.w3.org/mid/3FAF8ADA.7070000@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8101
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: <20031110125609.F216FA0A77@frink.w3.org>
Resent-Date: Mon, 10 Nov 2003 07:56:09 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

reminder: there is optional text conferencing through which people can 
"virtually" attend the meeting. Details are summarized in:



Regards, Julian

P.S.: 15.30 Minneapolis time seems to be 21:30 UTC.

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 10 09:29:52 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 JAA20807
	for ; Mon, 10 Nov 2003 09:29:52 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1025CA06A8; Mon, 10 Nov 2003 09:30:03 -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 ECB9DA06A8
	for ; Mon, 10 Nov 2003 09:29:51 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 701D7137B2; Mon, 10 Nov 2003 09:29:51 -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 D1CF91349F
	for ; Mon, 10 Nov 2003 09:29:50 -0500 (EST)
Received: (qmail 24985 invoked by uid 65534); 10 Nov 2003 14:29:50 -0000
Received: from unknown (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp003) with SMTP; 10 Nov 2003 15:29:50 +0100
X-Authenticated: #1915285
Message-ID: <3FAFA0DD.7090102@gmx.de>
Date: Mon, 10 Nov 2003 15:29:49 +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: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: remaining redirect ref issues
X-Archived-At: http://www.w3.org/mid/3FAFA0DD.7090102@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8102
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: <20031110143003.1025CA06A8@frink.w3.org>
Resent-Date: Mon, 10 Nov 2003 09:30:03 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

in case people want to discuss this during the IETF meeting, here's a 
summary of the major open issue left with the redirect references 
protocol 
().

There are (at least) two major design goals, but unfortunately both are 
in direct contradiction:

#1: Maximum consistency with HTTP/1.1 (RFC2616). This means that any 
request that addresses a redirect reference resource MUST result in a 
3xx status code (obviously the whole point is that GET MUST result in a 
redirection, and if it does, it's hard to say why other methods such as 
PUT or DELETE should behave differently). Therefore, the redirect 
reference protocol introduces a new request header 
("Apply-To-Redirect-Ref") through which a client can indicate that the 
request indeed should be applied to the redirect reference resource itself.

#2: Maximum usability with existing clients. For instance, the Microsoft 
Webfolder client will not be able to DELETE a redirect reference 
resource unless the server deviates from #1.

Right now I'm not sure about the best way to resolve this. Currently the 
spec chooses #1 (back when this decision was made, there was probably 
the assumption that existing clients would quickly be updated -- 
something that probably isn't true today).

However this may result in implementers either just ignoring these 
rules, or adding special workarounds based on "User Agent" detection.

Feedback appreciated,

Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760




From w3c-dist-auth-request@w3.org  Mon Nov 10 11:43:05 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 LAA29101
	for ; Mon, 10 Nov 2003 11:43:05 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D3AC1A0989; Mon, 10 Nov 2003 11:43: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 88AD7A0A9B
	for ; Mon, 10 Nov 2003 11:42:53 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 6C53213CE7; Mon, 10 Nov 2003 11:42:21 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id 3AC2813CE3
	for ; Mon, 10 Nov 2003 11:42:16 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AJF7H-0004RB-00
	for w3c-dist-auth@w3c.org; Mon, 10 Nov 2003 16:42:15 +0000
Received: from [130.129.133.243] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AJF7H-0004R0-00
	for w3c-dist-auth@w3c.org; Mon, 10 Nov 2003 16:42:15 +0000
From: "Lisa Dusseault" 
To: "'Webdav WG'" 
Date: Mon, 10 Nov 2003 10:41:47 -0800
Message-ID: <015901c3a7ba$4cde2b50$fa898182@lisalap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: FW: Request for review of draft-nystrom-http-sasl-09.txt
X-Archived-At: http://www.w3.org/mid/015901c3a7ba$4cde2b50$fa898182@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8103
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: <20031110164306.D3AC1A0989@frink.w3.org>
Resent-Date: Mon, 10 Nov 2003 11:43:06 -0500 (EST)
Content-Transfer-Encoding: 7bit


Obviously SASL support for HTTP is of wide interest to this group... please
let
the group (plus Alexey and Magnus) know if you can review this.

Lisa

-----Original Message-----
From: Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] 
Sent: Monday, November 10, 2003 8:32 AM
To: lisa@xythos.com
Cc: Magnus Nystrom
Subject: Request for review of draft-nystrom-http-sasl-09.txt


Hi Lisa,
Magnus and I are working on a document that adds SASL (RFC 2222) support 
to HTTP. We think we are close to Last Calling the document (currently
draft-nystrom-http-sasl-09.txt) and we are wondering if you 
could review the document (from HTTP prospective) or can recommend 
somebody to review it.

Thank you,
Alexey
__________________________________________

Isode Limited, http://www.isode.com

IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html
__________________________________________







From w3c-dist-auth-request@w3.org  Mon Nov 10 20:22: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 UAA27444
	for ; Mon, 10 Nov 2003 20:22:59 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9E5B8A095B; Mon, 10 Nov 2003 20:22:47 -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 A863BA0A64
	for ; Mon, 10 Nov 2003 20:22:43 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 37E0613633; Mon, 10 Nov 2003 20:22:43 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11])
	by dr-nick.w3.org (Postfix) with ESMTP id B263713B04
	for ; Mon, 10 Nov 2003 20:22:42 -0500 (EST)
Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27])
	by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id hAB1MUP03645
	for ; Mon, 10 Nov 2003 17:22:32 -0800 (PST)
Message-ID: <3FB039D6.90406@cse.ucsc.edu>
Date: Mon, 10 Nov 2003 17:22:30 -0800
From: Elias Sinderson 
Reply-To: w3c-dist-auth@w3c.org
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3c.org
References: <3FAF8ADA.7070000@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Agenda for WebDAV meeting, 58th IETF
X-Archived-At: http://www.w3.org/mid/3FB039D6.90406@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8104
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: <20031111012247.9E5B8A095B@frink.w3.org>
Resent-Date: Mon, 10 Nov 2003 20:22:47 -0500 (EST)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:

> reminder: there is optional text conferencing through which people can 
> "virtually" attend the meeting. [...]

Additionally, it would be great if anyone planning on using visual aids 
during the meeting (e.g. Powerpoint slides) would make these resources 
available online.  :-)


Cheers,
Elias



From w3c-dist-auth-request@w3.org  Wed Nov 12 11:02:10 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 LAA24076
	for ; Wed, 12 Nov 2003 11:02:09 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 77284A07A8; Wed, 12 Nov 2003 11:02:20 -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 E2384A07A8
	for ; Wed, 12 Nov 2003 11:02:16 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 9342213E10; Wed, 12 Nov 2003 11:02:16 -0500 (EST)
Delivered-To: w3c-dist-auth@w3.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id 77C8E13E09
	for ; Wed, 12 Nov 2003 11:02:16 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AJxRg-0003tP-00; Wed, 12 Nov 2003 16:02:16 +0000
Received: from [130.129.133.195] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AJxRf-0003t5-00; Wed, 12 Nov 2003 16:02:15 +0000
From: "Lisa Dusseault" 
To: "'Julian Reschke'" ,
        "'Brian Korver'" 
Cc: 
Date: Wed, 12 Nov 2003 10:01:49 -0800
Message-ID: <006401c3a947$0d91d8a0$82808182@lisalap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <3FACB5D2.4020000@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Old-X-Envelope-To: briank@xythos.com,
 julian.reschke@gmx.de,
 w3c-dist-auth@w3.org
Subject: RE: Review of draft-ietf-webdav-quota-02.txt
X-Archived-At: http://www.w3.org/mid/006401c3a947$0d91d8a0$82808182@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8105
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: <20031112160220.77284A07A8@frink.w3.org>
Resent-Date: Wed, 12 Nov 2003 11:02:20 -0500 (EST)
Content-Transfer-Encoding: 7bit



> True. This is a simplification that works well as long as the 
> quota is 
> not authorable. If it becomes authorable (by means of this additional 
> property), there's a big issue because the behavior of the server 
> becomes completely unpredictable.

It should be simple to make things predictable by saying that the
server MUST (SHOULD?) support only one quota if it allows that quota
to be authored via the mechanism in this draft.

In practice, there is usually one important size limitation.  On a 
service like sharemation or Apple's iDisk, that's the quota.  On a
hard drive that's the drive size.  Even though in theory there may
be a size-limited hard drive behind a quota-limiting system, it won't
change how things work except in extremely rare cases.  And let's not 
design a system that is optimized for the extremely rare cases.

Lisa




From w3c-dist-auth-request@w3.org  Wed Nov 12 11:08:28 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 LAA24377
	for ; Wed, 12 Nov 2003 11:08:27 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id ED48FA08C1; Wed, 12 Nov 2003 11:08:36 -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 D44B4A0814
	for ; Wed, 12 Nov 2003 11:08:34 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 7CFE213854; Wed, 12 Nov 2003 11:08:34 -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 0772A13853
	for ; Wed, 12 Nov 2003 11:08:34 -0500 (EST)
Received: (qmail 14979 invoked by uid 65534); 12 Nov 2003 16:08:33 -0000
Received: from mail.greenbytes.de (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp003) with SMTP; 12 Nov 2003 17:08:33 +0100
X-Authenticated: #1915285
Message-ID: <3FB25B00.60200@gmx.de>
Date: Wed, 12 Nov 2003 17:08:32 +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: "'Brian Korver'" , w3c-dist-auth@w3.org
References: <006401c3a947$0d91d8a0$82808182@lisalap>
In-Reply-To: <006401c3a947$0d91d8a0$82808182@lisalap>
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/3FB25B00.60200@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8106
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: <20031112160836.ED48FA08C1@frink.w3.org>
Resent-Date: Wed, 12 Nov 2003 11:08:36 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

>>True. This is a simplification that works well as long as the 
>>quota is 
>>not authorable. If it becomes authorable (by means of this additional 
>>property), there's a big issue because the behavior of the server 
>>becomes completely unpredictable.
> 
> 
> It should be simple to make things predictable by saying that the
> server MUST (SHOULD?) support only one quota if it allows that quota
> to be authored via the mechanism in this draft.

That would work, but seems like a hack. First we sell it as a feature 
that the server selects a specific quota, and then a feature is added 
that is incompatible with that.

> In practice, there is usually one important size limitation.  On a 
> service like sharemation or Apple's iDisk, that's the quota.  On a
> hard drive that's the drive size.  Even though in theory there may
> be a size-limited hard drive behind a quota-limiting system, it won't
> change how things work except in extremely rare cases.  And let's not 
> design a system that is optimized for the extremely rare cases.

We just reached agreement that physical disk limits should not be 
treated as quota, right Brian?

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Nov 12 12:04:56 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27719
	for ; Wed, 12 Nov 2003 12:04:55 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7D60CA0A42; Wed, 12 Nov 2003 12:03: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 6B9D0A0A4B
	for ; Wed, 12 Nov 2003 12:03:12 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id EB2F213E90; Wed, 12 Nov 2003 12:03:11 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id D11A41345F
	for ; Wed, 12 Nov 2003 12:03:11 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AJyOd-0004QP-00
	for w3c-dist-auth@w3c.org; Wed, 12 Nov 2003 17:03:11 +0000
Received: from [130.129.133.195] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AJyOd-0004QE-00
	for w3c-dist-auth@w3c.org; Wed, 12 Nov 2003 17:03:11 +0000
From: "Lisa Dusseault" 
To: 
Date: Wed, 12 Nov 2003 11:02:39 -0800
Message-ID: <007501c3a94f$9079ae70$82808182@lisalap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <3FB039D6.90406@cse.ucsc.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: RE: Agenda for WebDAV meeting, 58th IETF
X-Archived-At: http://www.w3.org/mid/007501c3a94f$9079ae70$82808182@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8107
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: <20031112170322.7D60CA0A42@frink.w3.org>
Resent-Date: Wed, 12 Nov 2003 12:03:22 -0500 (EST)
Content-Transfer-Encoding: quoted-printable


Here's the visual aids so far.  Comments welcome.
http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-iet=
f58
.ppt=20

See you in webdav@ietf.xmpp.org tomorrow...

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org=20
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Elias Sinderson
> Sent: Monday, November 10, 2003 5:23 PM
> To: w3c-dist-auth@w3c.org
> Subject: Re: Agenda for WebDAV meeting, 58th IETF
>=20
>=20
>=20
> Julian Reschke wrote:
>=20
> > reminder: there is optional text conferencing through which=20
> people can
> > "virtually" attend the meeting. [...]
>=20
> Additionally, it would be great if anyone planning on using=20
> visual aids=20
> during the meeting (e.g. Powerpoint slides) would make these=20
> resources=20
> available online.  :-)
>=20
>=20
> Cheers,
> Elias
>=20
>=20




From w3c-dist-auth-request@w3.org  Wed Nov 12 16:08:44 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09747
	for ; Wed, 12 Nov 2003 16:08:44 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 929E3A0797; Wed, 12 Nov 2003 16:08: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 9731BA0515
	for ; Wed, 12 Nov 2003 16:08:48 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 3BE691369C; Wed, 12 Nov 2003 16:08:48 -0500 (EST)
Delivered-To: w3c-dist-auth@w3.org
Received: from mac.wakasoft.com (unknown [65.208.153.194])
	by dr-nick.w3.org (Postfix) with ESMTP id D2BF013362
	for ; Wed, 12 Nov 2003 16:08:47 -0500 (EST)
Received: from apache.org (localhost [127.0.0.1])
	by mac.wakasoft.com (8.12.9/8.12.9) with ESMTP id hACL8Zdg004094;
	Wed, 12 Nov 2003 13:08:35 -0800 (PST)
Date: Wed, 12 Nov 2003 13:08:34 -0800
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: w3c-dist-auth@w3.org
To: Julian Reschke 
From: "Roy T. Fielding" 
In-Reply-To: <3FAFA0DD.7090102@gmx.de>
Message-Id: <60691A7A-1554-11D8-9F2A-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Subject: Re: remaining redirect ref issues
X-Archived-At: http://www.w3.org/mid/60691A7A-1554-11D8-9F2A-000393753936@apache.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8108
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: <20031112210854.929E3A0797@frink.w3.org>
Resent-Date: Wed, 12 Nov 2003 16:08:54 -0500 (EST)
Content-Transfer-Encoding: 7bit


> There are (at least) two major design goals, but unfortunately both 
> are in direct contradiction:
>
> #1: Maximum consistency with HTTP/1.1 (RFC2616). This means that any 
> request that addresses a redirect reference resource MUST result in a 
> 3xx status code (obviously the whole point is that GET MUST result in 
> a redirection, and if it does, it's hard to say why other methods such 
> as PUT or DELETE should behave differently). Therefore, the redirect 
> reference protocol introduces a new request header 
> ("Apply-To-Redirect-Ref") through which a client can indicate that the 
> request indeed should be applied to the redirect reference resource 
> itself.
>
> #2: Maximum usability with existing clients. For instance, the 
> Microsoft Webfolder client will not be able to DELETE a redirect 
> reference resource unless the server deviates from #1.
>
> Right now I'm not sure about the best way to resolve this. Currently 
> the spec chooses #1 (back when this decision was made, there was 
> probably the assumption that existing clients would quickly be updated 
> -- something that probably isn't true today).

I am certain I have said this before, though it was several years ago.
The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure to get 
straight
on that one bit is what causes webdav to trip over HTTP whenever it
tries to "author" anything other than a boring old file.

In this case, there must be two different URIs -- one for the resource
and one for the configuration of that resource.  That configuration
may be as simple as a URI, maybe a status code and a URI, or maybe even
an XML document -- that is what must be defined by the redirect 
protocol.
The actual URI which responds to requests with a redirect should have a
link to its configuration URI, such that an authoring tool can discover
the authorable resource that causes this resource to redirect.  That is
why webdav requires a source link in order to perform HTTP authoring.

The same principle holds for all dynamic content.

....Roy



From w3c-dist-auth-request@w3.org  Wed Nov 12 17:37:01 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 RAA13638
	for ; Wed, 12 Nov 2003 17:37:01 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 81884A0890; Wed, 12 Nov 2003 17:36: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 8DD7FA0944
	for ; Wed, 12 Nov 2003 17:36:11 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 31E02136EB; Wed, 12 Nov 2003 17:34:47 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id 7F1B113ED5
	for ; Wed, 12 Nov 2003 17:34:43 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AK3ZS-00075j-00; Wed, 12 Nov 2003 22:34:42 +0000
Received: from [130.129.128.130] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AK3ZS-00075Y-00; Wed, 12 Nov 2003 22:34:42 +0000
From: "Lisa Dusseault" 
To: "'Webdav WG'" 
Date: Wed, 12 Nov 2003 16:34:20 -0800
Message-ID: <007301c3a97d$e10c9450$82808182@lisalap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Old-X-Envelope-To: mankin@psg.com,
 w3c-dist-auth@w3c.org
Subject: GEOPRIV and HTTP (WebDAV)? as storage model
X-Archived-At: http://www.w3.org/mid/007301c3a97d$e10c9450$82808182@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8109
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: <20031112223619.81884A0890@frink.w3.org>
Resent-Date: Wed, 12 Nov 2003 17:36:19 -0500 (EST)
Content-Transfer-Encoding: 7bit



The geopriv working group has made much progress on its requirements,
policies and data model.  

Geopriv is working on the way Internet applications share geographic
location information.  The 'priv' part of the name comes from the
privacy concerns over letting a wide audience know where you are.  
This isn't limited to people, however, but also devices or abstract
entities.

One of the goals of geopriv is to get its objects into existing
protocols such as HTTP.  There's some initial proposals in this area
(http://www.ietf.org/internet-drafts/draft-daviel-http-geo-header-04.txt)

This email is to inform the WebDAV WG of this work and to call for
volunteers and participants.  Please email me if you're interested 
and what level of interest - document review, design participation, 
etc.

Geopriv charter:
http://www.ietf.org/html.charters/geopriv-charter.html

Lisa




From w3c-dist-auth-request@w3.org  Wed Nov 12 17:38: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 RAA13715
	for ; Wed, 12 Nov 2003 17:38:59 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E80C7A05AD; Wed, 12 Nov 2003 17:38: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 331ECA05AD
	for ; Wed, 12 Nov 2003 17:38:13 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 0F3EC13D49; Wed, 12 Nov 2003 17:38: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 BC4EB136EB
	for ; Wed, 12 Nov 2003 17:38:12 -0500 (EST)
Received: from xythos.com ([12.162.212.206]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 12 Nov 2003 14:38:10 -0800
Date: Wed, 12 Nov 2003 16:38:16 -0600
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: w3c-dist-auth@w3.org
To: Julian Reschke 
From: Brian Korver 
In-Reply-To: <3FB25B00.60200@gmx.de>
Message-Id: 
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-OriginalArrivalTime: 12 Nov 2003 22:38:10.0926 (UTC) FILETIME=[A6AB00E0:01C3A96D]
Subject: Re: Review of draft-ietf-webdav-quota-02.txt
X-Archived-At: http://www.w3.org/mid/E803D4CF-1560-11D8-B9D2-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8110
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: <20031112223813.E80C7A05AD@frink.w3.org>
Resent-Date: Wed, 12 Nov 2003 17:38:13 -0500 (EST)
Content-Transfer-Encoding: 7bit


On Wednesday, November 12, 2003, at 10:08  AM, Julian Reschke wrote:
> We just reached agreement that physical disk limits should not be 
> treated as quota, right Brian?
>
> Julian

That's news to me.

-brian
briank@xythos.com



From w3c-dist-auth-request@w3.org  Wed Nov 12 17:53:46 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 RAA14355
	for ; Wed, 12 Nov 2003 17:53:45 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9697EA0A30; Wed, 12 Nov 2003 17:53: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 B715CA09C1
	for ; Wed, 12 Nov 2003 17:53:03 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id EB03613EEC; Wed, 12 Nov 2003 17:52:18 -0500 (EST)
Delivered-To: w3c-dist-auth@w3.org
Received: from mail.gmx.net (pop.gmx.net [213.165.64.20])
	by dr-nick.w3.org (Postfix) with SMTP id 76ADE13EEB
	for ; Wed, 12 Nov 2003 17:52:18 -0500 (EST)
Received: (qmail 5021 invoked by uid 65534); 12 Nov 2003 22:52:12 -0000
Received: from pD950C3AE.dip.t-dialin.net (EHLO gmx.de) (217.80.195.174)
  by mail.gmx.net (mp005) with SMTP; 12 Nov 2003 23:52:12 +0100
X-Authenticated: #1915285
Message-ID: <3FB2B998.1040400@gmx.de>
Date: Wed, 12 Nov 2003 23:52:08 +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: Brian Korver 
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: Review of draft-ietf-webdav-quota-02.txt
X-Archived-At: http://www.w3.org/mid/3FB2B998.1040400@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8111
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: <20031112225311.9697EA0A30@frink.w3.org>
Resent-Date: Wed, 12 Nov 2003 17:53:11 -0500 (EST)
Content-Transfer-Encoding: 7bit


Brian Korver wrote:

> On Wednesday, November 12, 2003, at 10:08  AM, Julian Reschke wrote:
> 
>> We just reached agreement that physical disk limits should not be 
>> treated as quota, right Brian?
>>
>> Julian
> 
> 
> That's news to me.

Hmm. Then there was a misunderstanding here...:

 >> 01-C03 quota vs disk space
 >> > 0439.html>
 >> > 0460.html>
 >>
 >> The spec says that servers may expose physical disk limits as quota.
 >>
 >> a) This is incompatible with NFS from which we're borrowing the
 >> semantics (it treats disk limits as a separate property, and so 
 >should
 >> we)
 >> b) Stefan raised interesting usability issue that weren't resolved so
 >> far
 >> (> 0456.html>).
 >
 >Perhaps you're still looking at an older version of the draft?
 >Addressing this issue was the biggest change between -01 and -02.


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Nov 12 18:30: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 SAA17106
	for ; Wed, 12 Nov 2003 18:30:19 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 33BD6A060D; Wed, 12 Nov 2003 18:30:31 -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 D0EB0A060D
	for ; Wed, 12 Nov 2003 18:30:27 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id BA99F136C5; Wed, 12 Nov 2003 18:30:27 -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 7416A13684
	for ; Wed, 12 Nov 2003 18:30:27 -0500 (EST)
Received: from xythos.com ([12.162.212.206]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 12 Nov 2003 15:30:26 -0800
Date: Wed, 12 Nov 2003 17:30:31 -0600
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: w3c-dist-auth@w3.org
To: Julian Reschke 
From: Brian Korver 
In-Reply-To: <3FB2B998.1040400@gmx.de>
Message-Id: <34BF7DEA-1568-11D8-B9D2-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-OriginalArrivalTime: 12 Nov 2003 23:30:26.0511 (UTC) FILETIME=[F39F4DF0:01C3A974]
Subject: Re: Review of draft-ietf-webdav-quota-02.txt
X-Archived-At: http://www.w3.org/mid/34BF7DEA-1568-11D8-B9D2-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8112
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: <20031112233031.33BD6A060D@frink.w3.org>
Resent-Date: Wed, 12 Nov 2003 18:30:31 -0500 (EST)
Content-Transfer-Encoding: 7bit


On Wednesday, November 12, 2003, at 04:52  PM, Julian Reschke wrote:
> Hmm. Then there was a misunderstanding here...:
>
> >> 01-C03 quota vs disk space
> >>  >> 0439.html>
> >>  >> 0460.html>
> >>
> >> The spec says that servers may expose physical disk limits as quota.
> >>
> >> a) This is incompatible with NFS from which we're borrowing the
> >> semantics (it treats disk limits as a separate property, and so 
> >should
> >> we)
> >> b) Stefan raised interesting usability issue that weren't resolved 
> so
> >> far
> >> ( >> 0456.html>).
> >
> >Perhaps you're still looking at an older version of the draft?
> >Addressing this issue was the biggest change between -01 and -02.

Julian,

The "issue" I was referring to was the one immediately above my comment.
In other words, (b) is not valid.

-brian
briank@xythos.com



From w3c-dist-auth-request@w3.org  Thu Nov 13 04:10:13 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 EAA17673
	for ; Thu, 13 Nov 2003 04:10:12 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 093E2A07EB; Thu, 13 Nov 2003 04:09:38 -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 D7FEEA0804
	for ; Thu, 13 Nov 2003 04:09:26 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 6D76913FB6; Thu, 13 Nov 2003 04:08:49 -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 ED37613FB3
	for ; Thu, 13 Nov 2003 04:08:48 -0500 (EST)
Received: (qmail 26440 invoked by uid 65534); 13 Nov 2003 09:08:48 -0000
Received: from p3EE2480E.dip.t-dialin.net (EHLO gmx.de) (62.226.72.14)
  by mail.gmx.net (mp027) with SMTP; 13 Nov 2003 10:08:48 +0100
X-Authenticated: #1915285
Message-ID: <3FB34A1E.9090600@gmx.de>
Date: Thu, 13 Nov 2003 10: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: Brian Korver 
Cc: w3c-dist-auth@w3.org
References: <34BF7DEA-1568-11D8-B9D2-000393751598@xythos.com>
In-Reply-To: <34BF7DEA-1568-11D8-B9D2-000393751598@xythos.com>
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/3FB34A1E.9090600@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8113
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: <20031113090938.093E2A07EB@frink.w3.org>
Resent-Date: Thu, 13 Nov 2003 04:09:38 -0500 (EST)
Content-Transfer-Encoding: 7bit


Brian Korver wrote:
> 
> On Wednesday, November 12, 2003, at 04:52  PM, Julian Reschke wrote:
> 
>> Hmm. Then there was a misunderstanding here...:
>>
>> >> 01-C03 quota vs disk space
>> >> > >> 0439.html>
>> >> > >> 0460.html>
>> >>
>> >> The spec says that servers may expose physical disk limits as quota.
>> >>
>> >> a) This is incompatible with NFS from which we're borrowing the
>> >> semantics (it treats disk limits as a separate property, and so 
>> >should
>> >> we)
>> >> b) Stefan raised interesting usability issue that weren't resolved so
>> >> far
>> >> (> >> 0456.html>).
>> >
>> >Perhaps you're still looking at an older version of the draft?
>> >Addressing this issue was the biggest change between -01 and -02.
> 
> 
> Julian,
> 
> The "issue" I was referring to was the one immediately above my comment.
> In other words, (b) is not valid.

Then please explain how the latest draft adresses the issue. Also 
explain why mixing physical disk limits and quota is ok, although it 
creates confusing behaviour *and* is incompatible with NFS.

Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Nov 13 09:32:17 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 JAA28374
	for ; Thu, 13 Nov 2003 09:32:17 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 78D7AA058A; Thu, 13 Nov 2003 09:32: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 65A36A058A
	for ; Thu, 13 Nov 2003 09:32:20 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 4BD1914003; Thu, 13 Nov 2003 09:32:20 -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 078EF1347F
	for ; Thu, 13 Nov 2003 09:32:20 -0500 (EST)
Received: from xythos.com ([12.162.212.206]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 13 Nov 2003 06:32:18 -0800
Date: Thu, 13 Nov 2003 08:32:26 -0600
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: w3c-dist-auth@w3.org
To: Julian Reschke 
From: Brian Korver 
In-Reply-To: <3FB34A1E.9090600@gmx.de>
Message-Id: <33B39A78-15E6-11D8-B01A-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-OriginalArrivalTime: 13 Nov 2003 14:32:18.0434 (UTC) FILETIME=[F0D77E20:01C3A9F2]
Subject: Re: Review of draft-ietf-webdav-quota-02.txt
X-Archived-At: http://www.w3.org/mid/33B39A78-15E6-11D8-B01A-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8114
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: <20031113143226.78D7AA058A@frink.w3.org>
Resent-Date: Thu, 13 Nov 2003 09:32:26 -0500 (EST)
Content-Transfer-Encoding: 7bit


On Thursday, November 13, 2003, at 03:08  AM, Julian Reschke wrote:
> Then please explain how the latest draft adresses the issue. Also 
> explain why mixing physical disk limits and quota is ok, although it 
> creates confusing behaviour *and* is incompatible with NFS.
>
> Julian

Simple, we went with NFS's model rather than quota-limit.  So, if it's
still confusing to you, then blame NFS.

I didn't realize that compatibility with NFS was one of WebDAV's
requirements.  ;-)

-brian
briank@xythos.com



From w3c-dist-auth-request@w3.org  Thu Nov 13 09:51:17 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 JAA29240
	for ; Thu, 13 Nov 2003 09:51:17 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2005DA0614; Thu, 13 Nov 2003 09:51: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 739C6A0614
	for ; Thu, 13 Nov 2003 09:51:18 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 39D67131DD; Thu, 13 Nov 2003 09:51:18 -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 B920214003
	for ; Thu, 13 Nov 2003 09:51:17 -0500 (EST)
Received: (qmail 6865 invoked by uid 65534); 13 Nov 2003 14:51:17 -0000
Received: from unknown (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp022) with SMTP; 13 Nov 2003 15:51:17 +0100
X-Authenticated: #1915285
Message-ID: <3FB39A63.5020907@gmx.de>
Date: Thu, 13 Nov 2003 15:51:15 +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: Brian Korver 
Cc: w3c-dist-auth@w3.org
References: <33B39A78-15E6-11D8-B01A-000393751598@xythos.com>
In-Reply-To: <33B39A78-15E6-11D8-B01A-000393751598@xythos.com>
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/3FB39A63.5020907@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8115
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: <20031113145124.2005DA0614@frink.w3.org>
Resent-Date: Thu, 13 Nov 2003 09:51:24 -0500 (EST)
Content-Transfer-Encoding: 7bit


Brian Korver wrote:

> 
> On Thursday, November 13, 2003, at 03:08  AM, Julian Reschke wrote:
> 
>> Then please explain how the latest draft adresses the issue. Also 
>> explain why mixing physical disk limits and quota is ok, although it 
>> creates confusing behaviour *and* is incompatible with NFS.
>>
>> Julian
> 
> 
> Simple, we went with NFS's model rather than quota-limit.  So, if it's
> still confusing to you, then blame NFS.
> 
> I didn't realize that compatibility with NFS was one of WebDAV's
> requirements.  ;-)

Brian,

as far as I can tell, there's nothing confusing with what NFS says. The 
confusion arises because the quote spec

- marshalls disk limits and quota using the same mechanism (contrary to 
NFS) and
- the quota spec introduces a new property for authoring quota.

Why doesn't the quota spec just *copy* the relevant parts of NFS (all we 
  need to is map four property names)?

Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Nov 13 13:44: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 NAA12262
	for ; Thu, 13 Nov 2003 13:44:36 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7927CA0AF8; Thu, 13 Nov 2003 13:44: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 8909AA0AF8
	for ; Thu, 13 Nov 2003 13:44:43 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 59EA913565; Thu, 13 Nov 2003 13:44:43 -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 1321713426
	for ; Thu, 13 Nov 2003 13:44:43 -0500 (EST)
Received: from xythos.com ([12.162.212.206]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 13 Nov 2003 10:44:41 -0800
Date: Thu, 13 Nov 2003 12:44:48 -0600
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: w3c-dist-auth@w3.org
To: Julian Reschke 
From: Brian Korver 
In-Reply-To: <3FB39A63.5020907@gmx.de>
Message-Id: <7549AD86-1609-11D8-B03D-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-OriginalArrivalTime: 13 Nov 2003 18:44:41.0937 (UTC) FILETIME=[3312AC10:01C3AA16]
Subject: Re: Review of draft-ietf-webdav-quota-02.txt
X-Archived-At: http://www.w3.org/mid/7549AD86-1609-11D8-B03D-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8116
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: <20031113184446.7927CA0AF8@frink.w3.org>
Resent-Date: Thu, 13 Nov 2003 13:44:46 -0500 (EST)
Content-Transfer-Encoding: 7bit


On Thursday, November 13, 2003, at 08:51  AM, Julian Reschke wrote:
> Brian Korver wrote:
>
>> On Thursday, November 13, 2003, at 03:08  AM, Julian Reschke wrote:
>>> Then please explain how the latest draft adresses the issue. Also 
>>> explain why mixing physical disk limits and quota is ok, although it 
>>> creates confusing behaviour *and* is incompatible with NFS.
>>>
>>> Julian
>> Simple, we went with NFS's model rather than quota-limit.  So, if it's
>> still confusing to you, then blame NFS.
>> I didn't realize that compatibility with NFS was one of WebDAV's
>> requirements.  ;-)
>
> Brian,
>
> as far as I can tell, there's nothing confusing with what NFS says. 
> The confusion arises because the quote spec
>
> - marshalls disk limits and quota using the same mechanism (contrary 
> to NFS) and
> - the quota spec introduces a new property for authoring quota.
>
> Why doesn't the quota spec just *copy* the relevant parts of NFS (all 
> we  need to is map four property names)?
>
> Julian

Julian,

The quota draft does differ from NFS, but that property alone
shouldn't mean that the quota draft is confusing.  Perhaps
you could state what you find confusing about the current
draft (and please, use the current draft, because this stuff
has changed).

-brian
briank@xythos.com



From w3c-dist-auth-request@w3.org  Thu Nov 13 14:14: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 OAA13535
	for ; Thu, 13 Nov 2003 14:14:23 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E8283A05F5; Thu, 13 Nov 2003 14:14:32 -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 D525FA05F5
	for ; Thu, 13 Nov 2003 14:14:29 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 6EE03140C5; Thu, 13 Nov 2003 14:14:29 -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 EFACB140C1
	for ; Thu, 13 Nov 2003 14:14:28 -0500 (EST)
Received: (qmail 8403 invoked by uid 65534); 13 Nov 2003 19:14:28 -0000
Received: from p3EE2482A.dip.t-dialin.net (EHLO gmx.de) (62.226.72.42)
  by mail.gmx.net (mp009) with SMTP; 13 Nov 2003 20:14:28 +0100
X-Authenticated: #1915285
Message-ID: <3FB3D80E.3020808@gmx.de>
Date: Thu, 13 Nov 2003 20:14:22 +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: Brian Korver 
Cc: w3c-dist-auth@w3.org
References: <7549AD86-1609-11D8-B03D-000393751598@xythos.com>
In-Reply-To: <7549AD86-1609-11D8-B03D-000393751598@xythos.com>
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/3FB3D80E.3020808@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8117
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: <20031113191432.E8283A05F5@frink.w3.org>
Resent-Date: Thu, 13 Nov 2003 14:14:32 -0500 (EST)
Content-Transfer-Encoding: 7bit


Brian Korver wrote:
> The quota draft does differ from NFS, but that property alone
> shouldn't mean that the quota draft is confusing.  Perhaps
> you could state what you find confusing about the current
> draft (and please, use the current draft, because this stuff
> has changed).

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



-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Nov 13 16:06: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 QAA20704
	for ; Thu, 13 Nov 2003 16:06:42 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 43080A05F5; Thu, 13 Nov 2003 16:06: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 34E5FA0B69
	for ; Thu, 13 Nov 2003 16:06:16 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 1494714001; Thu, 13 Nov 2003 16:06:07 -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 BFDDC13670
	for ; Thu, 13 Nov 2003 16:06:06 -0500 (EST)
Received: from xythos.com ([12.162.212.206]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 13 Nov 2003 13:06:05 -0800
Date: Thu, 13 Nov 2003 15:06:12 -0600
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: w3c-dist-auth@w3.org
To: Julian Reschke 
From: Brian Korver 
In-Reply-To: <3FB3D80E.3020808@gmx.de>
Message-Id: <35F86684-161D-11D8-B03D-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-OriginalArrivalTime: 13 Nov 2003 21:06:05.0684 (UTC) FILETIME=[F3C7BB40:01C3AA29]
Subject: Re: Review of draft-ietf-webdav-quota-02.txt
X-Archived-At: http://www.w3.org/mid/35F86684-161D-11D8-B03D-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8118
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: <20031113210649.43080A05F5@frink.w3.org>
Resent-Date: Thu, 13 Nov 2003 16:06:49 -0500 (EST)
Content-Transfer-Encoding: 7bit


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 Nov 13 16:35: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 QAA22007
	for ; Thu, 13 Nov 2003 16:35:55 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A289CA07A3; Thu, 13 Nov 2003 16:35: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 713B3A07A3
	for ; Thu, 13 Nov 2003 16:35:39 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 4A4201417C; Thu, 13 Nov 2003 16:35:39 -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 AA574139C6
	for ; Thu, 13 Nov 2003 16:35:38 -0500 (EST)
Received: (qmail 3298 invoked by uid 0); 13 Nov 2003 21:35:31 -0000
Received: from p3EE2482A.dip.t-dialin.net (EHLO gmx.de) (62.226.72.42)
  by mail.gmx.net (mp003) with SMTP; 13 Nov 2003 22:35:31 +0100
X-Authenticated: #1915285
Message-ID: <3FB3F907.5000004@gmx.de>
Date: Thu, 13 Nov 2003 22:35:03 +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: Brian Korver 
Cc: w3c-dist-auth@w3.org
References: <35F86684-161D-11D8-B03D-000393751598@xythos.com>
In-Reply-To: <35F86684-161D-11D8-B03D-000393751598@xythos.com>
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/3FB3F907.5000004@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8119
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: <20031113213544.A289CA07A3@frink.w3.org>
Resent-Date: Thu, 13 Nov 2003 16:35:44 -0500 (EST)
Content-Transfer-Encoding: 7bit


Brian Korver wrote:

> 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, you may be right -- I'll have to re-review the change.

I'M still not convinced that handling both quota and disk space limits 
using the same properties is a good idea, especially as NFS does it 
differently.

Minor editorial note: RFC3010 has been obsoleted by a newer revision.

Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Nov 13 17:33:19 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 RAA24956
	for ; Thu, 13 Nov 2003 17:33:19 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3A107A0534; Thu, 13 Nov 2003 17:33:30 -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 DE2B0A0534
	for ; Thu, 13 Nov 2003 17:33:24 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id C2F1E13603; Thu, 13 Nov 2003 17:33:24 -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 6FD1F135BA
	for ; Thu, 13 Nov 2003 17:33:24 -0500 (EST)
Received: (qmail 23112 invoked by uid 65534); 13 Nov 2003 22:33:16 -0000
Received: from p3EE2482A.dip.t-dialin.net (EHLO gmx.de) (62.226.72.42)
  by mail.gmx.net (mp013) with SMTP; 13 Nov 2003 23:33:16 +0100
X-Authenticated: #1915285
Message-ID: <3FB40692.8060900@gmx.de>
Date: Thu, 13 Nov 2003 23:32:50 +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: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: IETF WG meeting
X-Archived-At: http://www.w3.org/mid/3FB40692.8060900@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8120
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: <20031113223330.3A107A0534@frink.w3.org>
Resent-Date: Thu, 13 Nov 2003 17:33:30 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi.

The teleconference script is available from:



Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760




From w3c-dist-auth-request@w3.org  Fri Nov 14 05:28: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 FAA05071
	for ; Fri, 14 Nov 2003 05:28:08 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id ACDA0A089A; Fri, 14 Nov 2003 05:28:20 -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 A4B78A08DB
	for ; Fri, 14 Nov 2003 05:28:17 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 2A5A513A9A; Fri, 14 Nov 2003 05:28:17 -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 56AF413A60
	for ; Fri, 14 Nov 2003 05:28:16 -0500 (EST)
Received: from 192.168.1.49 ([192.168.1.23])
	(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 48-md50000000006.tmp
	for ; Fri, 14 Nov 2003 11:28:04 +0100
In-Reply-To: <35F86684-161D-11D8-B03D-000393751598@xythos.com>
References: <35F86684-161D-11D8-B03D-000393751598@xythos.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <1693B4A4-168D-11D8-A8E2-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org
From: Stefan Eissing 
Date: Fri, 14 Nov 2003 11:27:03 +0100
To: Brian Korver 
X-Mailer: Apple Mail (2.606)
X-Authenticated-Sender: se@greenbytes.de
X-Spam-Processed: greenbytes.de, Fri, 14 Nov 2003 11:28:04 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.23
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/1693B4A4-168D-11D8-A8E2-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8121
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: <20031114102820.ACDA0A089A@frink.w3.org>
Resent-Date: Fri, 14 Nov 2003 05:28:20 -0500 (EST)
Content-Transfer-Encoding: 7bit


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  Sun Nov 16 12:43:39 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 MAA02565
	for ; Sun, 16 Nov 2003 12:43:39 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 11487A08A5; Sun, 16 Nov 2003 12:43:17 -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 80B41A0823
	for ; Sun, 16 Nov 2003 12:43:11 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 04CB113A70; Sun, 16 Nov 2003 12:42:15 -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 84AAF139C1
	for ; Sun, 16 Nov 2003 12:42:14 -0500 (EST)
Received: (qmail 20414 invoked by uid 65534); 16 Nov 2003 17:42:11 -0000
Received: from p3EE2475A.dip.t-dialin.net (EHLO gmx.de) (62.226.71.90)
  by mail.gmx.net (mp013) with SMTP; 16 Nov 2003 18:42:11 +0100
X-Authenticated: #1915285
Message-ID: <3FB7B6D6.5020303@gmx.de>
Date: Sun, 16 Nov 2003 18:41: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: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: BIND spec status
X-Archived-At: http://www.w3.org/mid/3FB7B6D6.5020303@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8122
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: <20031116174317.11487A08A5@frink.w3.org>
Resent-Date: Sun, 16 Nov 2003 12:43:17 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

looking at...



...we have only one single issue that needs resolution. The latest edits 
  () already 
define the 208 status code, so I think what's left is to execute the 
changes we talked about in 
.

This would require the following changes:

a) import DAV request header definition from rfc2518bis (note that the 
definition in the latest draft probably needs some more work)

b) define a DAV compliance class for the BIND spec

c) clarify that 208 should only be returned when the client specifies 
compliance to the BIND spec in the PROPFIND request (otherwise fail the 
complete request).

The next step would then to submit a new draft (-03) and to issue the 
working group last-call.


Regards, Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760




From w3c-dist-auth-request@w3.org  Sun Nov 16 17:19: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 RAA09085
	for ; Sun, 16 Nov 2003 17:19:42 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9FE5DA0579; Sun, 16 Nov 2003 17:19:53 -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 88CDFA0579
	for ; Sun, 16 Nov 2003 17:19:50 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 1DF2D13578; Sun, 16 Nov 2003 17:19:50 -0500 (EST)
Delivered-To: w3c-dist-auth@w3.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id DD7FE13527
	for ; Sun, 16 Nov 2003 17:19:49 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1ALVF8-00005Y-00; Sun, 16 Nov 2003 22:19:42 +0000
Received: from [198.144.201.117] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1ALVF8-00005N-00; Sun, 16 Nov 2003 22:19:42 +0000
From: "Lisa Dusseault" 
To: 
Cc: 
Date: Sun, 16 Nov 2003 16:19:28 -0800
Message-ID: <001401c3aca0$76fc0ac0$75c990c6@lisalap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Old-X-Envelope-To: minutes@ietf.org,
 w3c-dist-auth@w3.org
Subject: WebDAV WG minutes
X-Archived-At: http://www.w3.org/mid/001401c3aca0$76fc0ac0$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8123
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: <20031116221953.9FE5DA0579@frink.w3.org>
Resent-Date: Sun, 16 Nov 2003 17:19:53 -0500 (EST)
Content-Transfer-Encoding: quoted-printable



Here are the minutes from the WebDAV WG meeting:

http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-iet=
f58.ppt=20





From w3c-dist-auth-request@w3.org  Sun Nov 16 17:26:34 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 RAA09254
	for ; Sun, 16 Nov 2003 17:26:33 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id DEC76A08B8; Sun, 16 Nov 2003 17:26: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 B0FE7A086F
	for ; Sun, 16 Nov 2003 17:26:12 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id B130E135BC; Sun, 16 Nov 2003 17:23:05 -0500 (EST)
Delivered-To: w3c-dist-auth@w3.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id 671B91358C
	for ; Sun, 16 Nov 2003 17:23:05 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1ALVIO-00006Z-00; Sun, 16 Nov 2003 22:23:04 +0000
Received: from [198.144.201.117] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1ALVIN-00006O-00; Sun, 16 Nov 2003 22:23:04 +0000
From: "Lisa Dusseault" 
To: "'Lisa Dusseault'" , 
Cc: 
Date: Sun, 16 Nov 2003 16:22:42 -0800
Message-ID: <001501c3aca0$ef1fa840$75c990c6@lisalap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Old-X-Envelope-To: lisa@xythos.com,
 minutes@ietf.org,
 w3c-dist-auth@w3.org
Subject: RE: WebDAV WG minutes
X-Archived-At: http://www.w3.org/mid/001501c3aca0$ef1fa840$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8124
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: <20031116222613.DEC76A08B8@frink.w3.org>
Resent-Date: Sun, 16 Nov 2003 17:26:13 -0500 (EST)
Content-Transfer-Encoding: quoted-printable


Sorry, that was incomplete - I hit send too soon.

Here are links to minutes:=20
http://www.sharemation.com/~milele/public/dav/minutes/ietf58-minutes.txt =


Here are links to the presentations:
http://www.sharemation.com/~milele/public/dav/presentations/webdav-quota-=
ietf58.ppt=20
http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-iet=
f58.ppt=20

Lisa

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]=20
> Sent: Sunday, November 16, 2003 4:19 PM
> To: 'minutes@ietf.org'
> Cc: 'w3c-dist-auth@w3.org'
> Subject: WebDAV WG minutes
>=20
>=20
>=20
> Here are the minutes from the WebDAV WG meeting:
>=20
> http://www.sharemation.com/~milele/public/dav/presentations/we
bdav-wg-ietf58.ppt=20





From w3c-dist-auth-request@w3.org  Mon Nov 17 04:27: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 EAA06249
	for ; Mon, 17 Nov 2003 04:27:01 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 477C3A0579; Mon, 17 Nov 2003 04:27:10 -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 90009A0579
	for ; Mon, 17 Nov 2003 04:27:03 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 156DB13773; Mon, 17 Nov 2003 04:27:03 -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 9F9AC13A00
	for ; Mon, 17 Nov 2003 04:27:02 -0500 (EST)
Received: (qmail 13062 invoked by uid 65534); 17 Nov 2003 09:27:01 -0000
Received: from p3EE24806.dip.t-dialin.net (HELO lisa) (62.226.72.6)
  by mail.gmx.net (mp016) with SMTP; 17 Nov 2003 10:27:01 +0100
X-Authenticated: #1915285
From: "Julian Reschke" 
To: 
Date: Mon, 17 Nov 2003 10:26:49 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Subject: RE: WebDAV WG minutes
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEKOIPAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8125
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: <20031117092710.477C3A0579@frink.w3.org>
Resent-Date: Mon, 17 Nov 2003 04:27:10 -0500 (EST)
Content-Transfer-Encoding: 7bit


Here's the content of the minutes document (for archival on the mailing
list):

--

Notes for WebDAV WG meeting at IETF 58.  Thanks to Larry Greenfield for
notes/chat transcript.

TOPIC: Agenda bashing
 - no objections

TOPIC: ACL status

 - Security ADs did not approve and did not block.
 - Now in the RFC editor queue.
 - major problem was the unbounded number of rights.
 - security ADs says nothing could be done to make this spec a good spec,
	but weren't willing to make the WG restart.
 - hopefully "application acl workshops" will be held.
 - for future revs, think about "intersection" instead of "union" solutions.

TOPIC: Quota/size properties

Brian Korver
 - draft to let things interoperate with quota implementations.
 - -02 document aligns better with NFS.
 - quota_avail added back in to deal with low disk space condition
 - the thought is that a MAY for including disk space is ok.
 - we could remove from spec and a future application can give disk limits.

Some additional questions on Quota
Q (Reschke): why are disk limits treated as quota when (a) NFS
behaves differently and (b) making a difference could enhance client error
handling (such as mapping to error codes in file system drivers)?
A: some memory that WG members had asked for disk limits to be treated as
	quota

Proposal: marshall as separate properties, define distinct
condition codes, so that clients can distinguish both conditions (just like
in
file systems)

Q: (Randy presuhn) Why do you need to know this number?
A: to not attempt operations that would almost assurdly fail.


Suggestion (Reschke): For instance, we may just define a generic mapping of
RFC3530 properies to DAV properties, then apply that mapping to the two
quota
and the two disk space properties defined there.


TOPIC: Redirect draft.

 - issue: Replace MKRESOURCE with MKREDIRECT?
 - issue: allow authoirng 301-type redirects as well as 302-type?
 - issue: How to handle requests that address mutliple resources, including
redirects
 - no comments from attendees.


TOPIC: Interop Report.

 - 4 clients, 6 servers. this is only about 30% of implementors.
 - possible to participate remotely
 - also ongoing interop testing using "always online" test servers
 - Jim Luther @ Apple is maintaing a list of public test accounts


TOPIC: RFC 2518bis issues

Do namespace prefix tags need to be preserved
 - issue is with XML vocabularies that use prefixes in text or attribute
content,
 - such as XSLT or XML Schema
 - "prefix rewriting") would break fragments of these vocabularies appearing
in properties
 -
Requirements for ETag support
 - question for ted: when going to draft standard, how hard do you try to
keep existing implementations compliant?
 - Ted: It's certainly possible that one or more implementations will become
uncompliant.
 - if it changes behavior, then usually you recycle at propose.
 - other things are big changes, too.
 - you can remove features but you cant change features or add features
without recycling at propose.
 - Ted: the standard level isn't a big deal, so don't worry about recycling
at proposed. make the spec as good as possible.

More commentary:
Suggestion (Reschke): It would be really good if some of the mod_dav
maintainers
could state whether they are planning to actually meet the stronger etag
requirements.

Q (OGeisser): are there any plans for "ptags" = "etags for properties"?
A (Lisa): Yes, or ctags = "ctags for collections": would rather not add
major new design to webdav, just make stronger compliance, simplify
features,
etc.  New features that would be added in new extensions is the thought
here.

(reschke): I certainly dislike the idea of having an RFC2518++ that isn't
supported by Apache.
(Ted): send the source to apache to fix the issue, and that's done.

Issue: Must resources be in collections
 - Consensus is that resources can be standalone.

Issue: Some interest in new writable modification-date property
 - for instance, a backup program could upload stuff to a server and set the
modification-date property from the original.
 - Jim Luther on the filesystem team here at Apple wanted this
property.
 - Changing getlastmodified considered dangerous
 - Note that setting DAV:getlastmodified *back* implies
changing the MIME header last-modified as well, and that may be a bad idea.
 - it could screw up things for intermediaries and caches, unless we
divorced the property value from the header value which might create more
confusion.
 - We may instead want to define a new property that can track modifications
to properties as well (that would resemble more closely a filesystems last
mod date)

TOPIC: PATCH proposal
http://www.sharemation.com/~milele/public/dav/draft-dusseault-http-patch-00.
txt

 - WebDAV use case: would make it easier to make small changes to very large
files.
 - DeltaV use case: small changes to many source files.
 - SIMPLE use case : changing my buddy list or presence document on HTTP
server.
 - Netconf use case: Making changes to large configuration documents.

Q (OGeisser) does the PATCH proposal allow a partial change of a property
value, too (sorry - have not read the proposal)
A: No

Suggestion (Reschke): an alternative would be to model parts of a resource
as indivually addressable sub-resources (with their own URIs)

TOPIC: BIND

Status is at 
Reschke: My understanding is that we want to last-call the spec when the
open issue is resolved.
Lisa has other issues which she will raise on list.



From w3c-dist-auth-request@w3.org  Mon Nov 17 15:23: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 PAA03352
	for ; Mon, 17 Nov 2003 15:23:47 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id AB022A0837; Mon, 17 Nov 2003 15:23:30 -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 A4DFDA0837
	for ; Mon, 17 Nov 2003 15:23:27 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 32CA61372F; Mon, 17 Nov 2003 15:23:27 -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 DBD77136CB
	for ; Mon, 17 Nov 2003 15:23:26 -0500 (EST)
Received: from xythos.com ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 17 Nov 2003 12:23:26 -0800
Date: Mon, 17 Nov 2003 14:23:30 -0600
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: w3c-dist-auth@w3.org
To: Stefan Eissing 
From: Brian Korver 
In-Reply-To: <1693B4A4-168D-11D8-A8E2-00039384827E@greenbytes.de>
Message-Id: 
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-OriginalArrivalTime: 17 Nov 2003 20:23:26.0314 (UTC) FILETIME=[A7EDDCA0:01C3AD48]
Subject: Re: Review of draft-ietf-webdav-quota-02.txt
X-Archived-At: http://www.w3.org/mid/E8A03FF4-193B-11D8-81A9-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8126
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: <20031117202330.AB022A0837@frink.w3.org>
Resent-Date: Mon, 17 Nov 2003 15:23:30 -0500 (EST)
Content-Transfer-Encoding: 7bit


On Friday, November 14, 2003, at 04: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).

I agree on both counts.  Any help on making the example less confusing
would be appreciated.


>
> 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.

I'm not sure that I understand what you're saying.  On BSD, for 
instance,
quota is specified per-filesystem.  Therefore, if I've got the 
following mount
points and quota specified:

     /home/briank/           # my home directory, quota 1GB
     /home/briank/mp3s       # quota 100GB
     /home/briank/video      # quota 50GB
     /home/briank/small      # quota .25GB

So here, the 'set' is a filesystem.


>
> 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)?

I presume the server would just not return DAV:quota-assigned-bytes
if it isn't set.  Hmm, that should be stated in the document.  Will fix.


>
> 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?

The generic client should allow the user to change quota wherever
it can be.  It is up to the user to understand the quota model.
I don't know what else can be done.

-brian
briank@xythos.com



From w3c-dist-auth-request@w3.org  Tue Nov 18 14:45: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 OAA09555
	for ; Tue, 18 Nov 2003 14:45:06 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A2E24A0AE5; Tue, 18 Nov 2003 14:43: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 65177A0AC2
	for ; Tue, 18 Nov 2003 14:43:50 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id D350713E02; Tue, 18 Nov 2003 14:41:44 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id 8EE8113E01
	for ; Tue, 18 Nov 2003 14:41:44 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AMBjL-0000mc-00; Tue, 18 Nov 2003 19:41:43 +0000
Received: from [64.202.9.194] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AMBjK-0000mR-00; Tue, 18 Nov 2003 19:41:43 +0000
From: "Lisa Dusseault" 
To: "'Geoffrey M Clemm'" ,
        "'Julian Reschke'" 
Cc: "'Wallmer, Martin'" ,
        "'Webdav WG'" 
Date: Tue, 18 Nov 2003 11:41:27 -0800
Message-ID: <01c001c3ae0b$f4ebe740$75c990c6@lisalap>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01C1_01C3ADC8.E6C8A740"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: 
Importance: Normal
Old-X-Envelope-To: geoffrey.clemm@us.ibm.com,
 julian.reschke@gmx.de,
 Martin.Wallmer@softwareag.com,
 w3c-dist-auth@w3c.org
Subject: Bind issues 
X-Archived-At: http://www.w3.org/mid/01c001c3ae0b$f4ebe740$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8127
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: <20031118194354.A2E24A0AE5@frink.w3.org>
Resent-Date: Tue, 18 Nov 2003 14:43:54 -0500 (EST)


This is a multi-part message in MIME format.

------=_NextPart_000_01C1_01C3ADC8.E6C8A740
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On 8/4/2003, I asked about PROPFIND results in presence of bindings.  I
don't know that
that has been clarified.
=20
On 3/8/2003, I proposed language for clearer requirements on DELETE
behavior. This applies to MOVE too.  The discussion started earlier,
3/4/2003 or before.
=20
I believe I asked for more lock requirements -- what the server MUST do =
when
a client locks a binding.  I haven't found that email yet.
=20
It's quite possible that the bind authors believe they've already dealt =
with
these issues.  If so, I'm unaware of the resolutions.
=20
Lisa
=20
=20

-----Original Message-----
From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com]=20
Sent: Tuesday, November 18, 2003 5:29 AM
To: Julian Reschke
Cc: Lisa Dusseault; 'Wallmer, Martin'; www-webdav-dasl@w3.org
Subject: Re: "URI properties", Was: SEARCH for displayname



Like Julian, I have no memory of Lisa raising this issue on=20
the mailing list (at least, not since the activity on the BIND=20
protocol was resumed a year ago). A pointer to that email would be
appreciated,=20
since both Julian and I work very hard to maintain accurate issue=20
lists and to make sure that all issues that are raised on the mailing=20
list are addressed.  There was a discussion in the design team 4 or=20
5 years ago, about whether the spec should leave the question of where=20
the state of a binding resides up to the server (i.e. is it in the=20
parent collection, the child resource, or both), and the consensus=20
was that effective interoperability required us to specify where=20
this resides, so that access control and locking behavior could be=20
defined (i.e. was the removal/addition of a binding controlled by=20
a lock/acl on the parent collection, on the child resource, or both).=20
The choice of the parent collection was motivated by the use case=20
of two bindings to the same resource in a single collection, and by=20
the use case of different collections needing to give different names=20
to a single resource.=20

Cheers,=20
Geoff=20


Julian Reschke  wrote on 11/12/2003 11:00:00 AM:

> Lisa Dusseault wrote:
>=20
> > I do plan to raise these issues more generally for bind.  However, I =

> > have also raised them in the past and they do not show up on your =
list.
>=20
> Well, the please re-raise them with a pointer to the original mail on=20
> the mailing list.
>=20
> > Sorry if my replies are brief to the point of bluntness; I'm trying=20
> > to do a bunch of IETF coordination and cross-group work this week =
and
> > attend other WG meetings at the same time.  I will try to understand
> > the context in which you're saying how things are and must behave.
>=20
> Good.
>=20
> > In return, please respect that I am challenging the model =
assumptions
> > I see developing here and in bind discussions.  I hope it's not too
> > late for us to have open minds about how things are defined.
>=20
> The model for BIND has been developed in 1999 and has never changed =
since.
>=20
> Julian
>=20
> --=20
> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>=20



------=_NextPart_000_01C1_01C3ADC8.E6C8A740
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




Message




On=20
8/4/2003, I asked about PROPFIND results in presence of bindings.  =
I don't=20
know that


that=20
has been clarified.


 


On=20
3/8/2003, I proposed language for clearer requirements on DELETE =
behavior. This=20
applies to MOVE too.  The discussion started earlier, 3/4/2003 or=20
before.


 


I=20
believe I asked for more lock requirements -- what the server MUST do =
when a=20
client locks a binding.  I haven't found that email=20
yet.


 


It's=20
quite possible that the bind authors believe they've already dealt with =
these=20
issues.  If so, I'm unaware of the resolutions.


 


Lisa


 


 


  

  
-----Original Message-----
From: =
Geoffrey M Clemm=20
  [mailto:geoffrey.clemm@us.ibm.com] 
Sent: Tuesday, November =
18, 2003=20
  5:29 AM
To: Julian Reschke
Cc: Lisa Dusseault; =
'Wallmer,=20
  Martin'; www-webdav-dasl@w3.org
Subject: Re: "URI =
properties", Was:=20
  SEARCH for displayname


Like =
Julian, I=20
  have no memory of Lisa raising this issue on 
the mailing list (at least, not since the activity on the =

  BIND 
protocol was resumed a year =
ago). A=20
  pointer to that email would be appreciated, 
since both Julian and I work very hard to maintain =
accurate=20
  issue 
lists and to make sure that =
all issues=20
  that are raised on the mailing 
list =
are=20
  addressed.  There was a discussion in the design team 4 =
or=20
  
5 years ago, about whether the spec should =
leave the=20
  question of where 
the state of a =
binding=20
  resides up to the server (i.e. is it in the 
parent collection, the child resource, or both), and the=20
  consensus 
was that effective =
interoperability=20
  required us to specify where 
this =
resides, so=20
  that access control and locking behavior could be =

defined (i.e. was the removal/addition of a binding =
controlled=20
  by 
a lock/acl on the parent =
collection, on=20
  the child resource, or both). 
The =
choice of=20
  the parent collection was motivated by the use case =

of two bindings to the same resource in a single =
collection, and=20
  by 
the use case of different =
collections=20
  needing to give different names 
to =
a single=20
  resource. 

Cheers, =

Geoff 


Julian =
Reschke=20
  <julian.reschke@gmx.de> wrote on 11/12/2003 11:00:00 =
AM:

>=20
  Lisa Dusseault wrote:
> 
> > I do plan to raise these =
issues=20
  more generally for bind.  However, I 
> > have also =
raised them=20
  in the past and they do not show up on your list.
> 
> =
Well, the=20
  please re-raise them with a pointer to the original mail on 
> =
the=20
  mailing list.
> 
> > Sorry if my replies are brief to =
the point=20
  of bluntness; I'm trying 
> > to do a bunch of IETF =
coordination and=20
  cross-group work this week and
> > attend other WG meetings =
at the=20
  same time.  I will try to understand
> > the context in =
which=20
  you're saying how things are and must behave.
> 
> =
Good.
>=20
  
> > In return, please respect that I am challenging the =
model=20
  assumptions
> > I see developing here and in bind =
discussions.=20
   I hope it's not too
> > late for us to have open minds =
about=20
  how things are defined.
> 
> The model for BIND has been =
developed=20
  in 1999 and has never changed since.
> 
> Julian
> =

>=20
  -- 
> <green/>bytes GmbH -- http://www.greenbytes.de --=20
  tel:+492512807760
> 


------=_NextPart_000_01C1_01C3ADC8.E6C8A740--




From w3c-dist-auth-request@w3.org  Tue Nov 18 15:10:24 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11614
	for ; Tue, 18 Nov 2003 15:10:24 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D0B0CA0522; Tue, 18 Nov 2003 15:10: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 32719A0522
	for ; Tue, 18 Nov 2003 15:10:30 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id CB1EC1394C; Tue, 18 Nov 2003 15:10:29 -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 8600D134B4
	for ; Tue, 18 Nov 2003 15:10:29 -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 PAA11605;
	Tue, 18 Nov 2003 15:10:17 -0500 (EST)
Message-Id: <200311182010.PAA11605@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: Tue, 18 Nov 2003 15:10:17 -0500
Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-07.txt
X-Archived-At: http://www.w3.org/mid/200311182010.PAA11605@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8128
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: <20031118201033.D0B0CA0522@frink.w3.org>
Resent-Date: Tue, 18 Nov 2003 15:10:33 -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		: WebDAV Redirect Reference Resources
	Author(s)	: J. Slein
	Filename	: draft-ietf-webdav-redirectref-protocol-07.txt
	Pages		: 55
	Date		: 2003-11-18
	
This specification defines redirect reference resources.  A redirect
reference resource is a resource whose default response is an HTTP/
1.1 302 (Found) status code, redirecting the client to a different
resource, the target resource.  A redirect reference makes it
possible to access the target resource indirectly, through any URI
mapped to the redirect reference resource.  There are no integrity
guarantees associated with redirect reference resources.
Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WebDAV) working group at
w3c-dist-auth@w3.org [1], which may be joined by sending a message
with subject 'subscribe' to w3c-dist-auth-request@w3.org [2].
Discussions of the WEBDAV working group are archived at URL: http://
lists.w3.org/Archives/Public/w3c-dist-auth/.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-07.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-redirectref-protocol-07.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-redirectref-protocol-07.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-11-18124435.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-webdav-redirectref-protocol-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-11-18124435.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Tue Nov 18 15:18: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 PAA12576
	for ; Tue, 18 Nov 2003 15:18:41 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A4453A0C10; Tue, 18 Nov 2003 15:18:43 -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 D26E0A0706
	for ; Tue, 18 Nov 2003 15:18:29 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 632D513E8C; Tue, 18 Nov 2003 15:13:07 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by dr-nick.w3.org (Postfix) with SMTP id EB90C13E81
	for ; Tue, 18 Nov 2003 15:13:06 -0500 (EST)
Received: (qmail 25863 invoked by uid 65534); 18 Nov 2003 20:13:01 -0000
Received: from p3EE2473A.dip.t-dialin.net (EHLO gmx.de) (62.226.71.58)
  by mail.gmx.net (mp005) with SMTP; 18 Nov 2003 21:13:01 +0100
X-Authenticated: #1915285
Message-ID: <3FBA7D33.1040608@gmx.de>
Date: Tue, 18 Nov 2003 21:12:35 +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: "'Geoffrey M Clemm'" ,
        "'Wallmer, Martin'" ,
        "'Webdav WG'" 
References: <01c001c3ae0b$f4ebe740$75c990c6@lisalap>
In-Reply-To: <01c001c3ae0b$f4ebe740$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/3FBA7D33.1040608@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8129
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: <20031118201843.A4453A0C10@frink.w3.org>
Resent-Date: Tue, 18 Nov 2003 15:18:43 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> On 8/4/2003, I asked about PROPFIND results in presence of bindings.  I 
> don't know that
> that has been clarified.

I think this is the open issue that I mentioned. The proposal that I 
made two days ago 
() 
should take care of the issue you raised.

> On 3/8/2003, I proposed language for clearer requirements on DELETE 
> behavior. This applies to MOVE too.  The discussion started earlier, 
> 3/4/2003 or before.

In draft 02, BIND was rewritten to have both DELETE and UNBIND. As far 
as I can tell this took care of the issues from those who felt 
uncomfortable requiring DELETE to be atomic (this included myself). In 
the current spec, a server can implement DELETE non-atomic.

> I believe I asked for more lock requirements -- what the server MUST do 
> when a client locks a binding.  I haven't found that email yet.

Interaction between locks and multiple bindings is defined in GULP, and 
as far as I can tell, the only missing thing is to integrate it into 
RFC2518bis, just like discussed many times (both on the interim WG 
meeting in January and the mailing list).

> It's quite possible that the bind authors believe they've already dealt 
> with these issues.  If so, I'm unaware of the resolutions.

To summarize:

1) is open (it's the only open issue, and we're just trying to resolve it),

2) DELETE changed in draft 02, so please re-check,

3) there was agreement to do this in RFC2518bis -- if you think there 
are issues left with the latest GULP version, please describe those.

Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov 18 15:38:21 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 PAA14253
	for ; Tue, 18 Nov 2003 15:38:20 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5A200A0547; Tue, 18 Nov 2003 15:38:31 -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 70EE7A0547
	for ; Tue, 18 Nov 2003 15:38:26 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 4CB8E13430; Tue, 18 Nov 2003 15:38:26 -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 CB33F13380
	for ; Tue, 18 Nov 2003 15:38:25 -0500 (EST)
Received: (qmail 17275 invoked by uid 65534); 18 Nov 2003 20:38:23 -0000
Received: from p3EE2473A.dip.t-dialin.net (EHLO gmx.de) (62.226.71.58)
  by mail.gmx.net (mp016) with SMTP; 18 Nov 2003 21:38:23 +0100
X-Authenticated: #1915285
Message-ID: <3FBA8332.4010508@gmx.de>
Date: Tue, 18 Nov 2003 21:38: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: w3c-dist-auth@w3.org
References: <200311182010.PAA11605@ietf.org>
In-Reply-To: <200311182010.PAA11605@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION:draft-ietf-webdav-redirectref-protocol-07.txt
X-Archived-At: http://www.w3.org/mid/3FBA8332.4010508@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8130
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: <20031118203831.5A200A0547@frink.w3.org>
Resent-Date: Tue, 18 Nov 2003 15:38:31 -0500 (EST)
Content-Transfer-Encoding: 7bit


Internet-Drafts@ietf.org wrote:

> 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.
> ...

Changes are summarized here...:



Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov 18 16:34: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 QAA18911
	for ; Tue, 18 Nov 2003 16:34:13 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C3321A051A; Tue, 18 Nov 2003 16:34: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 011BEA051A
	for ; Tue, 18 Nov 2003 16:34:18 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id D76DE134E5; Tue, 18 Nov 2003 16:34:18 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id A64F0134C8
	for ; Tue, 18 Nov 2003 16:34:18 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AMDUH-00023r-00; Tue, 18 Nov 2003 21:34:17 +0000
Received: from [64.202.9.194] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AMDUH-00023g-00; Tue, 18 Nov 2003 21:34:17 +0000
From: "Lisa Dusseault" 
To: "'Julian Reschke'" 
Cc: "'Webdav WG'" 
Date: Tue, 18 Nov 2003 13:33:58 -0800
Message-ID: <002c01c3ae1b$aee21cf0$75c990c6@lisalap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <3FBA8C66.9080405@gmx.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: Bindings and GULP again 
X-Archived-At: http://www.w3.org/mid/002c01c3ae1b$aee21cf0$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8131
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: <20031118213422.C3321A051A@frink.w3.org>
Resent-Date: Tue, 18 Nov 2003 16:34:22 -0500 (EST)
Content-Transfer-Encoding: quoted-printable



I've reviewed the text of GULP before, and asked what part of
it wasn't sufficiently covered by the language in RFC2518bis.
I believe I've already incorporated most of pre-5.4 GULP (that part =
which
didn't assume bindings) into RFC2518bis.  That said, here's the text
you point to:

  "A lock either directly or indirectly locks a resource."

  "A LOCK request creates a new lock, and the resource identified
  by the request-URL is directly locked by that lock.  The
  "lock-root" of the new lock is the request-URL. If at the time of
  the request, the request-URL is not mapped to a resource, a new
  resource with no content MUST be created by the request."

Well, a LOCK doesn't always create a new lock.

  "If a collection is directly locked by a depth:infinity lock, all
  members of that collection (other than the collection itself) are
  indirectly locked by that lock.  In particular, if an internal
  member resource is added to a collection that is locked by a
  depth:infinity lock, and if the resource is not locked by that lock,
  then the resource becomes indirectly locked by that lock.
  Conversely, if a resource is indirectly locked with a depth:infinity
  lock, and if the result of deleting an internal member URI is that
  the resource is no longer a member of the collection that is
  directly locked by that lock, then the resource is no longer locked
  by that lock."

The phrase "and if the resource is not locked by that lock" confuses
this paragraph.  I believe it can be removed.  It's also not clear
in this para. if "members of" is recursive.  "descendants" is the
word I've used to make it clear when we're talking about all members
recursively, not just direct children.

  "An UNLOCK request deletes the lock with the specified lock token.
  The request-URL of the request MUST identify a resource that
  is either directly or indirectly locked by that lock.
  After a lock is deleted, no resource is locked by that lock."

In RFC2518bis, UNLOCK MUST be to a directly-locked URL.

  "A lock token is "submitted" in a request when it appears in an If
  header tagged-list whose tag is the lock-root of the lock, or when
  it appears in an untagged list and the request-URL is the lock-root
  of the lock."

In RFC2518bis, a lock token is submitted if it appears anywhere
in the if header, I think.

  "If a request would modify the content for a locked resource, a dead
  property of a locked resource, a live property that is defined to be
  lockable for a locked resource, or an internal member URI of a
  locked collection, the request MUST fail unless the lock-token for
  that lock is submitted in the request.  An internal member URI
  of a collection is considered to be modified if it is added,
  removed, or identifies a different resource."

  "If a request causes a directly locked resource to no longer be
  mapped to the lock-root of that lock, then the request MUST
  fail unless the lock-token for that lock is submitted in the
  request.  If the request succeeds, then that lock MUST have been
  deleted by that request."

  "If a request would cause a resource to be locked by two different
  exclusive locks, the request MUST fail."

Finally, this stuff doesn't address what happens to the other=20
bindings of a locked resource - if they now appear as locked,=20
which I would assume.  This needs to be made clear in bindings,
not RFC2518bis.

Lisa

> -----Original Message-----
> From: www-webdav-dasl-request@w3.org=20
> [mailto:www-webdav-dasl-request@w3.org] On Behalf Of Julian Reschke
> Sent: Tuesday, November 18, 2003 1:17 PM
> To: Lisa Dusseault
> Cc: 'Wallmer, Martin'; 'Kevin Wiggen'; www-webdav-dasl@w3.org
> Subject: Re: SEARCH by last path segment, Was: SEARCH for displayname
>=20
>=20
>=20
> Lisa Dusseault wrote:
>=20
> >=20
> >>>Why have an architectural principle that holds us back, if
> >>
> >>it doesn't
> >>
> >>>give us something in return?
> >>
> >>It does. For instance, it allows us to define how locks and multiple
> >>bindings interact in a logical way.
> >=20
> >=20
> > This is exactly what I'm looking to understand, that I=20
> don't currently=20
> > understand.  In fact, I thought that the interaction of locks and=20
> > multiple bindings was problematic.  So how does this make them work=20
> > together in a logical way?
>=20
> Looking at the latest GULP=20
> (),=20
it nicely explains how locks work without even mentioning them =
specifically.

Maybe you could re-read it and suggest what is unclear?

Regards, Julian

--=20
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760





From w3c-dist-auth-request@w3.org  Tue Nov 18 20:01:39 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 UAA29133
	for ; Tue, 18 Nov 2003 20:01:38 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D3744A0AA5; Tue, 18 Nov 2003 20:01:38 -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 1A3FCA051A
	for ; Tue, 18 Nov 2003 20:01:34 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id C1B9F13DC5; Tue, 18 Nov 2003 20:01:33 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by dr-nick.w3.org (Postfix) with SMTP id 5487213DB2
	for ; Tue, 18 Nov 2003 20:01:33 -0500 (EST)
Received: (qmail 13497 invoked by uid 65534); 19 Nov 2003 01:01:25 -0000
Received: from p3EE2473A.dip.t-dialin.net (EHLO gmx.de) (62.226.71.58)
  by mail.gmx.net (mp004) with SMTP; 19 Nov 2003 02:01:25 +0100
X-Authenticated: #1915285
Message-ID: <3FBAC0C0.7040509@gmx.de>
Date: Wed, 19 Nov 2003 02:00:48 +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: <002c01c3ae1b$aee21cf0$75c990c6@lisalap>
In-Reply-To: <002c01c3ae1b$aee21cf0$75c990c6@lisalap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Bindings and GULP again
X-Archived-At: http://www.w3.org/mid/3FBAC0C0.7040509@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8132
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: <20031119010138.D3744A0AA5@frink.w3.org>
Resent-Date: Tue, 18 Nov 2003 20:01:38 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I've reviewed the text of GULP before, and asked what part of
> it wasn't sufficiently covered by the language in RFC2518bis.

Well, the agreed upon plan was to actually add GULP to RFC2518bis once 
we've come up with a final version. At least that's the plan I remember.

> I believe I've already incorporated most of pre-5.4 GULP (that part which

GULP never "assumed" bindings. It was just using the term "binding". We 
have replaced it by "internal member", because in this context the terms 
are exchangeable.

> didn't assume bindings) into RFC2518bis.  That said, here's the text
> you point to:
> 
>   "A lock either directly or indirectly locks a resource."
> 
>   "A LOCK request creates a new lock, and the resource identified
>   by the request-URL is directly locked by that lock.  The
>   "lock-root" of the new lock is the request-URL. If at the time of
>   the request, the request-URL is not mapped to a resource, a new
>   resource with no content MUST be created by the request."
> 
> Well, a LOCK doesn't always create a new lock.

It does, unless this is a LOCK refresh. Ok.

>   "If a collection is directly locked by a depth:infinity lock, all
>   members of that collection (other than the collection itself) are
>   indirectly locked by that lock.  In particular, if an internal
>   member resource is added to a collection that is locked by a
>   depth:infinity lock, and if the resource is not locked by that lock,
>   then the resource becomes indirectly locked by that lock.
>   Conversely, if a resource is indirectly locked with a depth:infinity
>   lock, and if the result of deleting an internal member URI is that
>   the resource is no longer a member of the collection that is
>   directly locked by that lock, then the resource is no longer locked
>   by that lock."
> 
> The phrase "and if the resource is not locked by that lock" confuses
> this paragraph.  I believe it can be removed.  It's also not clear

No, it's required, because only if the resource is not already directly 
locked by that lock, it becomes *indirectly* locked.

> in this para. if "members of" is recursive.  "descendants" is the
> word I've used to make it clear when we're talking about all members
> recursively, not just direct children.

"members" and "internal members" is terminilogy defined in RFC2518, 
section 3.

>   "An UNLOCK request deletes the lock with the specified lock token.
>   The request-URL of the request MUST identify a resource that
>   is either directly or indirectly locked by that lock.
>   After a lock is deleted, no resource is locked by that lock."
> 
> In RFC2518bis, UNLOCK MUST be to a directly-locked URL.

OK.

>   "A lock token is "submitted" in a request when it appears in an If
>   header tagged-list whose tag is the lock-root of the lock, or when
>   it appears in an untagged list and the request-URL is the lock-root
>   of the lock."
> 
> In RFC2518bis, a lock token is submitted if it appears anywhere
> in the if header, I think.

Speaking of which I don't think that we ever agreed on making this change.

>   "If a request would modify the content for a locked resource, a dead
>   property of a locked resource, a live property that is defined to be
>   lockable for a locked resource, or an internal member URI of a
>   locked collection, the request MUST fail unless the lock-token for
>   that lock is submitted in the request.  An internal member URI
>   of a collection is considered to be modified if it is added,
>   removed, or identifies a different resource."
> 
>   "If a request causes a directly locked resource to no longer be
>   mapped to the lock-root of that lock, then the request MUST
>   fail unless the lock-token for that lock is submitted in the
>   request.  If the request succeeds, then that lock MUST have been
>   deleted by that request."
> 
>   "If a request would cause a resource to be locked by two different
>   exclusive locks, the request MUST fail."
> 
> Finally, this stuff doesn't address what happens to the other 
> bindings of a locked resource - if they now appear as locked, 
> which I would assume.  This needs to be made clear in bindings,
> not RFC2518bis.

1) No, the other URIs mapped to that resource are *not* affected. It's 
the *resource* that is locked.

2) And no (we discussed this before), this should be defined in 
RFC2518bis as both HTTP and WebDAV already allow multiple URIs being 
mapped to the same resource. All the BIND spec does is clarifying 
behaviour that was defined in RFC2518bis and added specific methods for 
explicitly creating those additional URI mappings.


Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov 18 21:53:39 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 VAA02819
	for ; Tue, 18 Nov 2003 21:53:39 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B1F0DA0810; Tue, 18 Nov 2003 21:53:50 -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 77BD9A0810
	for ; Tue, 18 Nov 2003 21:53:47 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 37D6013477; Tue, 18 Nov 2003 21:53:47 -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 19A2113421
	for ; Tue, 18 Nov 2003 21:53:47 -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 hAJ2rlhn761008
	for ; Tue, 18 Nov 2003 21:53: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 hAJ2rjJq232950
	for ; Tue, 18 Nov 2003 21:53:46 -0500
In-Reply-To: <60691A7A-1554-11D8-9F2A-000393753936@apache.org>
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, 18 Nov 2003 18:53:32 -0800
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF106 | October 27, 2003) at
 11/18/2003 21:53:35,
	Serialize complete at 11/18/2003 21:53:35
Content-Type: multipart/alternative; boundary="=_alternative 000FE46D88256DE3_="
Subject: Re: remaining redirect ref issues
X-Archived-At: http://www.w3.org/mid/OF9518EDF7.49E1F092-ON88256DE3.000EA437-88256DE3.000FE470@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8133
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: <20031119025350.B1F0DA0810@frink.w3.org>
Resent-Date: Tue, 18 Nov 2003 21:53:50 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 000FE46D88256DE3_=
Content-Type: text/plain; charset="US-ASCII"

In principle, I agree with Roy on this issue.

But a problem with the "authoring URI" approach occurs when you want to
apply a Depth operation (e.g. PROPFIND).  You can get all the authoring
URIs with a single Depth PROPFIND, but then how do you avoid having to
apply the operation separately to each of the authoring URIs?

In the case of PROPFIND, there is a solution provided by RFC-3253
(the DAV:expand-property REPORT), but that only works for PROPFIND,
not for other Depth methods like COPY.

Cheers,
Geoff 

Roy wrote on 11/12/2003 01:08:34 PM:

> I am certain I have said this before, though it was several years ago.
> The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure to get 
> straight
> on that one bit is what causes webdav to trip over HTTP whenever it
> tries to "author" anything other than a boring old file.
> 
> In this case, there must be two different URIs -- one for the resource
> and one for the configuration of that resource.  That configuration
> may be as simple as a URI, maybe a status code and a URI, or maybe even
> an XML document -- that is what must be defined by the redirect 
> protocol.
> The actual URI which responds to requests with a redirect should have a
> link to its configuration URI, such that an authoring tool can discover
> the authorable resource that causes this resource to redirect.  That is
> why webdav requires a source link in order to perform HTTP authoring.
> 
> The same principle holds for all dynamic content.
> 
> ....Roy
> 

--=_alternative 000FE46D88256DE3_=
Content-Type: text/html; charset="US-ASCII"



In principle, I agree with Roy on this issue.



But a problem with the "authoring URI" approach
occurs when you want to

apply a Depth operation (e.g. PROPFIND).  You
can get all the authoring

URIs with a single Depth PROPFIND, but then how do
you avoid having to

apply the operation separately to each of the authoring
URIs?



In the case of PROPFIND, there is a solution provided
by RFC-3253

(the DAV:expand-property REPORT), but that only works
for PROPFIND,

not for other Depth methods like COPY.



Cheers,

Geoff 



Roy wrote on 11/12/2003 01:08:34 PM:



> I am certain I have said this before, though it was several years
ago.

> The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure to
get 

> straight

> on that one bit is what causes webdav to trip over HTTP whenever it

> tries to "author" anything other than a boring old file.

> 

> In this case, there must be two different URIs -- one for the resource

> and one for the configuration of that resource.  That configuration

> may be as simple as a URI, maybe a status code and a URI, or maybe
even

> an XML document -- that is what must be defined by the redirect 

> protocol.

> The actual URI which responds to requests with a redirect should have
a

> link to its configuration URI, such that an authoring tool can discover

> the authorable resource that causes this resource to redirect.  That
is

> why webdav requires a source link in order to perform HTTP authoring.

> 

> The same principle holds for all dynamic content.

> 

> ....Roy

> 


--=_alternative 000FE46D88256DE3_=--



From w3c-dist-auth-request@w3.org  Wed Nov 19 06:35:51 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 GAA13170
	for ; Wed, 19 Nov 2003 06:35:51 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 15033A0A7F; Wed, 19 Nov 2003 06:35: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 37A18A0AE5
	for ; Wed, 19 Nov 2003 06:35:31 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 12BCC13F1B; Wed, 19 Nov 2003 06:34:08 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from greenbytes.de (unknown [217.5.201.10])
	by dr-nick.w3.org (Postfix) with ESMTP id 561EA138F2
	for ; Wed, 19 Nov 2003 06:34:07 -0500 (EST)
Received: from 192.168.1.49 ([192.168.1.23])
	(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 24-md50000000020.tmp
	for ; Wed, 19 Nov 2003 12:33:10 +0100
In-Reply-To: <002c01c3ae1b$aee21cf0$75c990c6@lisalap>
References: <002c01c3ae1b$aee21cf0$75c990c6@lisalap>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <02A3BCCB-1A84-11D8-9DBD-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
Cc: "'Julian Reschke'" ,
        "'Webdav WG'" 
From: Stefan Eissing 
Date: Wed, 19 Nov 2003 12:32:08 +0100
To: "Lisa Dusseault" 
X-Mailer: Apple Mail (2.606)
X-Authenticated-Sender: se@greenbytes.de
X-Spam-Processed: greenbytes.de, Wed, 19 Nov 2003 12:33:10 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Bindings and GULP again
X-Archived-At: http://www.w3.org/mid/02A3BCCB-1A84-11D8-9DBD-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8134
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: <20031119113554.15033A0A7F@frink.w3.org>
Resent-Date: Wed, 19 Nov 2003 06:35:54 -0500 (EST)
Content-Transfer-Encoding: 7bit



Am 18.11.2003 um 22:33 schrieb Lisa Dusseault:

> [...]
>
>   "A lock token is "submitted" in a request when it appears in an If
>   header tagged-list whose tag is the lock-root of the lock, or when
>   it appears in an untagged list and the request-URL is the lock-root
>   of the lock."
>
> In RFC2518bis, a lock token is submitted if it appears anywhere
> in the if header, I think.
> [...]

I agree to that view on submitted lock-tokens. In this, GULP needs a
simplification.

It is advisable for clients to create If headers which are tagged with
the lock-root of the lock. However it is also valid to use the uri of
an indirect-lock resource in a If header. The lock-token should then
be regarded as submitted, too, otherwise modifications of the
resource would fail.

//Stefan



From w3c-dist-auth-request@w3.org  Thu Nov 20 05:50: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 FAA28386
	for ; Thu, 20 Nov 2003 05:50:15 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E5700A0758; Thu, 20 Nov 2003 05:50: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 5CEE1A0754
	for ; Thu, 20 Nov 2003 05:50:21 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 5D7E813A48; Thu, 20 Nov 2003 05:49:24 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by dr-nick.w3.org (Postfix) with SMTP id DB08A13608
	for ; Thu, 20 Nov 2003 05:49:23 -0500 (EST)
Received: (qmail 32037 invoked by uid 65534); 20 Nov 2003 10:49:22 -0000
Received: from unknown (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp001) with SMTP; 20 Nov 2003 11:49:22 +0100
X-Authenticated: #1915285
Message-ID: <3FBC9C31.10103@gmx.de>
Date: Thu, 20 Nov 2003 11:49:21 +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: Stefan Eissing 
Cc: Lisa Dusseault , "'Webdav WG'" 
References: <002c01c3ae1b$aee21cf0$75c990c6@lisalap> <02A3BCCB-1A84-11D8-9DBD-00039384827E@greenbytes.de>
In-Reply-To: <02A3BCCB-1A84-11D8-9DBD-00039384827E@greenbytes.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Bindings and GULP again
X-Archived-At: http://www.w3.org/mid/3FBC9C31.10103@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8135
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: <20031120105026.E5700A0758@frink.w3.org>
Resent-Date: Thu, 20 Nov 2003 05:50:26 -0500 (EST)
Content-Transfer-Encoding: 7bit


Stefan Eissing wrote:

>> In RFC2518bis, a lock token is submitted if it appears anywhere
>> in the if header, I think.
>> [...]
> 
> 
> I agree to that view on submitted lock-tokens. In this, GULP needs a
> simplification.

Clarification: I confused "being submitted for LOCK evaluation" with the 
If header handling. So yes, GULP should state that a lock token is 
submitted when it appears in the If header at all.

However, this doesn't mean that for "If" header processing, lock tokens 
can be supplied un-tagged or with the wrong URI. I'm mentioning this 
because that would be a change from RFC2518, and I don't think we've 
reached consensus on that.

> ...

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Nov 20 06:12:39 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 GAA28734
	for ; Thu, 20 Nov 2003 06:12:38 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 27515A0A41; Thu, 20 Nov 2003 06:12:51 -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 587BBA0B88
	for ; Thu, 20 Nov 2003 06:12:12 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id B619F13B07; Thu, 20 Nov 2003 06:12:10 -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 234AB13B59
	for ; Thu, 20 Nov 2003 06:12:09 -0500 (EST)
Received: (qmail 8065 invoked by uid 65534); 20 Nov 2003 11:12:09 -0000
Received: from unknown (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp027) with SMTP; 20 Nov 2003 12:12:09 +0100
X-Authenticated: #1915285
Message-ID: <3FBCA188.7020502@gmx.de>
Date: Thu, 20 Nov 2003 12:12:08 +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: w3c-dist-auth@w3.org
Cc: "Roy T. Fielding" 
References: <60691A7A-1554-11D8-9F2A-000393753936@apache.org>
In-Reply-To: <60691A7A-1554-11D8-9F2A-000393753936@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: remaining redirect ref issues
X-Archived-At: http://www.w3.org/mid/3FBCA188.7020502@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8136
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: <20031120111251.27515A0A41@frink.w3.org>
Resent-Date: Thu, 20 Nov 2003 06:12:51 -0500 (EST)
Content-Transfer-Encoding: 7bit


Roy T. Fielding wrote:

> I am certain I have said this before, though it was several years ago.
> The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure to get straight
> on that one bit is what causes webdav to trip over HTTP whenever it
> tries to "author" anything other than a boring old file.
> 
> In this case, there must be two different URIs -- one for the resource
> and one for the configuration of that resource.  That configuration
> may be as simple as a URI, maybe a status code and a URI, or maybe even
> an XML document -- that is what must be defined by the redirect protocol.
> The actual URI which responds to requests with a redirect should have a
> link to its configuration URI, such that an authoring tool can discover
> the authorable resource that causes this resource to redirect.  That is
> why webdav requires a source link in order to perform HTTP authoring.
> 
> The same principle holds for all dynamic content.

Well, although I think I agree that this approach would work, it really 
doesn't help resolving the issue we have.

Let's start with a real-world example.

Take a WebDAV collection served by Apache/mod_dav, called "/a", 
containing one internal member "b".

A PROPFIND with Depth: 1 applied to /a will result in a multistatus with 
response elements for

/a
/a/b

Now the admin of the server decides to move the resource, and instead to 
add a permanent redirect reference using httpd.conf. Now, from WebDAV's 
point of view, "/a/b" is gone (because it isn't a WebDAV compliant 
resource anymore).

So PROPFIND Depth: 1 only lists

/a

However a GET on /a/b will return 3xx, so what we have here is a 
non-WebDAV-compliant source in a WebDAV collection. This per se isn't a 
problem.

Now, one of the requirements for the redirect ref spec is to *make* that 
resource WebDAV compliant, thus

- to define how WebDAV methods such as PROPFIND behave,
- to define how they appear as children of their parent collection and
- to define how namespace operations on collections behave if those 
contain redirect references.

Note that these questions are completely independant of how new 
redirects are *authored*.

If I understand you correctly, redirects not being exposed by WebDAV is 
fine and is no problem at all. From that point of view, we indeed don't 
need large parts of the redirect spec at all. However, in our use case 
(a content management system that has link resources), we definitively 
*want* these redirects to be subject of namespace operations.

I also hear that people want to be able to round-trip symbolic links 
between Unix filesystems and a WebDAV store, and redirect resources seem 
to be an obvious mapping.


Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Nov 20 09:31: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 JAA06017
	for ; Thu, 20 Nov 2003 09:31:37 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 543D7A0A2C; Thu, 20 Nov 2003 09:30:42 -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 29499A0A2C
	for ; Thu, 20 Nov 2003 09:30:35 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 0E14813B01; Thu, 20 Nov 2003 09:30:35 -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 D946C13AF3
	for ; Thu, 20 Nov 2003 09:30:34 -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 hAKEUXPF432972
	for ; Thu, 20 Nov 2003 09:30:33 -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 hAKEUVO3025380
	for ; Thu, 20 Nov 2003 09:30:31 -0500
In-Reply-To: 
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, 20 Nov 2003 09:30:25 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF106 | October 27, 2003) at
 11/20/2003 09:30:31,
	Serialize complete at 11/20/2003 09:30:31
Content-Type: multipart/alternative; boundary="=_alternative 004FAD1385256DE4_="
Subject: Re: remaining redirect ref issues
X-Archived-At: http://www.w3.org/mid/OFEAEDA909.84A86A62-ON85256DE4.004F50FB-85256DE4.004FAD16@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8137
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: <20031120143042.543D7A0A2C@frink.w3.org>
Resent-Date: Thu, 20 Nov 2003 09:30:42 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 004FAD1385256DE4_=
Content-Type: text/plain; charset="US-ASCII"

Below I expressed a general problem with the "authoring URI" approach
and Depth operations.  In this particular case (i.e. redirect reference
resources), there is the additional problem that I can't use PROPFIND
to find out the "authoring URI" (because the redirect reference will
automatically redirect the PROPFIND request away from the redirect 
resource).
So I'd need to define a GET-REDIRECT-AUTHORING-URI method to find out
the authoring URI (and then have the problem described in my original
message :-).  The header approach is looking better and better (:-).

Cheers,
Geoff

Geoff wrote on 11/18/2003 09:53:32 PM:

> 
> In principle, I agree with Roy on this issue. 
> 
> But a problem with the "authoring URI" approach occurs when you want to 
> apply a Depth operation (e.g. PROPFIND).  You can get all the authoring 
> URIs with a single Depth PROPFIND, but then how do you avoid having to 
> apply the operation separately to each of the authoring URIs? 
> 
> In the case of PROPFIND, there is a solution provided by RFC-3253 
> (the DAV:expand-property REPORT), but that only works for PROPFIND, 
> not for other Depth methods like COPY. 
> 
> Cheers, 
> Geoff 
> 
> Roy wrote on 11/12/2003 01:08:34 PM:
> 
> > I am certain I have said this before, though it was several years ago.
> > The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure to get 
> > straight
> > on that one bit is what causes webdav to trip over HTTP whenever it
> > tries to "author" anything other than a boring old file.
> > 
> > In this case, there must be two different URIs -- one for the resource
> > and one for the configuration of that resource.  That configuration
> > may be as simple as a URI, maybe a status code and a URI, or maybe 
even
> > an XML document -- that is what must be defined by the redirect 
> > protocol.
> > The actual URI which responds to requests with a redirect should have 
a
> > link to its configuration URI, such that an authoring tool can 
discover
> > the authorable resource that causes this resource to redirect.  That 
is
> > why webdav requires a source link in order to perform HTTP authoring.
> > 
> > The same principle holds for all dynamic content.
> > 
> > ....Roy
> > 
--=_alternative 004FAD1385256DE4_=
Content-Type: text/html; charset="US-ASCII"



Below I expressed a general problem with the "authoring
URI" approach

and Depth operations.  In this particular case
(i.e. redirect reference

resources), there is the additional problem that I
can't use PROPFIND

to find out the "authoring URI" (because
the redirect reference will

automatically redirect the PROPFIND request away from
the redirect resource).

So I'd need to define a GET-REDIRECT-AUTHORING-URI
method to find out

the authoring URI (and then have the problem described
in my original

message :-).  The header approach is looking
better and better (:-).



Cheers,

Geoff



Geoff wrote on 11/18/2003 09:53:32 PM:



> 

> In principle, I agree with Roy on this issue. 

> 

> But a problem with the "authoring URI" approach occurs when
you want to 

> apply a Depth operation (e.g. PROPFIND).  You can get all the
authoring 

> URIs with a single Depth PROPFIND, but then how do you avoid having
to 

> apply the operation separately to each of the authoring URIs? 

> 

> In the case of PROPFIND, there is a solution provided by RFC-3253


> (the DAV:expand-property REPORT), but that only works for PROPFIND,


> not for other Depth methods like COPY. 

> 

> Cheers, 

> Geoff 

> 

> Roy wrote on 11/12/2003 01:08:34 PM:

> 

> > I am certain I have said this before, though it was several years
ago.

> > The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure
to get 

> > straight

> > on that one bit is what causes webdav to trip over HTTP whenever
it

> > tries to "author" anything other than a boring old
file.

> > 

> > In this case, there must be two different URIs -- one for the
resource

> > and one for the configuration of that resource.  That configuration

> > may be as simple as a URI, maybe a status code and a URI, or
maybe even

> > an XML document -- that is what must be defined by the redirect


> > protocol.

> > The actual URI which responds to requests with a redirect should
have a

> > link to its configuration URI, such that an authoring tool can
discover

> > the authorable resource that causes this resource to redirect.
 That is

> > why webdav requires a source link in order to perform HTTP authoring.

> > 

> > The same principle holds for all dynamic content.

> > 

> > ....Roy

> > 
--=_alternative 004FAD1385256DE4_=--



From w3c-dist-auth-request@w3.org  Thu Nov 20 15:32: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 PAA24368
	for ; Thu, 20 Nov 2003 15:32:03 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9877FA0BBC; Thu, 20 Nov 2003 15:31:58 -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 5EC18A055B
	for ; Thu, 20 Nov 2003 15:31:54 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 45F70131DD; Thu, 20 Nov 2003 15:31:54 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id B059513F4B
	for ; Thu, 20 Nov 2003 15:31:50 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AMvSv-00021j-00; Thu, 20 Nov 2003 20:31:49 +0000
Received: from [65.218.244.110] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AMvSv-00021Y-00; Thu, 20 Nov 2003 20:31:49 +0000
From: "Lisa Dusseault" 
To: "'Julian Reschke'" ,
        "'Stefan Eissing'" 
Cc: "'Webdav WG'" 
Date: Thu, 20 Nov 2003 12:31:36 -0800
Message-ID: <027101c3afa5$4b88b160$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
In-Reply-To: <3FBC9C31.10103@gmx.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Old-X-Envelope-To: julian.reschke@gmx.de,
 stefan.eissing@greenbytes.de,
 w3c-dist-auth@w3c.org
Subject: RE: Bindings and GULP again
X-Archived-At: http://www.w3.org/mid/027101c3afa5$4b88b160$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8138
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: <20031120203158.9877FA0BBC@frink.w3.org>
Resent-Date: Thu, 20 Nov 2003 15:31:58 -0500 (EST)
Content-Transfer-Encoding: 7bit


> Stefan Eissing wrote:
> 
> >> In RFC2518bis, a lock token is submitted if it appears anywhere in 
> >> the if header, I think. [...]
> > 
> > 
> > I agree to that view on submitted lock-tokens. In this, 
> GULP needs a 
> > simplification.
> 
> Clarification: I confused "being submitted for LOCK 
> evaluation" with the 
> If header handling. So yes, GULP should state that a lock token is 
> submitted when it appears in the If header at all.
> 
> However, this doesn't mean that for "If" header processing, 
> lock tokens 
> can be supplied un-tagged or with the wrong URI. I'm mentioning this 
> because that would be a change from RFC2518, and I don't think we've 
> reached consensus on that.

No problem here, we all agree that lock tokens must be tagged with
the right URI (or untagged). Otherwise you'd get 412 Precondition 
Failed.  This hasn't changed in RFC2518bis, but if the language is
unclear I'm happy to take a look.

Lisa




From w3c-dist-auth-request@w3.org  Thu Nov 20 15:58: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 PAA25898
	for ; Thu, 20 Nov 2003 15:58:50 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4C6DAA0B9E; Thu, 20 Nov 2003 15:59:02 -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 BDF37A0B9E
	for ; Thu, 20 Nov 2003 15:58:57 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 7636613650; Thu, 20 Nov 2003 15:58:57 -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 03C9F13C20
	for ; Thu, 20 Nov 2003 15:58:57 -0500 (EST)
Received: (qmail 28523 invoked by uid 65534); 20 Nov 2003 20:58:49 -0000
Received: from pD950C273.dip.t-dialin.net (EHLO gmx.de) (217.80.194.115)
  by mail.gmx.net (mp007) with SMTP; 20 Nov 2003 21:58:49 +0100
X-Authenticated: #1915285
Message-ID: <3FBD2AEE.2090101@gmx.de>
Date: Thu, 20 Nov 2003 21:58:22 +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: <027101c3afa5$4b88b160$75c990c6@lisalap>
In-Reply-To: <027101c3afa5$4b88b160$75c990c6@lisalap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Bindings and GULP again
X-Archived-At: http://www.w3.org/mid/3FBD2AEE.2090101@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8139
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: <20031120205902.4C6DAA0B9E@frink.w3.org>
Resent-Date: Thu, 20 Nov 2003 15:59:02 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> No problem here, we all agree that lock tokens must be tagged with
> the right URI (or untagged). Otherwise you'd get 412 Precondition 
> Failed.  This hasn't changed in RFC2518bis, but if the language is
> unclear I'm happy to take a look.

No, that's fine. I just confused changes that are useful and we agreed 
upon and others I *thought* went in that were still under discussion.

If this shows anything, it's that we better finish discussions, then 
resolve the issues and document it :-)

Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Nov 20 16:25: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 QAA28228
	for ; Thu, 20 Nov 2003 16:25:35 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8E1B6A0639; Thu, 20 Nov 2003 16:25:47 -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 26965A0C14
	for ; Thu, 20 Nov 2003 16:25:39 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 922FB140B8; Thu, 20 Nov 2003 16:24:21 -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 E2CD913EE2
	for ; Thu, 20 Nov 2003 16:24:19 -0500 (EST)
Received: (qmail 15459 invoked by uid 65534); 20 Nov 2003 21:24:13 -0000
Received: from pD950C273.dip.t-dialin.net (EHLO gmx.de) (217.80.194.115)
  by mail.gmx.net (mp012) with SMTP; 20 Nov 2003 22:24:13 +0100
X-Authenticated: #1915285
Message-ID: <3FBD30E7.1050908@gmx.de>
Date: Thu, 20 Nov 2003 22:23:51 +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: Comments on draft-dusseault-http-patch-00
X-Archived-At: http://www.w3.org/mid/3FBD30E7.1050908@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8140
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: <20031120212547.8E1B6A0639@frink.w3.org>
Resent-Date: Thu, 20 Nov 2003 16:25:47 -0500 (EST)
Content-Transfer-Encoding: 7bit


...see 



In general, I think this addresses a real performance issue, and I'd 
imagine that existing WebDAV clients and servers will soon take 
advantage of it.

Comments:

 >   2.  DeltaV extends WebDAV to do versioning.  In versioning
 >       environments, a large number of files may be updated with very
 >       small changes.  For example, a programmer may change the name of
 >       a function used in a hundred source files.  Versioning
 >       applications typically send deltas or 'diffs' to the server to
 >       modify these files, however DetaV does not yet have this
 >       functionality.

Note: it may make sense to talk to the Subversion guys about how they 
are handling this case.

 >   3.  The SIMPLE WG is devising a way to store and modify configuration
 >       information. The biggest feature missing from HTTP is the ability
 >       to modify information in a very lightweight manner, so that the
 >       client that decides to change its presence state from "free" to
 >       "busy" doesn't have to upload a large document. This can be
 >       accomplished through changes to a HTTP resource as well.

In general, this can also be done by choosing a greater granularity in 
authorable resources (URIs). That being said, changing part of the 
contents of an authorable resource is of course a useful feature in any 
case.

 >   This specification defines a new HTTP 1.1 method for patches [HTTP].
 >   A new method is necessary to improve interoperability and prevent
 >   errors. The PUT method is already defined to overwrite a resource
 >   with a complete new body, and MUST NOT be reused to do partial
 >   changes. Otherwise, proxies and caches and even clients and servers
 >   may get confused as to the result of the operation.

Note: an alternative would be to use the HTTP Extension Framework 
(RFC2774), use M-PUT and define a mandatory range extension.

 >   PATCH bodies are not cachable.  A cache MAY mark the resource
 >   identified in the Request-URI as stale if it sees a successful
 >   response to the PATCH request.

I think we need to talk about the cacheability of responses (in this 
case, MUST not). We may also need to define whether PATCH is a "safe" or
"idempotent" message (RFC2616, sectiom 9.1). I'd say that PATCH is
neither safe nor idempotent (I think it may be idempotent for a few
specific patch formats, but in general probably not).

 >   The PATCH request MUST have a body.  It MUST include the Content-Type
 >   header with a value indicating what the body type is.  It MUST be a

...what the mime type of the message body is...

 >   format that has the semantics of defining a change to an existing
 >   document (such as gdiff or vcdiff).   The PATCH request MUST also use
 >   one of the standard HTTP/1.1 mechanisms that let the server know when
 >   the request body is done. The PATCH request body length MUST NOT be
 >   indicated only by closing the connection when the body is complete,
 >   because an incomplete PATCH body could conceivably corrupt the target
 >   resource.

How would that work? If a client sends PATCH and closes the connection 
before reading the result, this wouldn't work anyway. Please elaborate.

 >   The PATCH request MUST only be used in a context which ensures that
 >   only one user may apply a patch at a time.  There are two reliable
 >   ways to do this. The first way is to find out the resource ETag at
 >   the time the body is downloaded, and use that Etag in the PATCH
 >   request to make sure the resource is still unchanged.  The second way
 >   to use WebDAV LOCK/UNLOCK [WEBDAV] to reserve the file (first LOCK,
 >   then GET, then PATCH, then UNLOCK).  PATCH collisions from multiple
 >   users are more dangerous than PUT collisions, because a PATCH that is
 >   not operating from a known base point may corrupt the resource.
 >   Therefore, if neither strong ETags nor LOCKS are available from the
 >   server, the client MUST use If-Last-Modified as a less-reliable
 >   safeguard.

In this case (:-), I'd argue for a stronger requirement (MUST only work 
for resources that support strong etags).

 >   The PATCH method can return the following errors. Please note that
 >   the notation "DAV:foobar" is merely short form for expressing "the
 >   'foobar' element in the 'DAV:' namespace".  It has meaning only in
 >   English, not on the wire.  Also note that the string error codes are
 >   not meant to be displayed but instead as machine parsable known error
 >   codes (thus there is no language code).

Use RFC3253 terminology, thus name the precondition,
not the error condition

 >   Set of defined delta formats

General comment: there should be only one (or two) MUST requirements, 
one for sending updates to arbitrary ranges in the resource, one for 
truncating the resource to a specific length. It would be optimal if 
both can be done using the same format.

 >   When the OPTIONS request addresses a specific modifiable resource,
 >   the Patch header in the response indicates which delta formats may be
 >   used for this specific resource.  When an OPTIONS request addresses
 >   the server as a whole (Request-URI = "*") the Delta header in the
 >   response indicates the union of all delta formats supported by the
 >   server.

Not implementable using the Java servlet API.


Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760




From w3c-dist-auth-request@w3.org  Fri Nov 21 03:36: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 DAA05209
	for ; Fri, 21 Nov 2003 03:36:35 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1553FA0635; Fri, 21 Nov 2003 03:36:47 -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 D41CCA0635
	for ; Fri, 21 Nov 2003 03:36:42 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id B285713AC4; Fri, 21 Nov 2003 03:36:42 -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 3F12C135C2
	for ; Fri, 21 Nov 2003 03:36:42 -0500 (EST)
Received: (qmail 23895 invoked by uid 65534); 21 Nov 2003 08:36:36 -0000
Received: from pD950C273.dip.t-dialin.net (EHLO gmx.de) (217.80.194.115)
  by mail.gmx.net (mp005) with SMTP; 21 Nov 2003 09:36:36 +0100
X-Authenticated: #1915285
Message-ID: <3FBDCE84.7000003@gmx.de>
Date: Fri, 21 Nov 2003 09:36:20 +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'" 
References: <3FBD30E7.1050908@gmx.de>
In-Reply-To: <3FBD30E7.1050908@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Comments on draft-dusseault-http-patch-00
X-Archived-At: http://www.w3.org/mid/3FBDCE84.7000003@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8141
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: <20031121083647.1553FA0635@frink.w3.org>
Resent-Date: Fri, 21 Nov 2003 03:36:47 -0500 (EST)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:

> ...see 
>  

Here's another thought. You could get rid of any changes to OPTIONS 
altogether by specifying:

A PATCH request with no or unknown content type must result in a 4xx 
status, and a "Patch" response header summarizing the supported content 
types. Then a client can simply submit a PATCH request with no 
Content-Type header (and no body) to get the list of supported types.

I think this would be a good simplification as it makes PATCH 
independant of all other HTTP methods.

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Fri Nov 21 09:24:05 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 JAA14448
	for ; Fri, 21 Nov 2003 09:24:04 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 37982A0732; Fri, 21 Nov 2003 09:23:42 -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 2CA04A0657
	for ; Fri, 21 Nov 2003 09:23:35 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 9A28613772; Fri, 21 Nov 2003 09:23:34 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105])
	by dr-nick.w3.org (Postfix) with ESMTP
	id 7C8EE1358B; Fri, 21 Nov 2003 09:23:34 -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 hALENQTs230816;
	Fri, 21 Nov 2003 09:23:26 -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 hALENOLR182596;
	Fri, 21 Nov 2003 09:23:25 -0500
In-Reply-To: <3FBDCE84.7000003@gmx.de>
To: Julian Reschke 
Cc: "'Webdav WG'" , 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: Fri, 21 Nov 2003 09:23:19 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF106 | October 27, 2003) at
 11/21/2003 09:23:26,
	Serialize complete at 11/21/2003 09:23:26
Content-Type: multipart/alternative; boundary="=_alternative 004F069385256DE5_="
Subject: Re: Comments on draft-dusseault-http-patch-00
X-Archived-At: http://www.w3.org/mid/OF016E5129.44B16582-ON85256DE5.004EEF9A-85256DE5.004F069A@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8142
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: <20031121142342.37982A0732@frink.w3.org>
Resent-Date: Fri, 21 Nov 2003 09:23:42 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 004F069385256DE5_=
Content-Type: text/plain; charset="US-ASCII"

I agree that this would be an improvement over the OPTIONS technique.

Cheers,
Geoff


> Julian Reschke wrote:
> 
> > ...see 
> >  http-patch-00.txt> 
> 
> Here's another thought. You could get rid of any changes to OPTIONS 
> altogether by specifying:
> 
> A PATCH request with no or unknown content type must result in a 4xx 
> status, and a "Patch" response header summarizing the supported content 
> types. Then a client can simply submit a PATCH request with no 
> Content-Type header (and no body) to get the list of supported types.
> 
> I think this would be a good simplification as it makes PATCH 
> independant of all other HTTP methods.
> 
> Julian
> 
> -- 
> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 

--=_alternative 004F069385256DE5_=
Content-Type: text/html; charset="US-ASCII"



I agree that this would be an improvement over the
OPTIONS technique.



Cheers,

Geoff





> Julian Reschke wrote:

> 

> > ...see 

> > <http://www.sharemation.com/~milele/public/dav/draft-dusseault-

> http-patch-00.txt> 

> 

> Here's another thought. You could get rid of any changes to OPTIONS


> altogether by specifying:

> 

> A PATCH request with no or unknown content type must result in a 4xx


> status, and a "Patch" response header summarizing the supported
content 

> types. Then a client can simply submit a PATCH request with no 

> Content-Type header (and no body) to get the list of supported types.

> 

> I think this would be a good simplification as it makes PATCH 

> independant of all other HTTP methods.

> 

> Julian

> 

> -- 

> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> 


--=_alternative 004F069385256DE5_=--



From w3c-dist-auth-request@w3.org  Fri Nov 21 19:08: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 TAA13117
	for ; Fri, 21 Nov 2003 19:08:49 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8555BA0788; Fri, 21 Nov 2003 19:08: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 D67E4A0788
	for ; Fri, 21 Nov 2003 19:08:51 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 7D00F134ED; Fri, 21 Nov 2003 19:08:51 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id 492C413483
	for ; Fri, 21 Nov 2003 19:08:51 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1ANLKU-0003lK-00; Sat, 22 Nov 2003 00:08:50 +0000
Received: from [198.144.201.117] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1ANLKU-0003l9-00; Sat, 22 Nov 2003 00:08:50 +0000
From: "Lisa Dusseault" 
To: "'Julian Reschke'" ,
        "'Webdav WG'" 
Date: Fri, 21 Nov 2003 16:08:39 -0800
Message-ID: <04b501c3b08c$c89824f0$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
In-Reply-To: <3FBDCE84.7000003@gmx.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Comments on draft-dusseault-http-patch-00
X-Archived-At: http://www.w3.org/mid/04b501c3b08c$c89824f0$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8143
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: <20031122000855.8555BA0788@frink.w3.org>
Resent-Date: Fri, 21 Nov 2003 19:08:55 -0500 (EST)
Content-Transfer-Encoding: 7bit


The OPTIONS changes are as much to find out if the server supports PATCH, as
to 
indicate which patch formats are supported.  It's nice for clients to be
able
to discover all major optional features supported by the server in one
OPTIONS request, rather than trying features which might not work.

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke
> Sent: Friday, November 21, 2003 12:36 AM
> To: 'Webdav WG'
> Subject: Re: Comments on draft-dusseault-http-patch-00
> 
> 
> 
> Julian Reschke wrote:
> 
> > ...see 
> > 
> 

Here's another thought. You could get rid of any changes to OPTIONS 
altogether by specifying:

A PATCH request with no or unknown content type must result in a 4xx 
status, and a "Patch" response header summarizing the supported content 
types. Then a client can simply submit a PATCH request with no 
Content-Type header (and no body) to get the list of supported types.

I think this would be a good simplification as it makes PATCH 
independant of all other HTTP methods.

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760





From w3c-dist-auth-request@w3.org  Sat Nov 22 10:22:41 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 KAA14188
	for ; Sat, 22 Nov 2003 10:22:41 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E887FA0F64; Sat, 22 Nov 2003 10:22:42 -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 99FCFA0F65
	for ; Sat, 22 Nov 2003 10:22:38 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id B814C147C7; Sat, 22 Nov 2003 10:20: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 44574147C5
	for ; Sat, 22 Nov 2003 10:20:04 -0500 (EST)
Received: (qmail 22500 invoked by uid 65534); 22 Nov 2003 15:19:54 -0000
Received: from pD950C380.dip.t-dialin.net (EHLO gmx.de) (217.80.195.128)
  by mail.gmx.net (mp005) with SMTP; 22 Nov 2003 16:19:54 +0100
X-Authenticated: #1915285
Message-ID: <3FBF7E6C.2090104@gmx.de>
Date: Sat, 22 Nov 2003 16:19:08 +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: <04b501c3b08c$c89824f0$75c990c6@lisalap>
In-Reply-To: <04b501c3b08c$c89824f0$75c990c6@lisalap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Comments on draft-dusseault-http-patch-00
X-Archived-At: http://www.w3.org/mid/3FBF7E6C.2090104@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8144
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: <20031122152242.E887FA0F64@frink.w3.org>
Resent-Date: Sat, 22 Nov 2003 10:22:42 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> The OPTIONS changes are as much to find out if the server supports PATCH, as to

That doesn't require additional functionality, there's already the 
"Allow" header.

> indicate which patch formats are supported.  It's nice for clients to be able
> to discover all major optional features supported by the server in one
> OPTIONS request, rather than trying features which might not work.

Is this doesn't seem to be time-critical, I'm not sure that I see the 
benefit. Not changing OPTIONS will create less dependencies and will 
possibly make it easier to add the feature to existing servers.

Note that the proposed "OPTIONS *" functionality will not work anyway. 
Is it worth keeping the remainder?

Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 24 12:26: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 MAA17387
	for ; Mon, 24 Nov 2003 12:26:07 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A758AA0CF9; Mon, 24 Nov 2003 12:24: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 184A2A1149
	for ; Mon, 24 Nov 2003 11:57:21 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id AAE661461E; Mon, 24 Nov 2003 11:42:51 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20])
	by dr-nick.w3.org (Postfix) with SMTP id E263F15C2E
	for ; Mon, 24 Nov 2003 11:28:39 -0500 (EST)
Received: (qmail 28129 invoked by uid 65534); 24 Nov 2003 16:28:39 -0000
Received: from mail.greenbytes.de (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp022) with SMTP; 24 Nov 2003 17:28:39 +0100
X-Authenticated: #1915285
Message-ID: <3FC231B6.8060800@gmx.de>
Date: Mon, 24 Nov 2003 17:28:38 +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: Resolving RFC2518 issue 55 ("DISPLAYNAME")
X-Archived-At: http://www.w3.org/mid/3FC231B6.8060800@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8145
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: <20031124172441.A758AA0CF9@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 12:24:41 -0500 (EST)
Content-Transfer-Encoding: 7bit


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  Mon Nov 24 13:04:54 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19323
	for ; Mon, 24 Nov 2003 13:04:54 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E629BA06F4; Mon, 24 Nov 2003 13:05: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 68B8BA06F4
	for ; Mon, 24 Nov 2003 13:05:04 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 12D6913508; Mon, 24 Nov 2003 13:05:04 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id D209713339
	for ; Mon, 24 Nov 2003 13:05:03 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AOL54-0000SB-00; Mon, 24 Nov 2003 18:05:02 +0000
Received: from [64.202.9.194] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AOL53-0000S0-00; Mon, 24 Nov 2003 18:05:01 +0000
From: "Lisa Dusseault" 
To: "'Julian Reschke'" 
Cc: "'Webdav WG'" 
Date: Mon, 24 Nov 2003 10:04:57 -0800
Message-ID: <004901c3b2b5$78cc8580$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
In-Reply-To: <3FBF7E6C.2090104@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/004901c3b2b5$78cc8580$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8146
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: <20031124180507.E629BA06F4@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 13:05:07 -0500 (EST)
Content-Transfer-Encoding: 7bit


> Note that the proposed "OPTIONS *" functionality will not 
> work anyway. 
> Is it worth keeping the remainder?

OPTIONS * is an HTTP feature, not a WebDAV feature that we can
keep or throw away.  It's been there for years.  I haven't seen
much opposition to the feature, outside of a few people on the
WebDAV mailing list.  It's got useful semantics.

It's too bad, as Julian has pointed out in the past, that the
Java servlet design made it difficult to add stuff to OPTIONS *.
(It's not impossible, just difficult.  I can point to existence
proofs that it's possible, it just requires taking over the root
namespace with a servlet application, or doing something outside
the servlet framework.)  To me, that argues for fixes to the 
Java servlet functionality, not dropping an HTTP feature.  If
Microsoft "broke" OPTIONS * in its ISAPI design, the standards
community would not be so likely to quietly drop support for it.

Lisa




From w3c-dist-auth-request@w3.org  Mon Nov 24 13:31:33 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20105
	for ; Mon, 24 Nov 2003 13:31:32 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3824CA0668; Mon, 24 Nov 2003 13:31: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 6F4D3A0668
	for ; Mon, 24 Nov 2003 13:31:38 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 561C514321; Mon, 24 Nov 2003 13:31:38 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.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 1BE5914297
	for ; Mon, 24 Nov 2003 13:31:38 -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 hAOIVXg6362190
	for ; Mon, 24 Nov 2003 13:31:33 -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 hAOIVVDT045762
	for ; Mon, 24 Nov 2003 13:31:32 -0500
In-Reply-To: <004901c3b2b5$78cc8580$75c990c6@lisalap>
To: "'Webdav WG'" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: 
From: Geoffrey M Clemm 
Date: Mon, 24 Nov 2003 13:31:25 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 11/24/2003 13:31:31,
	Serialize complete at 11/24/2003 13:31:31
Content-Type: multipart/alternative; boundary="=_alternative 0065BD6A85256DE8_="
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/OF91734D8B.F6E5B2A5-ON85256DE8.00645044-85256DE8.0065BD6E@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8147
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: <20031124183144.3824CA0668@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 13:31:44 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 0065BD6A85256DE8_=
Content-Type: text/plain; charset="US-ASCII"

One of the problem with "OPTIONS *" is that it is easy for
a client to misunderstand the scope of the "server" that is
answering the request.  Commonly, a client will assume that
it refers to "any resource under /", but this will not be
the case when different servers are handling different
resources under "/".
 
So "OPTIONS *" is reasonably well defined in simple cases
where there is one server handling the entire web site,
but we shouldn't be defining protocols that only work for the
simple cases.

Note: It doesn't particularly matter if only a "few people
on the WebDAV mailing list" make a point, if that point is
valid.  Most people building web servers only read the
WebDAV mailing list infrequently, if at all, and even fewer
of them feel comfortable or have the time to post.  So we should
make optimal use of those that are consistent readers and
posters.

Cheers,
Geoff


Lisa wrote on 11/24/2003 01:04:57 PM:

> 
> > Note that the proposed "OPTIONS *" functionality will not 
> > work anyway. 
> > Is it worth keeping the remainder?
> 
> OPTIONS * is an HTTP feature, not a WebDAV feature that we can
> keep or throw away.  It's been there for years.  I haven't seen
> much opposition to the feature, outside of a few people on the
> WebDAV mailing list.  It's got useful semantics.
> 
> It's too bad, as Julian has pointed out in the past, that the
> Java servlet design made it difficult to add stuff to OPTIONS *.
> (It's not impossible, just difficult.  I can point to existence
> proofs that it's possible, it just requires taking over the root
> namespace with a servlet application, or doing something outside
> the servlet framework.)  To me, that argues for fixes to the 
> Java servlet functionality, not dropping an HTTP feature.  If
> Microsoft "broke" OPTIONS * in its ISAPI design, the standards
> community would not be so likely to quietly drop support for it.
> 
> Lisa
> 
> 

--=_alternative 0065BD6A85256DE8_=
Content-Type: text/html; charset="US-ASCII"



One of the problem with "OPTIONS *" is that
it is easy for

a client to misunderstand the scope of the "server"
that is

answering the request.  Commonly, a client will
assume that

it refers to "any resource under /", but
this will not be

the case when different servers are handling different

resources under "/".

 

So "OPTIONS *" is reasonably well defined
in simple cases

where there is one server handling the entire web
site,

but we shouldn't be defining protocols that only work
for the

simple cases.



Note: It doesn't particularly matter if only a "few
people

on the WebDAV mailing list" make a point, if
that point is

valid.  Most people building web servers only
read the

WebDAV mailing list infrequently, if at all, and even
fewer

of them feel comfortable or have the time to post.
 So we should

make optimal use of those that are consistent readers
and

posters.



Cheers,

Geoff





Lisa wrote on 11/24/2003 01:04:57 PM:



> 

> > Note that the proposed "OPTIONS *" functionality will
not 

> > work anyway. 

> > Is it worth keeping the remainder?

> 

> OPTIONS * is an HTTP feature, not a WebDAV feature that we can

> keep or throw away.  It's been there for years.  I haven't
seen

> much opposition to the feature, outside of a few people on the

> WebDAV mailing list.  It's got useful semantics.

> 

> It's too bad, as Julian has pointed out in the past, that the

> Java servlet design made it difficult to add stuff to OPTIONS *.

> (It's not impossible, just difficult.  I can point to existence

> proofs that it's possible, it just requires taking over the root

> namespace with a servlet application, or doing something outside

> the servlet framework.)  To me, that argues for fixes to the


> Java servlet functionality, not dropping an HTTP feature.  If

> Microsoft "broke" OPTIONS * in its ISAPI design, the standards

> community would not be so likely to quietly drop support for it.

> 

> Lisa

> 

> 


--=_alternative 0065BD6A85256DE8_=--



From w3c-dist-auth-request@w3.org  Mon Nov 24 13:50: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 NAA21028
	for ; Mon, 24 Nov 2003 13:50:10 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 03304A0518; Mon, 24 Nov 2003 13:50: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 0E789A0518
	for ; Mon, 24 Nov 2003 13:50:19 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id C9B1213753; Mon, 24 Nov 2003 13:50:18 -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 601771374D
	for ; Mon, 24 Nov 2003 13:50:18 -0500 (EST)
Received: (qmail 21700 invoked by uid 65534); 24 Nov 2003 18:50:16 -0000
Received: from p3EE24759.dip.t-dialin.net (EHLO gmx.de) (62.226.71.89)
  by mail.gmx.net (mp025) with SMTP; 24 Nov 2003 19:50:16 +0100
X-Authenticated: #1915285
Message-ID: <3FC252E2.7090600@gmx.de>
Date: Mon, 24 Nov 2003 19:50: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: Lisa Dusseault 
Cc: "'Webdav WG'" 
References: <004901c3b2b5$78cc8580$75c990c6@lisalap>
In-Reply-To: <004901c3b2b5$78cc8580$75c990c6@lisalap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/3FC252E2.7090600@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8148
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: <20031124185023.03304A0518@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 13:50:23 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:
>>Note that the proposed "OPTIONS *" functionality will not 
>>work anyway. 
>>Is it worth keeping the remainder?
> 
> 
> OPTIONS * is an HTTP feature, not a WebDAV feature that we can
> keep or throw away.  It's been there for years.  I haven't seen

Lisa, I pointed out multiple times that your proposals (both RFC2518bis 
and the PATCH spec) indeed contradict RFC2616, which says:

"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)."

> much opposition to the feature, outside of a few people on the
> WebDAV mailing list.  It's got useful semantics.

Yes. Please stick to them.

> It's too bad, as Julian has pointed out in the past, that the
> Java servlet design made it difficult to add stuff to OPTIONS *.
> (It's not impossible, just difficult.  I can point to existence
> proofs that it's possible, it just requires taking over the root
> namespace with a servlet application, or doing something outside
> the servlet framework.)  To me, that argues for fixes to the 
> Java servlet functionality, not dropping an HTTP feature.  If
> Microsoft "broke" OPTIONS * in its ISAPI design, the standards
> community would not be so likely to quietly drop support for it.

I agree that it would be nice if the servlet spec would allow us to do 
something here. But it doesn't. If you feel this is a big problem, raise 
it in the servlet community.

However I feel it entirely unacceptable to add new "must" level 
requirements (RFC2518bis, section 9.1) when

a) this contradicts RFC2616 and
b) it clearly is impossible to implement for a generic Java servlet.

If you feel strongly about adding this to WebDAV, please discuss it 
first. However just silently putting it in without any prior discussion 
IMHO really isn't constructive.

Regards,

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 24 14:06: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 OAA21793
	for ; Mon, 24 Nov 2003 14:06:16 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B4A8DA0532; Mon, 24 Nov 2003 14:06:29 -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 59140A0CD7
	for ; Mon, 24 Nov 2003 14:05:04 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 128111467F; Mon, 24 Nov 2003 14:03:50 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34])
	by dr-nick.w3.org (Postfix) with ESMTP id 5C0401444C
	for ; Mon, 24 Nov 2003 14:03:48 -0500 (EST)
Received: from [192.168.101.126] (unknown [213.187.82.59])
	by mail.mdlink.net (Postfix) with ESMTP id 3BF2D1F9D13
	for ; Mon, 24 Nov 2003 20:00:24 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v606)
In-Reply-To: <3FC252E2.7090600@gmx.de>
References: <004901c3b2b5$78cc8580$75c990c6@lisalap> <3FC252E2.7090600@gmx.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Helge Hess 
Date: Mon, 24 Nov 2003 20:03:32 +0100
To: "'Webdav WG'" 
X-Mailer: Apple Mail (2.606)
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/E590F7A6-1EB0-11D8-8A54-00039340AF4A@opengroupware.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8149
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: <20031124190629.B4A8DA0532@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 14:06:29 -0500 (EST)
Content-Transfer-Encoding: 7bit


On 24.11.2003, at 19:50, Julian Reschke wrote:
> However I feel it entirely unacceptable to add new "must" level 
> requirements (RFC2518bis, section 9.1) when
...
> b) it clearly is impossible to implement for a generic Java servlet.

Hm, this comment is *really* weird. A generic HTTP API is restricted 
because some API which isn't nearly as old as HTTP doesn't provide the 
required functionality?

best regards,
   Helge
-- 
OpenGroupware.org	http://www.opengroupware.org/



From w3c-dist-auth-request@w3.org  Mon Nov 24 14:17:28 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 OAA22518
	for ; Mon, 24 Nov 2003 14:17:27 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EA660A0887; Mon, 24 Nov 2003 14:17: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 85367A0731
	for ; Mon, 24 Nov 2003 14:17:26 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id DBC3814607; Mon, 24 Nov 2003 14:11:08 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34])
	by dr-nick.w3.org (Postfix) with ESMTP id 1961A146DB
	for ; Mon, 24 Nov 2003 14:11:08 -0500 (EST)
Received: from [192.168.101.126] (unknown [213.187.82.59])
	by mail.mdlink.net (Postfix) with ESMTP id D86B41F9D22
	for ; Mon, 24 Nov 2003 20:07:54 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v606)
Content-Transfer-Encoding: 7bit
Message-Id: 
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: "'Webdav WG'" 
From: Helge Hess 
Date: Mon, 24 Nov 2003 20:11:01 +0100
X-Mailer: Apple Mail (2.606)
Subject: WebDAV MOVE
X-Archived-At: http://www.w3.org/mid/F19E07F9-1EB1-11D8-8A54-00039340AF4A@opengroupware.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8150
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: <20031124191735.EA660A0887@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 14:17:35 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

the specification is a bit unclear on what we are supposed to return in 
the case that a MOVE cannot be completed because request URL and 
destination URL are on different servers or are on different 
subnamespaces on a single server.
I would expect some return value that signals to the client that the 
URLs are on different "drives". The client could then try to implement 
the MOVE logic on the client side (eg using PUT to dest then DELETE in 
src).
Any suggestions?

Thanks,
   Helge
-- 
OpenGroupware.org	http://www.opengroupware.org/



From w3c-dist-auth-request@w3.org  Mon Nov 24 14:25: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 OAA22981
	for ; Mon, 24 Nov 2003 14:25:56 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9D1BCA0873; Mon, 24 Nov 2003 14:25: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 07E50A0866
	for ; Mon, 24 Nov 2003 14:25:25 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 78E8013E12; Mon, 24 Nov 2003 14:25:18 -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 0C05F13D72
	for ; Mon, 24 Nov 2003 14:25:18 -0500 (EST)
Received: (qmail 11932 invoked by uid 65534); 24 Nov 2003 19:25:15 -0000
Received: from pD950C26F.dip.t-dialin.net (EHLO gmx.de) (217.80.194.111)
  by mail.gmx.net (mp016) with SMTP; 24 Nov 2003 20:25:15 +0100
X-Authenticated: #1915285
Message-ID: <3FC25B0A.7020104@gmx.de>
Date: Mon, 24 Nov 2003 20:24:58 +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: Helge Hess 
Cc: "'Webdav WG'" 
References: <004901c3b2b5$78cc8580$75c990c6@lisalap> <3FC252E2.7090600@gmx.de> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/3FC25B0A.7020104@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8151
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: <20031124192534.9D1BCA0873@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 14:25:34 -0500 (EST)
Content-Transfer-Encoding: 7bit


Helge Hess wrote:

> On 24.11.2003, at 19:50, Julian Reschke wrote:
> 
>> However I feel it entirely unacceptable to add new "must" level 
>> requirements (RFC2518bis, section 9.1) when
> 
> ...
> 
>> b) it clearly is impossible to implement for a generic Java servlet.
> 
> 
> Hm, this comment is *really* weird. A generic HTTP API is restricted 
> because some API which isn't nearly as old as HTTP doesn't provide the 
> required functionality?

No, it's not weird at all. When we discuss RFC2518bis, we are talking 
about progressing RFC2518 from "proposed" to "draft". Usually, this 
precludes adding any new requirements, unless there is already proven 
interoperability.

As a matter of fact, many of the currently existing WebDAV server 
implementations are based on the servlet API, and thus -- by defintion 
-- can't comply to the new requirement.

In addition, I have some very strong feelings (:-) about adding new 
"must" level requirements to a spec revision without

- any prior discussion (or even consensus)
- any clear benefit
- or even any notice to the working group (such as announcing the change 
after the Internet Draft was submitted)

Speaking about the PATCH method proposal - this is something new that 
doesn't need to be compatible with any existing implementation. However, 
I feel that putting additional requirements on OPTIONS is a bad idea

- because it will harm implementability in servlets and
- it introduces a dependency on other HTTP methods that doesn't seem to 
be necessary.

Finally, adding "must" level requirements to a spec that are likely to 
be ignored by many servers is really a disservice to everybody. Either 
people won't implement the spec at all, or they will and will claim 
conformance, although their implementation doesn't fully comply. In the 
latter case clients that rely on that behaviour (being a "must") will 
run into problems (in the best case, they'll not be able to use that 
feature although it's there).

Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 24 14:31:44 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23330
	for ; Mon, 24 Nov 2003 14:31:44 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 49C46A0969; Mon, 24 Nov 2003 14:31:57 -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 F3F6FA09BC
	for ; Mon, 24 Nov 2003 14:31:53 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id DBA111490B; Mon, 24 Nov 2003 14:31:53 -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 6AA7314717
	for ; Mon, 24 Nov 2003 14:31:53 -0500 (EST)
Received: (qmail 13570 invoked by uid 65534); 24 Nov 2003 19:31:50 -0000
Received: from pD950C26F.dip.t-dialin.net (EHLO gmx.de) (217.80.194.111)
  by mail.gmx.net (mp009) with SMTP; 24 Nov 2003 20:31:50 +0100
X-Authenticated: #1915285
Message-ID: <3FC25C95.6070905@gmx.de>
Date: Mon, 24 Nov 2003 20:31:33 +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: Helge Hess 
Cc: "'Webdav WG'" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: WebDAV MOVE
X-Archived-At: http://www.w3.org/mid/3FC25C95.6070905@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8152
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: <20031124193157.49C46A0969@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 14:31:57 -0500 (EST)
Content-Transfer-Encoding: 7bit


Helge Hess wrote:

> the specification is a bit unclear on what we are supposed to return in 
> the case that a MOVE cannot be completed because request URL and 
> destination URL are on different servers or are on different 
> subnamespaces on a single server.
> I would expect some return value that signals to the client that the 
> URLs are on different "drives". The client could then try to implement 
> the MOVE logic on the client side (eg using PUT to dest then DELETE in 
> src).
> Any suggestions?

Right now, RFC2518 allows both -- rejecting the request, or doing a 
"best effort" approach on the server.

The BIND draft () clarifies that a client 
that really wants to move resources (keeping all live properties and 
resource-ids) can do a REBIND method call that is guaranteed to fail if 
a "real" move operation is impossible.

If a server wants to reject MOVE, that's certainly possible although 
existing clients may not be handling this very well. A 403 (Forbidden) 
seems to be the right status code in this case. It would be nice if 
there'd also be a precondition code for this case (Geoff, could we add 
that to BIND as additional MOVE semantics?).

Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 24 15:03:33 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24533
	for ; Mon, 24 Nov 2003 15:03:32 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2F0C3A053A; Mon, 24 Nov 2003 15:03: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 89971A053A
	for ; Mon, 24 Nov 2003 15:03:42 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 38DBD14243; Mon, 24 Nov 2003 15:03:42 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id E69DF1398C
	for ; Mon, 24 Nov 2003 15:03:41 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AOMvr-0001Ue-00; Mon, 24 Nov 2003 20:03:39 +0000
Received: from [64.202.9.194] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AOMvr-0001UT-00; Mon, 24 Nov 2003 20:03:39 +0000
From: "Lisa Dusseault" 
To: "'Geoffrey M Clemm'" ,
        "'Webdav WG'" 
Date: Mon, 24 Nov 2003 12:03:35 -0800
Message-ID: <007301c3b2c6$0b065920$75c990c6@lisalap>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0074_01C3B282.FCE31920"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Old-X-Envelope-To: geoffrey.clemm@us.ibm.com,
 w3c-dist-auth@w3c.org
Subject: RE: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/007301c3b2c6$0b065920$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8153
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: <20031124200346.2F0C3A053A@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 15:03:46 -0500 (EST)


This is a multi-part message in MIME format.

------=_NextPart_000_0074_01C3B282.FCE31920
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I'm not so sure about clients assuming "any resource under /".  Do
you have actual cases there?  For example, even though OPTIONS *
would return "LOCK, UNLOCK" in the Allow header for a WebDAV
Level 2 server, WebDAV clients don't necessarily assume that all
collections really support LOCK.  They can't, because for example
IIS 5.0 collections don't.  Other situations might arise when the 
principal-URL space doesn't support LOCK even if the regular 
resource space does.  So I think it's already well understood, that
OPTIONS * means only that the server may in some sub-namespace
support a feature.
 
I didn't mean to denigrate anybody making any points, valid or otherwise.
Perhaps I should be more clear: if this is a HTTP problem, it needs to be
brought up in the context of HTTP design (e.g.
http://ftp.ics.uci.edu/pub/ietf/http/).
I haven't heard HTTP implementors (and there are many, many) outside
of the WebDAV WG complain about OPTIONS *.
 
Whenever WebDAV defines OPTIONS headers or bodies, WebDAV needs
to define their behavior in OPTIONS * as well as OPTIONS /specific/uri.
How could we not define this, when clients use OPTIONS * and servers
support it?
 
Lisa
 

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Geoffrey M Clemm
Sent: Monday, November 24, 2003 10:31 AM
To: 'Webdav WG'
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)



One of the problem with "OPTIONS *" is that it is easy for 
a client to misunderstand the scope of the "server" that is 
answering the request.  Commonly, a client will assume that 
it refers to "any resource under /", but this will not be 
the case when different servers are handling different 
resources under "/". 
  
So "OPTIONS *" is reasonably well defined in simple cases 
where there is one server handling the entire web site, 
but we shouldn't be defining protocols that only work for the 
simple cases. 

Note: It doesn't particularly matter if only a "few people 
on the WebDAV mailing list" make a point, if that point is 
valid.  Most people building web servers only read the 
WebDAV mailing list infrequently, if at all, and even fewer 
of them feel comfortable or have the time to post.  So we should 
make optimal use of those that are consistent readers and 
posters. 

Cheers, 
Geoff 


Lisa wrote on 11/24/2003 01:04:57 PM:

> 
> > Note that the proposed "OPTIONS *" functionality will not 
> > work anyway. 
> > Is it worth keeping the remainder?
> 
> OPTIONS * is an HTTP feature, not a WebDAV feature that we can
> keep or throw away.  It's been there for years.  I haven't seen
> much opposition to the feature, outside of a few people on the
> WebDAV mailing list.  It's got useful semantics.
> 
> It's too bad, as Julian has pointed out in the past, that the
> Java servlet design made it difficult to add stuff to OPTIONS *.
> (It's not impossible, just difficult.  I can point to existence
> proofs that it's possible, it just requires taking over the root
> namespace with a servlet application, or doing something outside
> the servlet framework.)  To me, that argues for fixes to the 
> Java servlet functionality, not dropping an HTTP feature.  If
> Microsoft "broke" OPTIONS * in its ISAPI design, the standards
> community would not be so likely to quietly drop support for it.
> 
> Lisa
> 
> 



------=_NextPart_000_0074_01C3B282.FCE31920
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable




Message




I'm=20
not so sure about clients assuming "any resource under /". =20
Do


you=20
have actual cases there?  For example, even though OPTIONS=20
*


would=20
return "LOCK, UNLOCK" in the Allow header for a =
WebDAV


Level=20
2 server, WebDAV clients don't necessarily assume that =
all


collections really support LOCK.  They can't, because =
for=20
example


IIS=20
5.0 collections don't.  Other situations might arise when the=20



principal-URL space doesn't support LOCK even if the regular=20



resource space does.  So I think it's already well =
understood,=20
that


OPTIONS * means only that the server may in some=20
sub-namespace


support a feature.


 


I=20
didn't mean to denigrate anybody making any points, valid or=20
otherwise.


Perhaps I should be more clear: if this is a HTTP problem, it =
needs to=20
be


brought up in the context of HTTP design (e.g. http://ftp.ics.uci.edu/pub=
/ietf/http/).


I=20
haven't heard HTTP implementors (and there are many, many)=20
outside


of the=20
WebDAV WG complain about OPTIONS *.


 


Whenever WebDAV defines OPTIONS headers or bodies, WebDAV=20
needs


to=20
define their behavior in OPTIONS * as well as OPTIONS=20
/specific/uri.


How=20
could we not define this, when clients use OPTIONS * and=20
servers


support it?


 


Lisa


 


  

  
-----Original Message-----
From:=20
  w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] =
On=20
  Behalf Of Geoffrey M Clemm
Sent: Monday, November 24, =
2003 10:31=20
  AM
To: 'Webdav WG'
Subject: Re: OPTIONS * (Was: =
RE:=20
  Comments on =
draft-dusseault-http-patch-00)


One of the problem with "OPTIONS *" is that it is easy=20
  for 
a client to misunderstand the =
scope of=20
  the "server" that is 
answering the =
request.=20
   Commonly, a client will assume that 
it=20
  refers to "any resource under /", but this will not be =

the case when different servers are handling =
different=20
  
resources under "/". 
  
So "OPTIONS *" =
is=20
  reasonably well defined in simple cases 
where=20
  there is one server handling the entire web site, =

but we shouldn't be defining protocols that only work for =

  the 
simple cases. =


Note: It doesn't particularly matter if only a "few=20
  people 
on the WebDAV mailing list" =
make a=20
  point, if that point is 
valid. =
 Most=20
  people building web servers only read the 
WebDAV mailing list infrequently, if at all, and even=20
  fewer 
of them feel comfortable or =
have the=20
  time to post.  So we should 
make optimal=20
  use of those that are consistent readers and 
posters. 

Cheers,=20
  
Geoff 


Lisa wrote=20
  on 11/24/2003 01:04:57 PM:

> 
> > Note that the =
proposed=20
  "OPTIONS *" functionality will not 
> > work anyway. 
> =
> Is=20
  it worth keeping the remainder?
> 
> OPTIONS * is an HTTP =
feature,=20
  not a WebDAV feature that we can
> keep or throw away. =
 It's been=20
  there for years.  I haven't seen
> much opposition to the =
feature,=20
  outside of a few people on the
> WebDAV mailing list.  It's =
got=20
  useful semantics.
> 
> It's too bad, as Julian has pointed =
out in=20
  the past, that the
> Java servlet design made it difficult to =
add stuff=20
  to OPTIONS *.
> (It's not impossible, just difficult.  I =
can point=20
  to existence
> proofs that it's possible, it just requires =
taking over=20
  the root
> namespace with a servlet application, or doing =
something=20
  outside
> the servlet framework.)  To me, that argues for =
fixes to=20
  the 
> Java servlet functionality, not dropping an HTTP feature. =

   If
> Microsoft "broke" OPTIONS * in its ISAPI design, the=20
  standards
> community would not be so likely to quietly drop =
support for=20
  it.
> 
> Lisa
> 
>=20



------=_NextPart_000_0074_01C3B282.FCE31920--




From w3c-dist-auth-request@w3.org  Mon Nov 24 15:13:34 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 PAA25917
	for ; Mon, 24 Nov 2003 15:13:34 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EA9A7A080B; Mon, 24 Nov 2003 15:13:45 -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 40220A0840
	for ; Mon, 24 Nov 2003 15:13:42 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id D1A2D13660; Mon, 24 Nov 2003 15:13:41 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id A1CEB131CD
	for ; Mon, 24 Nov 2003 15:13:41 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AON5Y-0001Zp-00; Mon, 24 Nov 2003 20:13:40 +0000
Received: from [64.202.9.194] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AON5Y-0001Ze-00; Mon, 24 Nov 2003 20:13:40 +0000
From: "Lisa Dusseault" 
To: "'Julian Reschke'" 
Cc: "'Webdav WG'" 
Date: Mon, 24 Nov 2003 12:13:36 -0800
Message-ID: <007c01c3b2c7$713a2d60$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
In-Reply-To: <3FC252E2.7090600@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/007c01c3b2c7$713a2d60$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8154
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: <20031124201345.EA9A7A080B@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 15:13:45 -0500 (EST)
Content-Transfer-Encoding: 7bit



> "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)."

This paragraph specifically *does* say that the client can test
the capabilities of the server.  How are the RFC2518bis or PATCH 
proposals in opposition to this?


> However I feel it entirely unacceptable to add new "must" level 
> requirements (RFC2518bis, section 9.1) when
> 
> a) this contradicts RFC2616 and
> b) it clearly is impossible to implement for a generic Java servlet.
> 
> If you feel strongly about adding this to WebDAV, please discuss it 
> first. However just silently putting it in without any prior 
> discussion 
> IMHO really isn't constructive.

As you know by my disagreement, I don't see how this contradicts 
2616.  So I'm not trying to add this particular functionality to 
contradict 2616.   I've also pointed out that it's not impossible 
for an application that uses Java servlets, so I'm also not trying 
to break those applications.

As for discussion, we *are* discussing.  I-D documents *are* what
we discuss.  The IETF process is to submit proposals, that not everybody
may agree with, as I-Ds.  These are discussed and frequently change as
a result.  By the very act of publishing an Internet-Draft, I am being
anything but silent about suggested text, possible solutions, proposals,
and so on.

I appreciate your attempts to help gain consensus.  It is my opinion,
and supported by IETF practice in many working groups and by RFC 3160,
(The Tao of IETF) that publishing I-Ds with specific new proposals to 
discuss is a useful way to achieve consensus:

"Internet Drafts are tentative documents -- they're meant for readers 
to comment on, so authors can mull over those comments and decide which 
ones to incorporate in the draft."

Lisa






From w3c-dist-auth-request@w3.org  Mon Nov 24 15:14:09 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 PAA26097
	for ; Mon, 24 Nov 2003 15:14:09 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 14F4DA0887; Mon, 24 Nov 2003 15:14: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 34BBDA0887
	for ; Mon, 24 Nov 2003 15:14:21 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id C6CA613451; Mon, 24 Nov 2003 15:14:20 -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 5A1F7135CB
	for ; Mon, 24 Nov 2003 15:14:20 -0500 (EST)
Received: (qmail 5392 invoked by uid 65534); 24 Nov 2003 20:14:17 -0000
Received: from pD950C26F.dip.t-dialin.net (EHLO gmx.de) (217.80.194.111)
  by mail.gmx.net (mp010) with SMTP; 24 Nov 2003 21:14:16 +0100
X-Authenticated: #1915285
Message-ID: <3FC26681.60708@gmx.de>
Date: Mon, 24 Nov 2003 21:13:53 +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: "'Geoffrey M Clemm'" ,
        "'Webdav WG'" 
References: <007301c3b2c6$0b065920$75c990c6@lisalap>
In-Reply-To: <007301c3b2c6$0b065920$75c990c6@lisalap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/3FC26681.60708@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8155
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: <20031124201422.14F4DA0887@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 15:14:22 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I'm not so sure about clients assuming "any resource under /".  Do
> you have actual cases there?  For example, even though OPTIONS *
> would return "LOCK, UNLOCK" in the Allow header for a WebDAV
> Level 2 server, WebDAV clients don't necessarily assume that all
> collections really support LOCK.  They can't, because for example
> IIS 5.0 collections don't.  Other situations might arise when the
> principal-URL space doesn't support LOCK even if the regular
> resource space does.  So I think it's already well understood, that
> OPTIONS * means only that the server may in some sub-namespace
> support a feature.
>  
> I didn't mean to denigrate anybody making any points, valid or otherwise.
> Perhaps I should be more clear: if this is a HTTP problem, it needs to be
> brought up in the context of HTTP design (e.g. 
> http://ftp.ics.uci.edu/pub/ietf/http/).
> I haven't heard HTTP implementors (and there are many, many) outside
> of the WebDAV WG complain about OPTIONS *.

That's because

- RFC2518 doesn't require it and
- RFC2518bis has added it without any announcement whatsoever.

How would an HTTP implementor outside the WebDAV working group even 
*know* about that proposed change?

> Whenever WebDAV defines OPTIONS headers or bodies, WebDAV needs
> to define their behavior in OPTIONS * as well as OPTIONS /specific/uri.

Fine. So please define that WebDAV doesn't put any additional semantics 
on OPTIONS *.

> How could we not define this, when clients use OPTIONS * and servers
> support it?

Only some servers support it (in the way you are trying to mandate it). 
And so far, I haven't seen a client using it for anything WebDAV related 
(for the simple reason that it won't work with all servers).

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 24 15:38: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 PAA28203
	for ; Mon, 24 Nov 2003 15:38:59 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2070DA0733; Mon, 24 Nov 2003 15:39:12 -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 3968CA0733
	for ; Mon, 24 Nov 2003 15:39:05 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id B8FA913DCD; Mon, 24 Nov 2003 15:35:06 -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 4CC7613782
	for ; Mon, 24 Nov 2003 15:35:06 -0500 (EST)
Received: (qmail 3770 invoked by uid 65534); 24 Nov 2003 20:35:02 -0000
Received: from pD950C26F.dip.t-dialin.net (EHLO gmx.de) (217.80.194.111)
  by mail.gmx.net (mp016) with SMTP; 24 Nov 2003 21:35:02 +0100
X-Authenticated: #1915285
Message-ID: <3FC26B55.4060905@gmx.de>
Date: Mon, 24 Nov 2003 21:34:29 +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: <007c01c3b2c7$713a2d60$75c990c6@lisalap>
In-Reply-To: <007c01c3b2c7$713a2d60$75c990c6@lisalap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/3FC26B55.4060905@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8156
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: <20031124203912.2070DA0733@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 15:39:12 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault 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)."
> 
> 
> This paragraph specifically *does* say that the client can test
> the capabilities of the server.  How are the RFC2518bis or PATCH 
> proposals in opposition to this?

I guess it depends on the definition of the server. Fact is

- the servlet spec doesn't support that in general,
- it doesn't seem to be supported by Apache modules (OPTIONS * on 
http://test.webdav.org doesn't list any WebDAV methods) and
- it doesn't seem to work with IIS (just tried and I got a 404).

So as far as RFC2518 is concerned, there is demonstratibly *no* 
interoperability for this, and I never have heard of any client 
requiring it. Therefore it doesn't belong into RFC2518bis.

>>However I feel it entirely unacceptable to add new "must" level 
>>requirements (RFC2518bis, section 9.1) when
>>
>>a) this contradicts RFC2616 and
>>b) it clearly is impossible to implement for a generic Java servlet.
>>
>>If you feel strongly about adding this to WebDAV, please discuss it 
>>first. However just silently putting it in without any prior 
>>discussion 
>>IMHO really isn't constructive.
> 
> 
> As you know by my disagreement, I don't see how this contradicts 
> 2616.  So I'm not trying to add this particular functionality to 
> contradict 2616.   I've also pointed out that it's not impossible 
> for an application that uses Java servlets, so I'm also not trying 
> to break those applications.

It's impossible for a web application that is deployed on a standard 
servlet engine, unless it's mapped to the root (and the WebDAV WG has 
already stated that it's perfectly legal to have a WebDAV server 
implementation that doesn't control the whole namespace of a particular 
HTTP host).

> As for discussion, we *are* discussing.  I-D documents *are* what
> we discuss.  The IETF process is to submit proposals, that not everybody
> may agree with, as I-Ds.  These are discussed and frequently change as
> a result.  By the very act of publishing an Internet-Draft, I am being
> anything but silent about suggested text, possible solutions, proposals,
> and so on.
> 
> I appreciate your attempts to help gain consensus.  It is my opinion,
> and supported by IETF practice in many working groups and by RFC 3160,
> (The Tao of IETF) that publishing I-Ds with specific new proposals to 
> discuss is a useful way to achieve consensus:
> 
> "Internet Drafts are tentative documents -- they're meant for readers 
> to comment on, so authors can mull over those comments and decide which 
> ones to incorporate in the draft."

Yes. I just wish it would be easier to do that for RFC2518bis. 
Up-to-date issues/change lists would really help. The only way to spot 
this change is indeed to diff the TXT versions of the internet drafts. 
Does it really have to be that hard???

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 24 15:39: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 PAA28224
	for ; Mon, 24 Nov 2003 15:39:15 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C2949A08E6; Mon, 24 Nov 2003 15:39: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 959CBA08E6
	for ; Mon, 24 Nov 2003 15:39:15 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 3163F1426A; Mon, 24 Nov 2003 15:37:22 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id 00936137EC
	for ; Mon, 24 Nov 2003 15:37:22 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AONSS-0001o5-00; Mon, 24 Nov 2003 20:37:20 +0000
Received: from [64.202.9.194] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AONSS-0001nu-00; Mon, 24 Nov 2003 20:37:20 +0000
From: "Lisa Dusseault" 
To: "'Julian Reschke'" 
Cc: "'Geoffrey M Clemm'" ,
        "'Webdav WG'" 
Date: Mon, 24 Nov 2003 12:37:16 -0800
Message-ID: <007d01c3b2ca$bfaf9900$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
In-Reply-To: <3FC26681.60708@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Old-X-Envelope-To: geoffrey.clemm@us.ibm.com,
 julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/007d01c3b2ca$bfaf9900$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8157
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: <20031124203916.C2949A08E6@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 15:39:16 -0500 (EST)
Content-Transfer-Encoding: 7bit



> That's because
> 
> - RFC2518 doesn't require it and
> - RFC2518bis has added it without any announcement whatsoever.

Ahh, here's our disconnect.  My assumption is that RFC2518 *does* 
require OPTIONS * to work, because RFC2518 requires that RFC2616
be implemented.  It's just one of many things that are part of 
WebDAV because they're part of HTTP/1.1.  It's my reading that support
of OPTIONS * is required for HTTP/1.1 therefore it was already 
required for WebDAV.  The addition to RFC2518bis was intended to
make obvious something that I thought implementors might not notice.


> How would an HTTP implementor outside the WebDAV working group even 
> *know* about that proposed change?

First, an HTTP implementor may not need to know about WebDAV changes.
Nothing in RFC2518 or RFC2518bis affects HTTP compliance or support.

Second, it's exactly by putting proposals into Internet-Drafts that
people outside a working group can most reliably learn about them.
Internet-Draft announcements are sent to a very broad list.  I myself
sometimes read Internet-Drafts for other working groups even if I'm 
not on the mailing list for that working group.

> > Whenever WebDAV defines OPTIONS headers or bodies, WebDAV needs
> > to define their behavior in OPTIONS * as well as OPTIONS 
> /specific/uri.
> 
> Fine. So please define that WebDAV doesn't put any additional 
> semantics 
> on OPTIONS *.

That's an interesting proposal.  How would you recommend doing that? 
Would the Allow header be incomplete?  Would the DAV: header be 
*missing* on a response to OPTIONS *?  Would DeltaV elements like
'DAV:version-history-collection-set' be illegal in the OPTIONS request
body if the Request-URI were '*'?  I fear this approach would break 
existing client implementations that do use OPTIONS * to detect 
server support.

It's a valid approach to say that WebDAV doesn't use, or doesn't
need, OPTIONS *.  However, I think that approach is less consistent, 
less compliant, and less interoperable with HTTP/1.1.  I still 
prefer for WebDAV to make clear that OPTIONS * support is required.
Then perhaps we'd eventually get out of our current situation of 
servers not supporting it properly, by having them add support.

Lisa




From w3c-dist-auth-request@w3.org  Mon Nov 24 15:51:31 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28967
	for ; Mon, 24 Nov 2003 15:51:31 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B76F3A0869; Mon, 24 Nov 2003 15:51: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 4D452A096E
	for ; Mon, 24 Nov 2003 15:51:40 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 11D7513794; Mon, 24 Nov 2003 15:51:40 -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 9951C13381
	for ; Mon, 24 Nov 2003 15:51:39 -0500 (EST)
Received: (qmail 21337 invoked by uid 65534); 24 Nov 2003 20:51:33 -0000
Received: from pD950C26F.dip.t-dialin.net (EHLO gmx.de) (217.80.194.111)
  by mail.gmx.net (mp001) with SMTP; 24 Nov 2003 21:51:33 +0100
X-Authenticated: #1915285
Message-ID: <3FC26F32.6090301@gmx.de>
Date: Mon, 24 Nov 2003 21:50:58 +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: "'Geoffrey M Clemm'" ,
        "'Webdav WG'" 
References: <007d01c3b2ca$bfaf9900$75c990c6@lisalap>
In-Reply-To: <007d01c3b2ca$bfaf9900$75c990c6@lisalap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/3FC26F32.6090301@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8158
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: <20031124205144.B76F3A0869@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 15:51:44 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> Ahh, here's our disconnect.  My assumption is that RFC2518 *does* 
> require OPTIONS * to work, because RFC2518 requires that RFC2616
> be implemented.  It's just one of many things that are part of 
> WebDAV because they're part of HTTP/1.1.  It's my reading that support
> of OPTIONS * is required for HTTP/1.1 therefore it was already 
> required for WebDAV.  The addition to RFC2518bis was intended to
> make obvious something that I thought implementors might not notice.

Ok, let's assume HTTP *does* require this (IMHO that on the other hand 
should be clarified on the HTTP mailing list). In which case for 
RFC2518bis, it's our job to actually find out whether there's 
interoperability for this.

I just tried both Apache/mod_dav and our server. None of them supports 
it. On the other hand, I haven't seen any client failing because of 
this. Thus, if any clarification is required, then it's to say that 
clients can not rely on anything WebDAV specific being returned by 
OPTIONS *.

>>>Whenever WebDAV defines OPTIONS headers or bodies, WebDAV needs
>>>to define their behavior in OPTIONS * as well as OPTIONS 
>>
>>/specific/uri.
>>
>>Fine. So please define that WebDAV doesn't put any additional 
>>semantics 
>>on OPTIONS *.
> 
> 
> That's an interesting proposal.  How would you recommend doing that? 
> Would the Allow header be incomplete?  Would the DAV: header be 

It is with many existing implementations.

> *missing* on a response to OPTIONS *?  Would DeltaV elements like

Same.

> 'DAV:version-history-collection-set' be illegal in the OPTIONS request
> body if the Request-URI were '*'?  I fear this approach would break 

Yes. That's a known defect in DeltaV, therefore the marshalling through 
OPTIONS has been deprecated, and live properties have been added instead 
(see issues 5.5_OPTIONS_BODY and 5.5_USE_PROPERTIES on 
).

> existing client implementations that do use OPTIONS * to detect 
> server support.

Show me one.

> It's a valid approach to say that WebDAV doesn't use, or doesn't
> need, OPTIONS *.  However, I think that approach is less consistent, 
> less compliant, and less interoperable with HTTP/1.1.  I still 
> prefer for WebDAV to make clear that OPTIONS * support is required.
> Then perhaps we'd eventually get out of our current situation of 
> servers not supporting it properly, by having them add support.

Well. Servers not supporting it right now doesn't seem to be any 
*practical* problem. Could you please elaborate?

Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 24 16: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 QAA29944
	for ; Mon, 24 Nov 2003 16:09:04 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8208AA052F; Mon, 24 Nov 2003 16:09: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 2CC6CA052F
	for ; Mon, 24 Nov 2003 16:09:11 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id C6CFB13DBD; Mon, 24 Nov 2003 16:09:10 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.xythos.com (unknown [206.14.210.116])
	by dr-nick.w3.org (Postfix) with ESMTP id 94B4F137AE
	for ; Mon, 24 Nov 2003 16:09:10 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1AONxG-00023A-00; Mon, 24 Nov 2003 21:09:10 +0000
Received: from [64.202.9.194] (helo=lisalap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1AONxG-00022z-00; Mon, 24 Nov 2003 21:09:10 +0000
From: "Lisa Dusseault" 
To: "'Webdav WG'" , ,
        
Date: Mon, 24 Nov 2003 13:09:05 -0800
Message-ID: <008101c3b2cf$31dbab00$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
In-Reply-To: <3FC26F32.6090301@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Old-X-Envelope-To: fielding@apache.org,
 masinter@adobe.com,
 w3c-dist-auth@w3c.org
Subject: RE: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/008101c3b2cf$31dbab00$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8159
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: <20031124210916.8208AA052F@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 16:09:16 -0500 (EST)
Content-Transfer-Encoding: 7bit


Well, obviously I've been reluctant to encourage implementors
to diverge from HTTP, given my assumptions that OPTIONS * is
required in HTTP/1.1.  But if that's the general consensus, 
we need to know.  

Everybody, please consider, reply, and discuss: 

1. Does HTTP/1.1 require support for OPTIONS *?  Would a HTTP
server that considered OPTIONS * to be a "bad request" be a 
compliant HTTP/1.1 server?

2. If the answer to 1 is YES, then should WebDAV servers get 
special dispensation to leave OPTIONS * unimplemented? 

3. If the answer to 2 is NO, then should WebDAV servers be 
exempt from showing WebDAV support in OPTIONS *?  

Bonus question: Can you report on any client or server HTTP or
WebDAV implementations that do, or do not, support or use 
OPTIONS *?

It may be premature to ask these questions, if the questions are
poorly formed, but at least by asking the questions we may get
feedback about how to properly ask the questions.

Implementation report: Xythos WebFile Server *does* support OPTIONS *
(and it is java servlet based, surprise surprise).  Xythos WebFile
Client does not use OPTIONS *, but it does use "OPTIONS /".

Lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Monday, November 24, 2003 12:51 PM
> To: Lisa Dusseault
> Cc: 'Geoffrey M Clemm'; 'Webdav WG'
> Subject: Re: OPTIONS * (Was: RE: Comments on 
> draft-dusseault-http-patch-00)
> 
> 
> Lisa Dusseault wrote:
> 
> > Ahh, here's our disconnect.  My assumption is that RFC2518 *does* 
> > require OPTIONS * to work, because RFC2518 requires that RFC2616
> > be implemented.  It's just one of many things that are part of 
> > WebDAV because they're part of HTTP/1.1.  It's my reading 
> that support
> > of OPTIONS * is required for HTTP/1.1 therefore it was already 
> > required for WebDAV.  The addition to RFC2518bis was intended to
> > make obvious something that I thought implementors might not notice.
> 
> Ok, let's assume HTTP *does* require this (IMHO that on the 
> other hand 
> should be clarified on the HTTP mailing list). In which case for 
> RFC2518bis, it's our job to actually find out whether there's 
> interoperability for this.
> 
> I just tried both Apache/mod_dav and our server. None of them 
> supports 
> it. On the other hand, I haven't seen any client failing because of 
> this. Thus, if any clarification is required, then it's to say that 
> clients can not rely on anything WebDAV specific being returned by 
> OPTIONS *.
> 
> >>>Whenever WebDAV defines OPTIONS headers or bodies, WebDAV needs
> >>>to define their behavior in OPTIONS * as well as OPTIONS 
> >>
> >>/specific/uri.
> >>
> >>Fine. So please define that WebDAV doesn't put any additional 
> >>semantics 
> >>on OPTIONS *.
> > 
> > 
> > That's an interesting proposal.  How would you recommend 
> doing that? 
> > Would the Allow header be incomplete?  Would the DAV: header be 
> 
> It is with many existing implementations.
> 
> > *missing* on a response to OPTIONS *?  Would DeltaV elements like
> 
> Same.
> 
> > 'DAV:version-history-collection-set' be illegal in the 
> OPTIONS request
> > body if the Request-URI were '*'?  I fear this approach would break 
> 
> Yes. That's a known defect in DeltaV, therefore the 
> marshalling through 
> OPTIONS has been deprecated, and live properties have been 
> added instead 
> (see issues 5.5_OPTIONS_BODY and 5.5_USE_PROPERTIES on 
> ).
> 
> > existing client implementations that do use OPTIONS * to detect 
> > server support.
> 
> Show me one.
> 
> > It's a valid approach to say that WebDAV doesn't use, or doesn't
> > need, OPTIONS *.  However, I think that approach is less 
> consistent, 
> > less compliant, and less interoperable with HTTP/1.1.  I still 
> > prefer for WebDAV to make clear that OPTIONS * support is required.
> > Then perhaps we'd eventually get out of our current situation of 
> > servers not supporting it properly, by having them add support.
> 
> Well. Servers not supporting it right now doesn't seem to be any 
> *practical* problem. Could you please elaborate?
> 
> Regards, Julian
> 
> -- 
> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> 




From w3c-dist-auth-request@w3.org  Mon Nov 24 16:19:41 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 QAA00681
	for ; Mon, 24 Nov 2003 16:19:40 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 60C3EA07B4; Mon, 24 Nov 2003 16:19: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 E1170A07BA
	for ; Mon, 24 Nov 2003 16:19:48 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 7552513369; Mon, 24 Nov 2003 16:19:48 -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 B414613341
	for ; Mon, 24 Nov 2003 16:19:47 -0500 (EST)
Received: (qmail 22340 invoked by uid 65534); 24 Nov 2003 21:19:45 -0000
Received: from pD950C26F.dip.t-dialin.net (EHLO gmx.de) (217.80.194.111)
  by mail.gmx.net (mp022) with SMTP; 24 Nov 2003 22:19:45 +0100
X-Authenticated: #1915285
Message-ID: <3FC275E1.7090204@gmx.de>
Date: Mon, 24 Nov 2003 22:19:29 +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'" , fielding@apache.org,
        masinter@adobe.com
References: <008101c3b2cf$31dbab00$75c990c6@lisalap>
In-Reply-To: <008101c3b2cf$31dbab00$75c990c6@lisalap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/3FC275E1.7090204@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8160
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: <20031124211954.60C3EA07B4@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 16:19:54 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> Well, obviously I've been reluctant to encourage implementors
> to diverge from HTTP, given my assumptions that OPTIONS * is
> required in HTTP/1.1.  But if that's the general consensus, 
> we need to know.  
> 
> Everybody, please consider, reply, and discuss: 
> 
> 1. Does HTTP/1.1 require support for OPTIONS *?  Would a HTTP
> server that considered OPTIONS * to be a "bad request" be a 
> compliant HTTP/1.1 server?

1b) Would a server that does not list PROPFIND in the Allow: header for 
OPTIONS * although it does support WebDAV resources in some parts of 
it's namespace compliant?

> 2. If the answer to 1 is YES, then should WebDAV servers get 
> special dispensation to leave OPTIONS * unimplemented? 

I guess this depends of what support for "OPTIONS *" actually means, and 
this is something the HTTP mailing list can hopefully clarify.

> 3. If the answer to 2 is NO, then should WebDAV servers be 
> exempt from showing WebDAV support in OPTIONS *?  
> 
> Bonus question: Can you report on any client or server HTTP or
> WebDAV implementations that do, or do not, support or use 
> OPTIONS *?

Servers:

- Apache/mod_dav doesn't list PROPFIND in the Allow header
- Nor does Apache/Tomcat (with the default webdav servlet installation)
- Nor does SAP Enterprise Portal Server

Clients:

- none of the clients I'm aware of relies on "OPTIONS *" returning 
anything WebDAV-specific (this includes Microsoft clients, various Adobe 
clients, MacOsX, our own and others).

> It may be premature to ask these questions, if the questions are
> poorly formed, but at least by asking the questions we may get
> feedback about how to properly ask the questions.
> 
> Implementation report: Xythos WebFile Server *does* support OPTIONS *
> (and it is java servlet based, surprise surprise).  Xythos WebFile
> Client does not use OPTIONS *, but it does use "OPTIONS /".

Re: "OPTIONS /"? What does it use it for? Seems to be nothing essential, 
otherwise it wouldn't work with our server (which it does).

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Nov 24 18:24:43 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10719
	for ; Mon, 24 Nov 2003 18:24:42 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C3951A0911; Mon, 24 Nov 2003 18:24: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 5DDC0A0A28
	for ; Mon, 24 Nov 2003 18:24:50 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id CD6231348C; Mon, 24 Nov 2003 18:23:22 -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 B448113484
	for ; Mon, 24 Nov 2003 18:23:22 -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 hAONNMDA382028
	for ; Mon, 24 Nov 2003 18:23:22 -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 hAONNLDT103958
	for ; Mon, 24 Nov 2003 18:23:21 -0500
In-Reply-To: <3FC26B55.4060905@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: Mon, 24 Nov 2003 18:23:27 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 11/24/2003 18:23:21,
	Serialize complete at 11/24/2003 18:23:21
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/OF53CC5596.E5FED19A-ON85256DE8.007FA124-85256DE8.00807DA2@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8161
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: <20031124232455.C3951A0911@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 18:24:55 -0500 (EST)


Julian wrote on 11/24/2003 03:34:29 PM:

> Lisa Dusseault wrote:
> > I appreciate your attempts to help gain consensus.  It is my opinion,
> > and supported by IETF practice in many working groups and by RFC 3160,
> > (The Tao of IETF) that publishing I-Ds with specific new proposals to 
> > discuss is a useful way to achieve consensus:
> 
> Yes. I just wish it would be easier to do that for RFC2518bis. 
> Up-to-date issues/change lists would really help. The only way to spot 
> this change is indeed to diff the TXT versions of the internet drafts. 
> Does it really have to be that hard???

I vigorously agree with Julian here.  Each significant change (addition,
deletion, modification) to RFC2518bis should be preceded by an
email with that proposed change, and then should be documented in the 
issues
list with a pointer to that email message(and marked as OPEN, until
the change has been accepted by consensus, or at least, if no objections
have been raised in a reasonable period of time).

A new revision of the I-D is a good way to see the proposed change in
context, but just publishing the draft is not an effective way to
announce or achieve consensus on a set of changes.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Nov 24 19:01:52 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 TAA12435
	for ; Mon, 24 Nov 2003 19:01:51 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5BFE4A0683; Mon, 24 Nov 2003 19:02: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 0B3D8A06DC
	for ; Mon, 24 Nov 2003 19:02:01 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id B07EA13362; Mon, 24 Nov 2003 19:02:00 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from smtp-relay-8.adobe.com (smtp-relay-8.adobe.com [192.150.22.8])
	by dr-nick.w3.org (Postfix) with ESMTP
	id 5BE651335C; Mon, 24 Nov 2003 19:02:00 -0500 (EST)
Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51])
	by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id hAP01RZS013801;
	Mon, 24 Nov 2003 16:01:32 -0800 (PST)
Received: from mailsjtest (mailsj [153.32.1.135])
	by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id hAP01RGl013377;
	Mon, 24 Nov 2003 16:01:27 -0800 (PST)
Received: from MasinterT40 (c-67-195.corp.adobe.com [153.32.67.195])
 by mailsjtest.corp.adobe.com
 (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002))
 with ESMTP id <0HOV00G4JS33EV@mailsjtest.corp.adobe.com>; Mon,
 24 Nov 2003 16:01:51 -0800 (PST)
Date: Mon, 24 Nov 2003 16:01:26 -0800
From: Larry Masinter 
In-reply-to: <008101c3b2cf$31dbab00$75c990c6@lisalap>
To: "'Lisa Dusseault'" ,
        "'Webdav WG'" 
Cc: ietf-http-wg@w3c.org
Message-id: <009f01c3b2e7$4577e260$c3432099@MasinterT40>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Subject: RE: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/009f01c3b2e7$4577e260$c3432099@MasinterT40
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8162
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: <20031125000205.5BFE4A0683@frink.w3.org>
Resent-Date: Mon, 24 Nov 2003 19:02:05 -0500 (EST)
Content-Transfer-Encoding: 7BIT


> 1. Does HTTP/1.1 require support for OPTIONS *?  Would a HTTP
> server that considered OPTIONS * to be a "bad request" be a 
> compliant HTTP/1.1 server?

I think the wording in RFC 2616 is unclear about requiring
that servers implement OPTIONS *. There's no explicit
language to that effect, but it does say (9.2 para 4):

   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?).


For a response, '501 Not Implemented' seems better than
'400 Bad Request'.


> 2. If the answer to 1 is YES, then should WebDAV servers get 
> special dispensation to leave OPTIONS * unimplemented? 

I'm not in favor of giving 'WebDAV servers' special dispensation.

> 3. If the answer to 2 is NO, then should WebDAV servers be 
> exempt from showing WebDAV support in OPTIONS *?  

Yes, for the reason of the above paragraph "a server's communication
 options typically depend on the resource".




From w3c-dist-auth-request@w3.org  Tue Nov 25 03:31: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 DAA08350
	for ; Tue, 25 Nov 2003 03:31:02 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1ED71A0AE9; Tue, 25 Nov 2003 03:31: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 950B7A0AFC
	for ; Tue, 25 Nov 2003 03:31:01 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id B519D135B8; Tue, 25 Nov 2003 03:28:44 -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 48453135B7
	for ; Tue, 25 Nov 2003 03:28:44 -0500 (EST)
Received: (qmail 8913 invoked by uid 65534); 25 Nov 2003 08:28:42 -0000
Received: from pD950C26F.dip.t-dialin.net (EHLO gmx.de) (217.80.194.111)
  by mail.gmx.net (mp012) with SMTP; 25 Nov 2003 09:28:42 +0100
X-Authenticated: #1915285
Message-ID: <3FC312AB.7060203@gmx.de>
Date: Tue, 25 Nov 2003 09:28:27 +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: ietf-http-wg@w3.org, w3c-dist-auth@w3c.org
References:   <3FC2859D.4070504@gmx.de> 
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/3FC312AB.7060203@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8163
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: <20031125083114.1ED71A0AE9@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 03:31:14 -0500 (EST)
Content-Transfer-Encoding: 7bit


Alex Rousskov wrote:

>>I think it would be nice if the spec would clarify what "supported
>>in general" means... Specifically for the "Allow" header: does it
>>mean
>>
>>- the methods listed in the Allow header are supported by all resources?
>>- methods not listed in the Allow header aren't supported by any resource?
>>- something else...?
> 
> 
> While "supported by all resources" sounds logical, I suspect the true
> intent was to use "*" for things that are not resource-dependent at
> all (e.g., server ability to server N concurrent clients or switch to
> non-TCP transport). In other words, there should not be any Allow
> header returned for OPTIONS *.

That would be my interpretation as well, but I think the wording of 
RFC2616 is really too vague here.

> I doubt it is possible to formally define what * is referring to
> because HTTP does not have a definition of a "server" that is suitable
> for this context. Such a definition would be outside of the
> communication protocol scope. Essentially, the definition of "*" or
> "server" in this context is implementation/environment dependent.

Yes.

> It is potentially useful for announcing support for custom server
> features _not_ documented in RFC 2616. The documentation for such a
> feature would define exactly what to include in or expect from an
> "OPTIONS *" response. I bet somebody out there is using it for such
> custom purposes.

Well, that's what got us here (WebDAV using it for that). However the 
issue here is that the "OPTIONS *" request in reality get's never passed 
to the various 'modules' inside a server that would need to be able to 
respond it (for instance neither Apache/mod_dav nor Tomcat/Webdav 
servlet set the special "DAV:" response header defined for OPTIONS in 
RFC2518).

Any chance to get that onto the RFC2616 issues list?

Regards, Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov 25 06:18: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 GAA12890
	for ; Tue, 25 Nov 2003 06:18:14 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8E51EA054C; Tue, 25 Nov 2003 06:18: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 5373CA054F
	for ; Tue, 25 Nov 2003 06:18:18 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id DDF091388F; Tue, 25 Nov 2003 06:18:17 -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 722ED136B8
	for ; Tue, 25 Nov 2003 06:18:17 -0500 (EST)
Received: (qmail 9801 invoked by uid 65534); 25 Nov 2003 11:18:17 -0000
Received: from mail.greenbytes.de (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp014) with SMTP; 25 Nov 2003 12:18:17 +0100
X-Authenticated: #1915285
Message-ID: <3FC33A77.2050602@gmx.de>
Date: Tue, 25 Nov 2003 12:18:15 +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: "'www-webdav-dasl@w3.org'" , w3c-dist-auth@w3c.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Format of DAV:get* properties
X-Archived-At: http://www.w3.org/mid/3FC33A77.2050602@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8164
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: <20031125111824.8E51EA054C@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 06:18:24 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

I was just trying to come up with a DAV:basicsearch query that would 
match on the DAV:getcontenttype property (instead of making assumptions 
about file names).

However, a combination of

- complex media type syntax 
(),
- HTTP white space handling in headers and
- deficiencies in the DAV:like operator

makes this *really* hard. To illustrate the problem, all of the 
following are legal values for the HTTP content-type header for a 
"text/plain" resource:

1) "text/plain"

2) "text/plain; charset=UTF-8"

3) "text/plain ; charset=UTF-8"

4) "text/plain;\tcharset=UTF-8"

5) "text/plain\r\n\t;charset=UTF8"

(where \r, \n and \t are CR, LF and HT).

If we add linear white space at the start of the attribute value, things 
get even more complicated.

One way to approach this issue is to find out whether existing DAV 
servers indeed use all these variants, or whether in practice only 
single SPs appear as whitespace (which would make sense in 
DAV:getcontenttype). In that case, we'd only need to consider variants 
1...3.

Alternatively, the SEARCH spec could state that matching on DAV:get* 
headers occurs after whitespace normalization.

In both cases, a match for "text/plain" could be expressed as:

(DAV:getcontenttype LIKE "text/plain") OR (DAV:getcontenttype LIKE 
"text/plain %") OR (DAV:getcontenttype LIKE "text/plain;%")

This is still ugly, but if we add that as example to the spec, servers 
may be able to optimize this case internally.

An alternative would be to add a specific operator that specializes on 
matching media types minus parameters, such as


   text
   plain<


where both child elements would be optional and probably use LIKE syntax 
(in caseless mode).

Feedback appreciated,

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760




From w3c-dist-auth-request@w3.org  Tue Nov 25 08:57: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 IAA17587
	for ; Tue, 25 Nov 2003 08:57:42 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1561AA080C; Tue, 25 Nov 2003 08:57: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 1C51DA080C
	for ; Tue, 25 Nov 2003 08:57:50 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id C9B1613901; Tue, 25 Nov 2003 08:57:49 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by dr-nick.w3.org (Postfix) with ESMTP
	id A7EC4138FE; Tue, 25 Nov 2003 08:57:49 -0500 (EST)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id hAPDvnAv489968;
	Tue, 25 Nov 2003 08:57:49 -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 hAPDvJTq091288;
	Tue, 25 Nov 2003 08:57:47 -0500
In-Reply-To: <009f01c3b2e7$4577e260$c3432099@MasinterT40>
To: ietf-http-wg@w3c.org, "'Webdav WG'" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: 
From: Geoffrey M Clemm 
Date: Tue, 25 Nov 2003 08:42:39 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 11/25/2003 08:57:48,
	Serialize complete at 11/25/2003 08:57:48
Content-Type: multipart/alternative; boundary="=_alternative 004B4CDC85256DE9_="
Subject: RE: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)
X-Archived-At: http://www.w3.org/mid/OF96854298.D18DB623-ON85256DE9.004AC625-85256DE9.004B4CDF@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8165
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: <20031125135755.1561AA080C@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 08:57:55 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 004B4CDC85256DE9_=
Content-Type: text/plain; charset="US-ASCII"

Larry wrote on 11/24/2003 07:01:26 PM:

> > 3. ... should WebDAV servers be 
> > exempt from showing WebDAV support in OPTIONS *? 
> 
> Yes, for the reason of the above paragraph "a server's communication
>  options typically depend on the resource".

I think Larry has identified the key point here.  We should not be
using OPTIONS to communicate resource-dependent information.  So if
the support for a method depends on what resource it
is being applied to (which it usually does), then we should not be 
marshalling
this information via "OPTIONS *", but rather by applying the query
to the appropriate resource.

Cheers,
Geoff

--=_alternative 004B4CDC85256DE9_=
Content-Type: text/html; charset="US-ASCII"



Larry wrote on 11/24/2003 07:01:26 PM:



> > 3. ... should WebDAV servers be 

> > exempt from showing WebDAV support in OPTIONS *?  

> 

> Yes, for the reason of the above paragraph "a server's communication

>  options typically depend on the resource".



I think Larry has identified the key point here.  We
should not be

using OPTIONS to communicate resource-dependent information.
 So if

the support for a method depends on what resource
it

is being applied to (which it usually does), then
we should not be marshalling

this information via "OPTIONS *", but rather
by applying the query

to the appropriate resource.



Cheers,

Geoff


--=_alternative 004B4CDC85256DE9_=--



From w3c-dist-auth-request@w3.org  Tue Nov 25 09:04: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 JAA17835
	for ; Tue, 25 Nov 2003 09:04:25 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1898BA0946; Tue, 25 Nov 2003 09:04: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 821D2A0946
	for ; Tue, 25 Nov 2003 09:04:24 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 1353313933; Tue, 25 Nov 2003 09:02:26 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105])
	by dr-nick.w3.org (Postfix) with ESMTP id E8E691391C
	for ; Tue, 25 Nov 2003 09:02:25 -0500 (EST)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAPE2P9n187904
	for ; Tue, 25 Nov 2003 09:02:25 -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 hAPE2OTY098168
	for ; Tue, 25 Nov 2003 09:02:24 -0500
In-Reply-To: <3FC25C95.6070905@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: Tue, 25 Nov 2003 09:02:20 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 11/25/2003 09:02:25,
	Serialize complete at 11/25/2003 09:02:25
Content-Type: multipart/alternative; boundary="=_alternative 004D1A4385256DE9_="
Subject: Re: WebDAV MOVE
X-Archived-At: http://www.w3.org/mid/OF69D8148A.583D3988-ON85256DE9.004C52A1-85256DE9.004D1A45@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8166
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: <20031125140437.1898BA0946@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 09:04:37 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 004D1A4385256DE9_=
Content-Type: text/plain; charset="US-ASCII"

I'm not sure what the benefit would be of this additional error
code for MOVE.  If the client wants to try COPY/DELETE as an
alternative to MOVE, then it should do so.  I don't see that 
the clients decision to do so would be affected by a special
error code here.

Cheers,
Geoff

Julian wrote on 11/24/2003 02:31:33 PM:
> Helge Hess wrote:
> 
> > the specification is a bit unclear on what we are supposed to return 
in 
> > the case that a MOVE cannot be completed because request URL and 
> > destination URL are on different servers or are on different 
> > subnamespaces on a single server.
> > I would expect some return value that signals to the client that the 
> > URLs are on different "drives". The client could then try to implement 

> > the MOVE logic on the client side (eg using PUT to dest then DELETE in 

> > src).
> > Any suggestions?
> 
> Right now, RFC2518 allows both -- rejecting the request, or doing a 
> "best effort" approach on the server.
> 
> The BIND draft () clarifies that a client 
> that really wants to move resources (keeping all live properties and 
> resource-ids) can do a REBIND method call that is guaranteed to fail if 
> a "real" move operation is impossible.
> 
> If a server wants to reject MOVE, that's certainly possible although 
> existing clients may not be handling this very well. A 403 (Forbidden) 
> seems to be the right status code in this case. It would be nice if 
> there'd also be a precondition code for this case (Geoff, could we add 
> that to BIND as additional MOVE semantics?).

--=_alternative 004D1A4385256DE9_=
Content-Type: text/html; charset="US-ASCII"



I'm not sure what the benefit would be of this additional
error

code for MOVE.  If the client wants to try COPY/DELETE
as an

alternative to MOVE, then it should do so.  I
don't see that 

the clients decision to do so would be affected by
a special

error code here.



Cheers,

Geoff



Julian wrote on 11/24/2003 02:31:33 PM:

> Helge Hess wrote:

> 

> > the specification is a bit unclear on what we are supposed to
return in 

> > the case that a MOVE cannot be completed because request URL
and 

> > destination URL are on different servers or are on different


> > subnamespaces on a single server.

> > I would expect some return value that signals to the client that
the 

> > URLs are on different "drives". The client could then
try to implement 

> > the MOVE logic on the client side (eg using PUT to dest then
DELETE in 

> > src).

> > Any suggestions?

> 

> Right now, RFC2518 allows both -- rejecting the request, or doing
a 

> "best effort" approach on the server.

> 

> The BIND draft (<http://wwww.webdav.org/bind>) clarifies that
a client 

> that really wants to move resources (keeping all live properties and


> resource-ids) can do a REBIND method call that is guaranteed to fail
if 

> a "real" move operation is impossible.

> 

> If a server wants to reject MOVE, that's certainly possible although


> existing clients may not be handling this very well. A 403 (Forbidden)


> seems to be the right status code in this case. It would be nice if


> there'd also be a precondition code for this case (Geoff, could we
add 

> that to BIND as additional MOVE semantics?).


--=_alternative 004D1A4385256DE9_=--



From w3c-dist-auth-request@w3.org  Tue Nov 25 09:51:28 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 JAA19586
	for ; Tue, 25 Nov 2003 09:51:28 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id CB311A0552; Tue, 25 Nov 2003 09:51: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 210D2A05D8
	for ; Tue, 25 Nov 2003 09:51:34 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 3EA0B133BC; Tue, 25 Nov 2003 09:51:22 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34])
	by dr-nick.w3.org (Postfix) with ESMTP id 1C6F81363A
	for ; Tue, 25 Nov 2003 09:51:22 -0500 (EST)
Received: from [213.187.82.59] (unknown [213.187.82.59])
	by mail.mdlink.net (Postfix) with ESMTP
	id 1AFB61FC27D; Tue, 25 Nov 2003 15:48:05 +0100 (CET)
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: 
Content-Transfer-Encoding: quoted-printable
Cc: "'Webdav WG'" 
From: Helge Hess 
Date: Tue, 25 Nov 2003 15:51:17 +0100
To: Geoffrey M Clemm 
X-Mailer: Apple Mail (2.606)
Subject: Re: WebDAV MOVE
X-Archived-At: http://www.w3.org/mid/D30AF431-1F56-11D8-9250-000393C29C2A@opengroupware.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8167
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: <20031125145140.CB311A0552@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 09:51:40 -0500 (EST)
Content-Transfer-Encoding: quoted-printable


On 25.11.2003, at 15:02, Geoffrey M Clemm wrote:
> I'm not sure what the benefit would be of this additional error
> code for MOVE. =A0If the client wants to try COPY/DELETE as an
> alternative to MOVE, then it should do so. =A0I don't see that
> the clients decision to do so would be affected by a special
> error code here.

[maybe we got the method wrong, of course COPY suffers the same issue!=20=

the alternative to MOVE is GET/PUT/DELETE, not COPY/DELETE]

Well, MOVE is usually a cheap operation on the server and on the=20
network while PUT is expensive on the network. So I would assume=20
(without having thought through everything, I have to admit), that a=20
code which signals the client why it couldn't perform the operation=20
would be quite useful (something like out-of-the-namespace-I-process).
With the Forbidden code we do not know whether the request was rejected=20=

because of access restrictions or just because it is located on a=20
different server, right?

Note that I'm assuming that a server is usually "dumb" and will not try=20=

to act as a proxy with regards to the other namespace (if it does we do=20=

have the 502 code to detect errors, if I remember right).

Doesn't make sense?

regards,
   Helge
--=20
I'm describing in a paragraph what took 14 hours to figure out. You may=20=

want to sniff glue for a while, then reread this when you get out of=20
rehab. [aLa]



From w3c-dist-auth-request@w3.org  Tue Nov 25 10:32:12 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 KAA23045
	for ; Tue, 25 Nov 2003 10:32:12 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E85E0A050B; Tue, 25 Nov 2003 10:32: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 95110A050B
	for ; Tue, 25 Nov 2003 10:32:19 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id EA95513599; Tue, 25 Nov 2003 10:32:18 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102])
	by dr-nick.w3.org (Postfix) with ESMTP id BF647133D0
	for ; Tue, 25 Nov 2003 10:32:18 -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 hAPFWFd6215762;
	Tue, 25 Nov 2003 10:32:15 -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 hAPFW7TZ108720;
	Tue, 25 Nov 2003 10:32:14 -0500
In-Reply-To: 
To: Helge Hess 
Cc: "'Webdav WG'" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: 
From: Geoffrey M Clemm 
Date: Tue, 25 Nov 2003 10:32:03 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 11/25/2003 10:32:14,
	Serialize complete at 11/25/2003 10:32:14
Content-Type: multipart/alternative; boundary="=_alternative 005550F885256DE9_="
Subject: Re: WebDAV MOVE
X-Archived-At: http://www.w3.org/mid/OF10C75B0B.B73E04D1-ON85256DE9.00543A57-85256DE9.005550FA@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8168
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: <20031125153223.E85E0A050B@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 10:32:23 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 005550F885256DE9_=
Content-Type: text/plain; charset="US-ASCII"

There are 3 obvious alternatives to move one set of resources
to another location:
- MOVE (cheap, least likely to work)
- COPY/DELETE (more expensive, more likely to work)
- PUT*/DELETE (most expensive, most likely to work)

So a client that cares about efficiency will try these three
methods in the above order, until one succeeds.  So what use
would it be for a server to say "out of the namespace I process"?
The client will try the next method in either case.

So is there anything that a server can do to expedite this
sequence?  The only thing I can think of is to have the
server have a special error code for MOVE that says "don't try to fake
MOVE with COPY or PUT*, because I know those will also fail"
and a special code for COPY that says "don't try to fake copy
with PUT*, because I know that will also fail".

But I think the likelihood that the MOVE or COPY implementation
will know this is small, and the benefit of skipping those
attempts is also small, so the overall benefit is very small.

Cheers,
Geoff


Helge Hess  wrote on 11/25/2003 09:51:17 AM:

> On 25.11.2003, at 15:02, Geoffrey M Clemm wrote:
> > I'm not sure what the benefit would be of this additional error
> > code for MOVE.  If the client wants to try COPY/DELETE as an
> > alternative to MOVE, then it should do so.  I don't see that
> > the clients decision to do so would be affected by a special
> > error code here.
> 
> [maybe we got the method wrong, of course COPY suffers the same issue! 
> the alternative to MOVE is GET/PUT/DELETE, not COPY/DELETE]
> 
> Well, MOVE is usually a cheap operation on the server and on the 
> network while PUT is expensive on the network. So I would assume 
> (without having thought through everything, I have to admit), that a 
> code which signals the client why it couldn't perform the operation 
> would be quite useful (something like out-of-the-namespace-I-process).
> With the Forbidden code we do not know whether the request was rejected 
> because of access restrictions or just because it is located on a 
> different server, right?
> 
> Note that I'm assuming that a server is usually "dumb" and will not try 
> to act as a proxy with regards to the other namespace (if it does we do 
> have the 502 code to detect errors, if I remember right).
> 
> Doesn't make sense?
> 
> regards,
>    Helge
> -- 
> I'm describing in a paragraph what took 14 hours to figure out. You may 
> want to sniff glue for a while, then reread this when you get out of 
> rehab. [aLa]
> 

--=_alternative 005550F885256DE9_=
Content-Type: text/html; charset="US-ASCII"



There are 3 obvious alternatives to move one set of
resources

to another location:

- MOVE (cheap, least likely to work)

- COPY/DELETE (more expensive, more likely to work)

- PUT*/DELETE (most expensive, most likely to work)



So a client that cares about efficiency will try these
three

methods in the above order, until one succeeds.  So
what use

would it be for a server to say "out of the namespace
I process"?

The client will try the next method in either case.



So is there anything that a server can do to expedite
this

sequence?  The only thing I can think of is to
have the

server have a special error code for MOVE that says
"don't try to fake

MOVE with COPY or PUT*, because I know those will
also fail"

and a special code for COPY that says "don't
try to fake copy

with PUT*, because I know that will also fail".



But I think the likelihood that the MOVE or COPY implementation

will know this is small, and the benefit of skipping
those

attempts is also small, so the overall benefit is
very small.



Cheers,

Geoff





Helge Hess <helge.hess@opengroupware.org> wrote
on 11/25/2003 09:51:17 AM:



> On 25.11.2003, at 15:02, Geoffrey M Clemm wrote:

> > I'm not sure what the benefit would be of this additional error

> > code for MOVE.  If the client wants to try COPY/DELETE as
an

> > alternative to MOVE, then it should do so.  I don't see
that

> > the clients decision to do so would be affected by a special

> > error code here.

> 

> [maybe we got the method wrong, of course COPY suffers the same issue!


> the alternative to MOVE is GET/PUT/DELETE, not COPY/DELETE]

> 

> Well, MOVE is usually a cheap operation on the server and on the 

> network while PUT is expensive on the network. So I would assume 

> (without having thought through everything, I have to admit), that
a 

> code which signals the client why it couldn't perform the operation


> would be quite useful (something like out-of-the-namespace-I-process).

> With the Forbidden code we do not know whether the request was rejected


> because of access restrictions or just because it is located on a


> different server, right?

> 

> Note that I'm assuming that a server is usually "dumb" and
will not try 

> to act as a proxy with regards to the other namespace (if it does
we do 

> have the 502 code to detect errors, if I remember right).

> 

> Doesn't make sense?

> 

> regards,

>    Helge

> -- 

> I'm describing in a paragraph what took 14 hours to figure out. You
may 

> want to sniff glue for a while, then reread this when you get out
of 

> rehab. [aLa]

> 


--=_alternative 005550F885256DE9_=--



From w3c-dist-auth-request@w3.org  Tue Nov 25 10:55: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 KAA24368
	for ; Tue, 25 Nov 2003 10:55:05 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 14695A09ED; Tue, 25 Nov 2003 10:54: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 D69A0A09ED
	for ; Tue, 25 Nov 2003 10:54:14 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 68FC8139F0; Tue, 25 Nov 2003 10:47:51 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34])
	by dr-nick.w3.org (Postfix) with ESMTP id 28F2C139ED
	for ; Tue, 25 Nov 2003 10:47:51 -0500 (EST)
Received: from [213.187.82.59] (unknown [213.187.82.59])
	by mail.mdlink.net (Postfix) with ESMTP
	id DFBF41FC184; Tue, 25 Nov 2003 16:44:36 +0100 (CET)
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: 
Content-Transfer-Encoding: quoted-printable
Cc: "'Webdav WG'" 
From: Helge Hess 
Date: Tue, 25 Nov 2003 16:47:49 +0100
To: Geoffrey M Clemm 
X-Mailer: Apple Mail (2.606)
Subject: Re: WebDAV MOVE
X-Archived-At: http://www.w3.org/mid/B8ACE104-1F5E-11D8-9250-000393C29C2A@opengroupware.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8169
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: <20031125155427.14695A09ED@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 10:54:27 -0500 (EST)
Content-Transfer-Encoding: quoted-printable


On 25.11.2003, at 16:32, Geoffrey M Clemm wrote:
> There are 3 obvious alternatives to move one set of resources
> to another location:
> - MOVE (cheap, least likely to work)
> - COPY/DELETE (more expensive, more likely to work)
> - PUT*/DELETE (most expensive, most likely to work)
>
> So a client that cares about efficiency will try these three
> methods in the above order, until one succeeds. =A0So what use
> would it be for a server to say "out of the namespace I process"?

So that the client knows that he should continue with COPY. If the=20
client has no read access to the resource to be moved (access is 403=20
Forbidden!), it doesn't make sense to continue?!
On the other side you are right, the client will find out about that in=20=

the last option, GET - if this returns Forbidden, we know that it is=20
really an access issue.

> The client will try the next method in either case.

Well, if the server says that access to the resource is forbidden, I as=20=

the client, would not try the next method.

> So is there anything that a server can do to expedite this
> sequence? =A0The only thing I can think of is to have the
> server have a special error code for MOVE that says "don't try to fake
> MOVE with COPY or PUT*, because I know those will also fail"
> and a special code for COPY that says "don't try to fake copy
> with PUT*, because I know that will also fail".

Well, this is 403 (Access) Forbidden ;-) Using that access status code=20=

to signal some technically completely different issue (the resource=20
cannot be moved on the server side due to operational restrictions)=20
seems a bit weird to me.
But if I'm supposed to do it that way, I do.

BTW: another status which might be somewhat appropriate from the=20
semantics is 501, Not Implemented. But this probably implies in the=20
client that the whole method is not implemented which isn't what we=20
want either.

> But I think the likelihood that the MOVE or COPY implementation
> will know this is small, and the benefit of skipping those
> attempts is also small, so the overall benefit is very small.

Well, I think that this is the common case. MOVE will usually map the=20
URI to some internal storage URL, eg

   /publicstorage/image.gif         to mod_dav /image.gif
   /dynamicservice/GroupwareFolder/ to servlet /GroupwareFolder

and this mapping process will know whether source and target are going=20=

to be processed by the same service.

Anyway, no intention to start a huge discussion on that. If there is no=20=

other way, I simply return 403 - I just wanted to make sure that I'm=20
not missing something in the WebDAV spec.

regards,
   Helge
--=20
I'm describing in a paragraph what took 14 hours to figure out. You may=20=

want to sniff glue for a while, then reread this when you get out of=20
rehab. [aLa]



From w3c-dist-auth-request@w3.org  Tue Nov 25 11:20:35 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25115
	for ; Tue, 25 Nov 2003 11:20:34 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BA7BCA07A1; Tue, 25 Nov 2003 11:20: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 C80CDA07A1
	for ; Tue, 25 Nov 2003 11:20:42 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 5B06E133EB; Tue, 25 Nov 2003 11:20:42 -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 4092E133A9
	for ; Tue, 25 Nov 2003 11:20:37 -0500 (EST)
Received: (qmail 479 invoked by uid 65534); 25 Nov 2003 16:20:36 -0000
Received: from mail.greenbytes.de (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp003) with SMTP; 25 Nov 2003 17:20:36 +0100
X-Authenticated: #1915285
Message-ID: <3FC38153.7060705@gmx.de>
Date: Tue, 25 Nov 2003 17:20:35 +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: ietf-http-wg@w3.org, w3c-dist-auth@w3c.org
References:   <3FC2859D.4070504@gmx.de>  <3FC312AB.7060203@gmx.de> 
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/3FC38153.7060705@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8170
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: <20031125162046.BA7BCA07A1@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 11:20:46 -0500 (EST)
Content-Transfer-Encoding: 7bit


Alex Rousskov wrote:
> On Tue, 25 Nov 2003, Julian Reschke wrote:
> 
> 
>>the issue here is that the "OPTIONS *" request in reality get's
>>never passed to the various 'modules' inside a server that would
>>need to be able to respond it (for instance neither Apache/mod_dav
>>nor Tomcat/Webdav servlet set the special "DAV:" response header
>>defined for OPTIONS in RFC2518).
>>
>>Any chance to get that onto the RFC2616 issues list?
> 
> 
> In my experience, you need to convince one of the original authors or
> anybody Scott Lawrence trusts that a certain change is warranted. If
> you succeed, the change will be posted to
> http://purl.org/NET/http-errata with a link to the discussion on the
> list.
> 
> The change does not have to be an "errata" or "issue" with the
> protocol itself.
> 
> Your best bet is probably to post a specific wording to this list and
> wait for a reaction.

OK, that sounds reasonable. Maybe we can come up with a good replacement 
text.

Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov 25 12:42: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 MAA29032
	for ; Tue, 25 Nov 2003 12:42:04 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 6EC52A0502; Tue, 25 Nov 2003 12:41:20 -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 6052FA0502
	for ; Tue, 25 Nov 2003 12:41:12 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 36CF713955; Tue, 25 Nov 2003 12:41:12 -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 E068D13836
	for ; Tue, 25 Nov 2003 12:41:11 -0500 (EST)
Received: from lisalap ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 25 Nov 2003 09:41:10 -0800
From: "Lisa Dusseault" 
To: "'Julian Reschke'" , ,
        
Date: Tue, 25 Nov 2003 09:41:05 -0800
Message-ID: <001501c3b37b$4ee3ff20$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
In-Reply-To: <3FC33A77.2050602@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 25 Nov 2003 17:41:10.0108 (UTC) FILETIME=[5000B9C0:01C3B37B]
Subject: RE: Format of DAV:get* properties
X-Archived-At: http://www.w3.org/mid/001501c3b37b$4ee3ff20$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8171
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: <20031125174120.6EC52A0502@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 12:41:20 -0500 (EST)
Content-Transfer-Encoding: 7bit


This hasn't been a problem in the WFS implementation.  The unusual
formatting is rare, and so users can generally search on "contains 
'text/plain'" and get all the results they need.  Sometimes it's 
not worth dealing with edge cases in a spec, beyond noting that 
they exist and noting that servers can easily normalize the value
to reduce the existence of edge cases.

However, I'm not sure how much of an edge case it is.  If it's been
a problem in practice, the 'media-type-match' syntax seems to be an
elegant and effective way to deal with it.

Lisa

> -----Original Message-----
> From: www-webdav-dasl-request@w3.org 
> [mailto:www-webdav-dasl-request@w3.org] On Behalf Of Julian Reschke
> Sent: Tuesday, November 25, 2003 3:18 AM
> To: 'www-webdav-dasl@w3.org'; w3c-dist-auth@w3c.org
> Subject: Format of DAV:get* properties
> 
> 
> 
> Hi,
> 
> I was just trying to come up with a DAV:basicsearch query that would 
> match on the DAV:getcontenttype property (instead of making 
> assumptions 
> about file names).
> 
> However, a combination of
> 
> - complex media type syntax 
> (),
> - HTTP white space handling in headers and
> - deficiencies in the DAV:like operator
> 
> makes this *really* hard. To illustrate the problem, all of the 
> following are legal values for the HTTP content-type header for a 
> "text/plain" resource:
> 
> 1) "text/plain"
> 
> 2) "text/plain; charset=UTF-8"
> 
> 3) "text/plain ; charset=UTF-8"
> 
> 4) "text/plain;\tcharset=UTF-8"
> 
> 5) "text/plain\r\n\t;charset=UTF8"
> 
> (where \r, \n and \t are CR, LF and HT).
> 
> If we add linear white space at the start of the attribute 
> value, things 
> get even more complicated.
> 
> One way to approach this issue is to find out whether existing DAV 
> servers indeed use all these variants, or whether in practice only 
> single SPs appear as whitespace (which would make sense in 
> DAV:getcontenttype). In that case, we'd only need to consider 
> variants 
> 1...3.
> 
> Alternatively, the SEARCH spec could state that matching on DAV:get* 
> headers occurs after whitespace normalization.
> 
> In both cases, a match for "text/plain" could be expressed as:
> 
> (DAV:getcontenttype LIKE "text/plain") OR (DAV:getcontenttype LIKE 
> "text/plain %") OR (DAV:getcontenttype LIKE "text/plain;%")
> 
> This is still ugly, but if we add that as example to the 
> spec, servers 
> may be able to optimize this case internally.
> 
> An alternative would be to add a specific operator that 
> specializes on 
> matching media types minus parameters, such as
> 
> 
>    text
>    plain<
> 
> 
> where both child elements would be optional and probably use 
> LIKE syntax 
> (in caseless mode).
> 
> Feedback appreciated,
> 
> Julian
> 
> -- 
> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> 
> 



From w3c-dist-auth-request@w3.org  Tue Nov 25 13:03:44 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29868
	for ; Tue, 25 Nov 2003 13:03:43 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 21ECDA0748; Tue, 25 Nov 2003 13:03: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 81387A0748
	for ; Tue, 25 Nov 2003 13:03:49 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 314C9139E6; Tue, 25 Nov 2003 13:03:49 -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 DC540139E1
	for ; Tue, 25 Nov 2003 13:03:48 -0500 (EST)
Received: from lisalap ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 25 Nov 2003 10:03:48 -0800
From: "Lisa Dusseault" 
To: "'Helge Hess'" ,
        "'Geoffrey M Clemm'" 
Cc: "'Webdav WG'" 
Date: Tue, 25 Nov 2003 10:03:45 -0800
Message-ID: <002601c3b37e$785a7070$75c990c6@lisalap>
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, Build 10.0.4510
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 25 Nov 2003 18:03:48.0185 (UTC) FILETIME=[797AD490:01C3B37E]
Subject: RE: WebDAV MOVE
X-Archived-At: http://www.w3.org/mid/002601c3b37e$785a7070$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8172
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: <20031125180356.21ECDA0748@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 13:03:56 -0500 (EST)
Content-Transfer-Encoding: 7bit


> code which signals the client why it couldn't perform the operation 
> would be quite useful (something like out-of-the-namespace-I-process).
> With the Forbidden code we do not know whether the request 
> was rejected 
> because of access restrictions or just because it is located on a 
> different server, right?
> 
> Note that I'm assuming that a server is usually "dumb" and 
> will not try 
> to act as a proxy with regards to the other namespace (if it 
> does we do 
> have the 502 code to detect errors, if I remember right).
> 

I thought the 502 Bad Gateway error was appropriate whenever it's
another server, another namespace, or another domain that can't
be copied to.  It's a fuzzy continuum, after all:

 - One physical machine may be able to copy to another physical
machine if they're in the same security domain and the software 
supports it.  Thus, docs1.example.com and docs2.example.com might 
allow MOVE between them.  If not, however, 502 Bad Gateway is 
appropriate.

 - Two domains might be hosted on the same physical machine.  Thus
if docs.bettysbagels.com and docs.joesjava.com are both hosted by 
the same service provider using the same server software, using 
virtual servers, a MOVE between them might be allowed.  If it's 
not allowed, however, 502 Bad Gateway is appropriate. 

 - Within one domain, two top-level directories might actually 
be mounted from different locations (different file storage servers?), 
and *not* allow move between. E.g. docs.example.com/nfs-mount1 
and docs.example.com/cifs-mount8 might not support MOVE between 
them.  I think this sufficiently meets the definition of "gateway" 
to make 502 Bad Gateway is still appropriate.

Lisa



From w3c-dist-auth-request@w3.org  Tue Nov 25 13:22: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 NAA00468
	for ; Tue, 25 Nov 2003 13:22:23 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 09AE3A05B6; Tue, 25 Nov 2003 13:22: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 5052AA05DA
	for ; Tue, 25 Nov 2003 13:22:29 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id D5C2813A0C; Tue, 25 Nov 2003 13:22:28 -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 6229D13A09
	for ; Tue, 25 Nov 2003 13:22:28 -0500 (EST)
Received: (qmail 3652 invoked by uid 65534); 25 Nov 2003 18:22:26 -0000
Received: from pD950C26F.dip.t-dialin.net (EHLO gmx.de) (217.80.194.111)
  by mail.gmx.net (mp002) with SMTP; 25 Nov 2003 19:22:26 +0100
X-Authenticated: #1915285
Message-ID: <3FC39DD5.5090609@gmx.de>
Date: Tue, 25 Nov 2003 19:22:13 +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: Jeffrey Mogul , ietf-http-wg@w3.org,
        w3c-dist-auth@w3c.org
References: <200311251636.hAPGaQmU018655@wera.hpl.hp.com> 
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/3FC39DD5.5090609@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8173
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: <20031125182234.09AE3A05B6@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 13:22:34 -0500 (EST)
Content-Transfer-Encoding: 7bit


Alex Rousskov wrote:

> Given Jeff's comments, would it make any sense for those who need a
> working OPTIONS to specify their own extension method (e.g., FEATURES)
> and publish a small RFC instead of patching RFC 2616?

Possibly, but I don't think this applies to the questions that got us here.

WebDAV uses the DAV: response header in OPTIONS, and so far this seems 
to work just fine. The only disagreement that we have (had?) is whether 
clients can rely on "OPTIONS *" returning something meaningful. I think 
it has been shown that they can't, thus RFC2518bis shouldn't add any new 
language suggesting that. In addition, we have no evidence of clients 
that actually use that.

Regarding Lisa's draft for a PATCH method, I still believe that getting 
rid of any dependencies on OPTIONS will make it easier to be 
acccepted/implemented. At the very least it shouldn't require "OPTIONS 
*" to do anything it won't actually do in practice.

> ...
> 
> Adding some extension header to OPTIONS, to signal new well-defined
> functionality would be a similar approach that does not require an
> extension method.

That's what WebDAV already does 
(), and 
besides the problem with "OPTIONS *", there doesn't seem to be any 
real-world problem with it.

Julian

-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov 25 13:42:13 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 NAA01303
	for ; Tue, 25 Nov 2003 13:42:13 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A46ABA0AA8; Tue, 25 Nov 2003 13:42: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 EE0CAA0C19
	for ; Tue, 25 Nov 2003 13:40:48 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 15ABE13D69; Tue, 25 Nov 2003 13:30:07 -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 99C7413D55
	for ; Tue, 25 Nov 2003 13:30:06 -0500 (EST)
Received: (qmail 7610 invoked by uid 65534); 25 Nov 2003 18:30:05 -0000
Received: from pD950C26F.dip.t-dialin.net (EHLO gmx.de) (217.80.194.111)
  by mail.gmx.net (mp010) with SMTP; 25 Nov 2003 19:30:05 +0100
X-Authenticated: #1915285
Message-ID: <3FC39FA6.5020302@gmx.de>
Date: Tue, 25 Nov 2003 19:29:58 +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: Scott Lawrence 
Cc: Jeffrey Mogul ,
        Alex Rousskov , ietf-http-wg@w3.org,
        w3c-dist-auth@w3c.org
References: <200311251636.hAPGaQmU018655@wera.hpl.hp.com> 
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/3FC39FA6.5020302@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8174
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: <20031125184214.A46ABA0AA8@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 13:42:14 -0500 (EST)
Content-Transfer-Encoding: 7bit


Scott Lawrence wrote:

 > ...
> I agree that the best that can be done now is to document what can and
> cannot be achieved with what we have (pretty limited, but it does make
> a good no-op message; we used it that way in RFC 2817).

Agreed. So I think what we want to replace is 
:

"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)."

Any proposals for replacement text?

Julian


-- 
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Nov 25 18:10:35 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16750
	for ; Tue, 25 Nov 2003 18:10:35 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BAC13A0502; Tue, 25 Nov 2003 18:10:42 -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 60FF8A0502
	for ; Tue, 25 Nov 2003 18:10:39 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 01C9D139C9; Tue, 25 Nov 2003 18:10:39 -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 898A313402
	for ; Tue, 25 Nov 2003 18:10:38 -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 hAPN8Vj23773
	for ; Tue, 25 Nov 2003 15:08:32 -0800 (PST)
From: "Jim Whitehead" 
To: "WebDAV" 
Date: Tue, 25 Nov 2003 15:09:52 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: Re: OPTIONS *
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIEEAHKEAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8175
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: <20031125231042.BAC13A0502@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 18:10:42 -0500 (EST)
Content-Transfer-Encoding: 7bit


Accidentally caught by the spam filter. I've added
rousskov@measurement-factory.com to the accept2 list.

- Jim

-----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: [Moderator Action] 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.



From w3c-dist-auth-request@w3.org  Tue Nov 25 20:34:05 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 UAA21005
	for ; Tue, 25 Nov 2003 20:34:05 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 374D1A05B5; Tue, 25 Nov 2003 20:34:17 -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 780C3A05B5
	for ; Tue, 25 Nov 2003 20:34:13 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 49F7B13A57; Tue, 25 Nov 2003 20:25:10 -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 6A48513A37
	for ; Tue, 25 Nov 2003 20:25:06 -0500 (EST)
Received: from lisalap ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 25 Nov 2003 17:25:03 -0800
From: "Lisa Dusseault" 
To: "'Alex Rousskov'" ,
        "'Scott Lawrence'" 
Cc: "'Larry Masinter'" , "'Webdav WG'" ,
        
Date: Tue, 25 Nov 2003 17:25:00 -0800
Message-ID: <009301c3b3bc$1cbd7df0$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
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 26 Nov 2003 01:25:03.0510 (UTC) FILETIME=[1E00D360:01C3B3BC]
Subject: RE: OPTIONS *
X-Archived-At: http://www.w3.org/mid/009301c3b3bc$1cbd7df0$75c990c6@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8176
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: <20031126013417.374D1A05B5@frink.w3.org>
Resent-Date: Tue, 25 Nov 2003 20:34:17 -0500 (EST)
Content-Transfer-Encoding: 7bit


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.
> 
> 



From w3c-dist-auth-request@w3.org  Wed Nov 26 12:04: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 MAA17330
	for ; Wed, 26 Nov 2003 12:04:21 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2464BA0DEB; Wed, 26 Nov 2003 12:04:29 -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 74D79A0DAA
	for ; Wed, 26 Nov 2003 12:04:10 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 4C23E13DF4; Wed, 26 Nov 2003 11:59:38 -0500 (EST)
Delivered-To: w3c-dist-auth@w3c.org
Received: from measurement-factory.com (measurement-factory.com [206.168.0.5])
	by dr-nick.w3.org (Postfix) with ESMTP
	id 0813913DF3; Wed, 26 Nov 2003 11:59:38 -0500 (EST)
Received: from measurement-factory.com (localhost [127.0.0.1])
	by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hAQGxUGh054168;
	Wed, 26 Nov 2003 09:59:30 -0700 (MST)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.9/Submit) id hAQGxU3q054167;
	Wed, 26 Nov 2003 09:59:30 -0700 (MST)
	(envelope-from rousskov)
Date: Wed, 26 Nov 2003 09:59:30 -0700 (MST)
From: Alex Rousskov 
To: Jim Gettys 
Cc: Lisa Dusseault , "'Scott Lawrence'" ,
        "'Larry Masinter'" ,
        "'Webdav WG'" , ietf-http-wg@w3.org
In-Reply-To: <1069861653.5508.17.camel@laptop.gettys.org>
Message-ID: 
References: <009301c3b3bc$1cbd7df0$75c990c6@lisalap> <1069861653.5508.17.camel@laptop.gettys.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: RE: OPTIONS *
X-Archived-At: http://www.w3.org/mid/Pine.BSF.4.53.0311260957121.51108@measurement-factory.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8177
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: <20031126170429.2464BA0DEB@frink.w3.org>
Resent-Date: Wed, 26 Nov 2003 12:04:29 -0500 (EST)



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)".

Alex.

> On Tue, 2003-11-25 at 20:25, Lisa Dusseault 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.  For example, this
> >   can be used to test a proxy for HTTP/1.1 support (or lack thereof).
> >
> > Lisa
> >
> > > 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).
> > > > >
> > >
> > > 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.



From w3c-dist-auth-request@w3.org  Sun Nov 30 06:04:17 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 GAA27975
	for ; Sun, 30 Nov 2003 06:04:17 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 99A9CA05B9; Sun, 30 Nov 2003 06:04: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 5786FA0655
	for ; Sun, 30 Nov 2003 06:04:11 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id 92B5E1360C; Sun, 30 Nov 2003 06:03:34 -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 0D69013617
	for ; Sun, 30 Nov 2003 06:03:34 -0500 (EST)
Received: (qmail 30331 invoked by uid 65534); 30 Nov 2003 11:03:20 -0000
Received: from pD950C24E.dip.t-dialin.net (HELO lisa) (217.80.194.78)
  by mail.gmx.net (mp025) with SMTP; 30 Nov 2003 12:03:20 +0100
X-Authenticated: #1915285
From: "Julian Reschke" 
To: 
Date: Sun, 30 Nov 2003 12:03:03 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Subject: Re: Bind issues
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEBEJAAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/8178
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: <20031130110427.99A9CA05B9@frink.w3.org>
Resent-Date: Sun, 30 Nov 2003 06:04:27 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa,

you haven't replied to my mail dated Nov 18
().
As far as I can tell among the three questions you raised,

- one is closed (by the introduction of REBIND in addition to MOVE),

- one is still open (bind loop error marshalling), proposal for resolution
is at


- one will be closed by updating GULP
()
to clarify when a lock token counts as "submitted".

Do you agree?

Besides the error marshalling question, this still leaves the issue open
where GULP belongs. My recollection from the Interim meeting in January is
that we planned to add GULP to RFC2518bis
().
If this isn't the plan anymore (why?), we'd have to consider adding GULP to
the BIND spec. This would be of course a very bad thing, as GULP in fact
says little about bindings, and we'd introduce the risk that BIND and
RFC2518bis say different things about locks.

As we've had this discussion for over a year now with little progress, I'd
like the mailing list to simply vote on this issue.

Here's the proposal:

"RFC2518bis should include the text from the latest GULP proposal (after
possibly final adjustments) as *normative* description of WebDAV locking
behaviour."

In any case, the BIND draft has been stable for a long time now, and we
really should get the final changes done so we can last-call it.


Regards,

Julian

--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760